DE:Empfehlungen zum Vorgehen
From i-doit documentation
| i-doit Benutzerhandbuch 0.9.x: |
Hauptseite | Vorwort | Über dieses Handbuch | Release Notes | Nützliche Links | Installation | Systemkonfiguration | Grundlagen | Empfehlungen zum Vorgehen | Das CMDB-Modul | Allgemeine Kategorien | Spezifische Kategorien | Browser | Objekttypen | Verbindungen | Dateien | Lizenzen | Workflows | my-doit | Kontakte | Einstellungen | Nagios Integration | Report Manager | OCS Inventory NG |
Einleitung
Das Kapitel soll Anregungen für den geplanten Einstieg in die Nutzung von i-doit geben. Dabei wird ein grundsätzliches Verständnis der Arbeitsweise von i-doit (insb. Objekttypen und Kategorien) vorausgesetzt.
Vor dem Einsatz
Zu Beginn gilt es festzulegen, was in welcher Tiefe dokumentiert werden soll. i-doit bietet die Möglichkeit, sowohl die Detailtiefe (s. Kategorien) als auch den Umfang (s. auch Objekttypen) zu bestimmen. Nach einer Standardinstallation sind dabei zunächst alle mitgelieferten Objekttypen in voller Detailtiefe aktiv.
Neben der Frage, welche der bestehenden Objekttypen zum Einsatz kommen sollen, steht auch die Überlegung, ob ggf. eigene Objekttypen benötigt werden und welche Ausprägung (s. Kategorien) diese haben sollen. Wer zum Beispiel seine Blade-Systeme verwalten möchte, erstellt sich hierzu einen Objekttyp "Blade-Chassis" als Containerobjekt und dann einen weiteren Objekttyp "Blade" als normalen Objekttyp und weist den beiden die jeweils notwendigen Kategorien zu. Damit kann man dann einzelne Blades einem Chassis zuordnen und schafft Raum für eine flexible Dokumentationslogik.
Eine weitere wichtige Überlegung besteht darin, den Umfang, bzw. die Tiefe der Verbindungsdokumentation zu bestimmen. Neben der Abbildung von Strom-, Daten- und Speichernetzen ist hier auch das generische Modell "Schnittstellen" zu berücksichtigen. Dieses erlaubt die Definition eigener Verbindungstypen, die dann bei gleichem Typ objektübergeifend miteinander verbunden werden können. Im einfachsten Fall sind das USB- oder Grafik-Schnittstellen, genauso können aber auch alternative Netzverbindungen damit dokumentiert werden.
In der Nutzung der Verbindungsdokumentation stellt i-doit bewusst keine Vorgaben auf. Es bleibt dem Anwender überlassen, ob und in welcher Tiefe Verbindungen dokumentiert werden sollen. Als Grundsatz kann dabei stehen bleiben, dass eine höhere Detaillierung insbesondere im Fehlerfall eine große Unterstützung darstellt, aber auch einen recht hohen Aufwand bei der Ersterfassung und einen erhöhten Aufwand bei der Pflege bedeutet. Das gilt natürlich auch analog für die Detaillierung der Objekttypen.
i-doit im Einsatz
Dokumentationen haben den großen strategischen Nachteil, dass sie sich ständig mit der Realität messen lassen müssen. Es geht also um das "lästige" Thema Pflege. Auch hierzu sollte man sich im Vorfeld Gedanken machen (s.o.), da im Zweifel wenige, aber aktuelle Informationen über ein System hilfreicher sind als viele Details, deren Aktualität nicht gesichert ist. Hier soll es aber jetzt eher um allgemeine Überlegungen zum Einsatz von i-doit gehen. Und zwar insbesondere in Bezug auf die Pflege und Nutzung der Dokumentationsdaten.
Dafür stehen in i-doit aktuell zwei maßgebliche Werkzeuge zur Verfügung. Da sind zunächst die Workflows zu nennen, die mit den 'Arbeitsaufträgen' und 'Checklisten' Hilfsmittel für die Nachverfolgung von System- und Dokumentationsarbeiten liefern. Bei einer durchgängigen Nutzung dieser Verfahren kann eine konsistente Historie von Änderungen erfasst werden, die über die Möglichkeiten des Logbuches hinausgehen.
Als zweites steht die my-doit-Funktion bereit. Diese liefert den Überblick zu den zuvor dargestellten Workflows und erlaubt darüber hinaus eine individuelle Zusammenstellung von "Favoriten", sprich einzelnen Objekten innerhalb von i-doit. Somit kann eine individuelle Sicht auf die hauptsächlich genutzten Objekte zusammen gestellt werden, die dann einen direkten und damit schnelleren Zugriff auf diese Objekte erlaubt.
Sofern für Änderungen innerhalb von i-doit keine Workflows genutzt werden, sollte über die Kommentarfunktion des Logbuchs nachgedacht werden. Die Anwendung kann so konfiguriert werden, dass jeder Speichervorgang mit einem Kommentar quittiert werden muss, der nach Möglichkeit den Grund der Änderung enthält. Mit dieser Mini-Dokumentation können Hintergründe für Änderungen/Neuanlagen zumindest rudimentär erfasst und somit nachvollziehbar gehalten werden.
