Ein Configuration Item (CI) ist jede Komponente - Hardware, Software oder Dokumentation - die in einer CMDB geführt wird, weil sie einen IT-Service unterstützt.
Ein Configuration Item (CI) ist jede Komponente, die verwaltet werden muss, um einen IT-Service zu erbringen - ein Server, eine Anwendung, ein Netzwerk-Switch, sogar ein Dokument -, erfasst in einer Configuration Management Database (CMDB). Der Begriff stammt aus ITIL, dem am weitesten verbreiteten Rahmenwerk für IT-Service-Management. Was ein CI von einem gewöhnlichen Asset-Datensatz unterscheidet, sind die Beziehungsdaten: Eine CMDB listet Komponenten nicht nur auf, sie bildet ab, wie sie voneinander abhängen, sodass bei einem Ausfall der Auswirkungsbereich sichtbar wird.
Beispiele für Configuration Items
- Hardware-CIs - Server, Netzwerk-Switches, Router, Firewalls, Storage-Arrays und Endgeräte, von denen ein Service abhängt.
- Software-CIs - Betriebssysteme, Anwendungen, Datenbanken, Middleware und ihre Versionen.
- Dokumentations-CIs - Runbooks, SLAs, Netzwerkdiagramme und Richtlinien, ohne die der Service nicht betrieben werden kann.
- Service- und Infrastruktur-CIs - der E-Mail-Service selbst, Cloud-Instanzen, SSL-Zertifikate, DNS-Zonen.
Der entscheidende Test ist die Auswirkung auf den Service, nicht der Preis. Ein günstiges SSL-Zertifikat ist ein Musterbeispiel für ein CI, weil sein Ablauf einen Service lahmlegt; ein teurer Gegenstand ohne Rolle für einen Service - Reserve-externe Festplatten im Schrank oder Konferenzraum-Ausstattung, von der niemandes Verfügbarkeit abhängt - ist ein Asset, das sich zu erfassen lohnt, aber selten als CI zu modellieren ist.
Was ein CI-Datensatz enthält
Ein CI trägt eine eindeutige Kennung, einen Typ, einen Verantwortlichen, einen Status und, wo relevant, eine Version. Das Attribut, das die eigentliche Arbeit leistet, sind die Beziehungen: „läuft auf”, „hängt ab von”, „verbindet mit”, „ist dokumentiert durch”. Über diese Verknüpfungen kann der Service Desk einen Ausfall vom defekten Switch bis zu den drei Anwendungen dahinter verfolgen oder im Voraus bewerten, was eine geplante Änderung berührt. Ohne Beziehungen schrumpft eine CMDB zu einem gewöhnlichen Inventar mit ein paar Extra-Feldern.
CI vs. Asset
Beide Konzepte beschreiben dieselbe physische Welt aus unterschiedlichen Blickwinkeln. Ein Asset-Datensatz nimmt die Eigentums- und Finanzsicht ein: Kaufpreis, Lieferant, Garantie, aktueller Inhaber, Position im IT-Asset-Lebenszyklus und wann der Hardware-Austauschzyklus einen Ersatz vorsieht. Ein CI nimmt die Service-Sicht ein: was diese Komponente unterstützt und was geschieht, wenn sie ausfällt.
Die beiden Mengen überschneiden sich, ohne deckungsgleich zu sein. Ein Produktionsserver ist Asset und CI. Ein Reserve-Monitor ist ein Asset, aber kein CI. Eine kostenlose Open-Source-Bibliothek oder ein Runbook ist ein CI, taucht aber in keiner Bilanz auf - so wie ein Software-Nutzungsrecht lizenzrechtlich ein Asset ist, ganz gleich, ob es jemand in einer CMDB modelliert oder nicht.
Wann eine CMDB überdimensioniert ist
CMDBs haben sich ihren Ruf des Verfalls verdient. Beziehungsdaten aktuell zu halten ist teuer - jede Architekturänderung, Migration und Ausmusterung muss nachgezogen werden, und eine CMDB, die nur zu 80 % stimmt, ist gefährlich, weil man ihr mitten in einer Störung vertraut. Die ehrliche Faustregel: CIs nur dort modellieren, wo die Abhängigkeitskarte wirklich gepflegt und herangezogen wird - meist die Server, das Netzwerk und die Kernanwendungen hinter kritischen Services. Für alles andere - und für die meisten kleinen und mittleren Organisationen ganz - liefert ein gut geführtes Asset-Register mit Eigentümern, Status und Historie den Großteil des Werts bei einem Bruchteil des Aufwands; das Glossar behandelt die Register-Seite im Detail.
Verwandte Begriffe
- IT-Asset-Lebenszyklus - die Phasen vom Kauf bis zur Entsorgung, die die Asset-Sicht abbildet
- Hardware-Austauschzyklus - der geplante Ersatzrhythmus für Hardware-CIs und Assets
- Software-Nutzungsrecht - die Lizenzrechte hinter Software-CIs
- Kauflizenz vs. Abo - die zwei Bezahlmodelle für Software-CIs
- Per-User-Lizenzierung - platzbasierte Lizenzierung, an Nutzer statt an Komponenten gebunden