Praxis-Leitfaden IT-Dokumentation: Schritt 1 – Dokumentation der physischen Infrastruktur

Praxis-Leitfaden IT-Dokumentation: Schritt 1 – Dokumentation der physischen Infrastruktur

Unsere neue Praxis-Reihe „In 6 Schritten zur IT-Dokumentation“ präsentiert anschaulich die Möglichkeiten der IT-Dokumentation und führt Sie durch die einzelnen Abschnitte Ihres Dokumentations-Projektes:

  1. Die Infrastruktur
  2. Das Netzwerk
  3. Die Server
  4. Die Clients
  5. Die Server-Anwendungen und IT-Services

Natürlich können Sie die komplette Blog-Reihe auch als kompakten Praxis-Leitfaden kostenlos herunterladen.

Standortdokumentation leicht gemacht

Gehen Sie davon aus, dass Sie jedes Objekt, das einem Standort entspricht, nur noch genau einmal dokumentieren müssen. Alle anderen Objekte werden damit relational verbunden.

Das alles kann ein physischer Standort sein:

  • Ein Chassis (um Einschübe korrekt zu “verorten”)
  • Ein Rack (in dem Chassis oder Server eingebaut sind)
  • Ein Arbeitsplatz (mit dem Geräte verbunden sind)
  • Ein Raum (in dem z.B. Racks oder Arbeitsplätze sind)
  • Ein Stockwerk (in dem Räume sind)
  • Ein Gebäude (in dem mehrere Stockwerke sind)
  • Ein Campus (in dem Gebäude stehen)
  • Eine Stadt (in der Gebäude oder Campus sind)
  • Ein Bundesland
  • Ein Staat/Land

Zu kompliziert?

Nun – die rudimentäre Variante, zum Beispiel für eine reine Rechnerraumkonfiguration, ist wie folgt:

Racks stehen in einem Raum und Räume befinden sich in einem Gebäude. Alles andere wird anfangs weggelassen.

Da jedes Element nur einmal angelegt wird, kann man in die einmalige Dokumentation ein wenig mehr Mühe stecken: Nicht nur ein Name sollte es sein, sondern weitere Eigenschaften: Die genaue Adresse, die Ansprechpartner (für Zutritt oder Alarmierung), Eine Telefonnummer der Nebenstelle im Rechnerraum, usw. Denken Sie bitte an den worst case: Im schlimmsten Fall müssen nicht Sie sich zurechtfinden, sondern Personen, die unter Umständen noch nie in den Räumlichkeiten waren!

 

Wie umgehen mit fehlenden Angaben?

Oft wird uns von fehlenden Angaben aus der Organisation berichtet: Es gibt keine eindeutige Bezeichnung von Räumen, keine Raumnummern. Daher kann vermeintlich mit der Dokumentation der Standorte nicht fortgefahren werden. Das Projekt scheint von Anfang an festzustecken.

Kommunikation ist im Notfall alles…

Wie kann es von hier aus weitergehen?

Mit den dokumentierten Standorten kann man schon eine Menge anfangen:

 

 

Raumpläne

Mit dem i-doit Raumplan-Add-on erhalten Sie eine grafische Darstellung, auch Bilder (z.B. von Gebäudeplänen) können hinterlegt werden. Später werden Sie wahrscheinlich die genauen Standorte von Anlagen, Racks, aber auch die WLAN Abdeckung einzeichnen wollen.

 

Rack Management

Gleich kommen wir zu den Geräten, die in den Racks stecken. Wenn Sie diese auch im Rack richtig verorten, also die Höhenangaben richtig treffen, erleben Sie als Dank eine grafische Darstellung, die der Realität im Serverraum entspricht. Endlich!

 

Facility Management

Verwalten Sie nicht nur Räume, sondern auch Arbeitsplätze, die Benutzer, Telefonnebenstellen, bis hin zur Inventur von Tisch, Stuhl und Feuerlöscher. Wobei anfangs das Hauptaugenmerk sicher auf wichtigen IT-Komponenten liegen sollte!

 

Dokumentieren der betrieblichen Anlagen

Feuerlöscher, USV-Anlagen, Netzersatzanlagen, Klimaanlagen, etc. haben eines gemeinsam: Eine Prüfplakette, oft vom TÜV ausgestellt, die Auskunft darüber gibt, wann die nächste Überprüfung stattfinden muss. Teils sind versicherungstechnische, teils gesetzliche, oder einfach betriebliche Notwendigkeiten der Hintergrund, diese Termine nicht zu übersehen. Lassen Sie sich doch von i-doit an diese Termine automatisch erinnern, oder erstellen Sie einen automatischen Report, was im Folgemonat an Überprüfungen einzuplanen ist.

 

Verkabelungsmanagement

oft ist es nötig die Kabelverbindungen zu dokumentieren. Vor allem beim Patchen eine große Hilfe zur immer wiederkehrenden Frage: Welche Strippe kann abgesteckt werden? i-doit weiß es. Wobei es i-doit egal ist, ob Sie Strom- oder Netzwerkverbindungen abbilden. Doch ist das nun der richtige Zeitpunkt? Wir meinen: Nein: Später dazu mehr.

Sie möchten den kompletten Praxis-Leitfaden kostenlos herunterladen?
Hier geht es zum PDF-Download!

i-doit Add-ons: alle Funktionserweiterungen im Überblick

i-doit Add-ons: alle Funktionserweiterungen im Überblick

Dem aufmerksamen Beobachter mag es schon aufgefallen sein: Unsere Module heißen jetzt Add-ons. Im internen Sprachgebrauch hadere ich zwar noch ein wenig mit dem neuen Begriff – aber es gab handfeste Gründe, hier sprachlich aufzuräumen.

Werfen wir einen Blick auf die alte Darstellung:

Wir hatten Module, Erweiterungen und Schnittstellen. Module nannten wir die kostenpflichtigen Ergänzungen zu i-doit, z.B. das Dokumente und Analyse Modul. Erweiterungen waren die kostenfreien, wie der Raumplan oder Gerätetausch. Schnittstellen waren “sowieso” schon im i-doit Kern mit dabei, benötigten aber immer mindestens ein 3rd Party Produkt, welches separat installiert werden muss. Beispiel JDisc Discovery.

Das ist von den Begrifflichkeiten her zwar in sich soweit schlüssig, aber mittlerweile haben sich aber zwei Dinge geändert.

Mittlerweile haben sich aber zwei Dinge geändert

Zum einen haben wir Bestandteile des i-doit Cores wie beispielsweise die API herausgetrennt und als zusätzlich installierbare Erweiterung veröffentlicht. Diese Methodik werden wir auch in Zukunft bei der Überarbeitung einiger Funktionen beibehalten, um den i-doit Core schlank zu halten. Letztendlich geht es hier um Performance und Übersicht. Knöpfe hat i-doit ja schon genug.
Zum anderen haben unsere Partner marktreife Eigenentwicklungen veröffentlicht und bieten diese als Ergänzungen zu i-doit an. Diese Entwicklungen haben eine enorme Spannweite. Das reicht von Schnittstellen über die Lösung von Use-Cases bis hin zur Behandlung ganzer Prozess-Ketten. Beispiele sind mehrere gelungene OTRS Kopplungen, eine branchenspezifische Möglichkeit zur Dokumentation von Medizintechnik sowie einige Kopplungen zu Monitoring Lösungen. Und in Zukunft werden unsere Partner noch einiges mehr anbieten… (Appstore, ick hör Dir trapsen)

Deswegen nennen wir all diese Varianten nun
einfach Add-ons

Anstatt die Kommode um weitere Schubladen zu erweitern, haben wir uns überlegt, die Begrifflichkeiten zu vereinheitlichen. Was nützt es unseren Anwendern, sprachlich hier genau differenzieren zu können? Nicht viel, denn der technische Prozess ist erstmal der gleiche: Ich lade etwas herunter und installiere es zusätzlich. Deswegen nennen wir all diese Varianten nun einfach Add-ons.

Der Kritiker in mir sagt nun: Für den Anwender ist es aber aufgrund des Namens nicht mehr ersichtlich, ob ein Add-on kostenpflichtig ist oder nicht! Doch hier beruhigt mich letztendlich unser Markt Team mit der Aussage: “Alles eine Sache der Präsentation”.

Die gebündelte Darstellung unserer Add-ons dürfen wir jetzt hier bewundern:

https://www.i-doit.com/produkte/add-ons/

OTRS-Schnittstellen unserer Partner

OTRS-Schnittstellen unserer Partner

Die i-doit OTRS Schnittstellen im Überblick

Haben wir uns im vorigen Artikel mit den Vorteilen der Kopplung von OTRS und i-doit beschäftigt, werden in diesem Artikel die derzeit verfügbaren Schnittstellen vorgestellt.
Aktuell sind vier Schnittstellen der i-doit Partner becon, Freicon, it-Novum und Sector Nord AG verfügbar. Unsere Partner verwenden diese in ihren eigenen ITSM Projekten, in denen zumeist mehrere ITSM Prozesse umgesetzt und damit auch mehrere Tools miteinander gekoppelt werden. Langfristige Projekte sind jedoch nicht Bedingung für den Einsatz, die hier besprochene Schnittstellen werden auch frei zum Verkauf angeboten. Jeder Partner pflegt seine eigene Umsetzung, es ist somit Versionskompatibilität gewährleistet. Eventuell nötige Updates nach Erscheinen neuer Releases, sowohl von OTRS als auch i-doit, sind bei allen Partnern kurzfristig gewährleistet, ebenso gibt es funktionierende Supportstrukturen auf Basis von Wartungsverträgen.

Gemeinsamkeiten

Jede der betrachteten Schnittstellen bietet sowohl eine Verknüpfung von OTRS Tickets zu  i-doit Objekten als auch eine Übersicht und Verknüpfung von i-doit Objekten zu OTRS Tickets. Von beiden Seiten aus können also Informationen eingesehen und mit einem Klick im jeweils anderen Werkzeug aufgerufen werden.

Ebenso bieten alle vier Hersteller die Verknüpfung mit jeder der im letzten Artikel vorgestellten Prozess-Arten an. Der Incident-, Problem- bzw. Request for Change-Prozess kann zum Beispiel direkt aus dem betroffenen i-doit Objekt gestartet und sofort mit diesem verknüpft werden, eine tolle Vereinfachung des täglichen Betriebs.

Unterschiede

Als größter Unterschied zwischen den Umsetzungskonzepten haben wir die Datensynchronisation identifiziert. Ein Weg, der von zwei Anbietern, Becon und it-Novum, zur Realisierung der Schnittstelle gewählt wurde, ist die Synchronisierung von “Kopfdaten” der Objekte, also einiger Attribute die in beiden Tools synchron gehalten werden. Eine Komplettsynchronisation aller Attribute macht wenig Sinn, nicht jedes Detail wird benötigt. Der technische Task der Synchronisation wird von einer der beiden Seiten aus angestoßen und entweder zeitgesteuert oder über Events getriggert durchgeführt. Damit hat man hohe Freiheiten zu welchen Anlässen synchronisiert werden soll, muss dies jedoch auch tun. Vorteil dieser Methode ist, dass jene Daten auch garantiert vorliegen, die zur Steuerung weiterer Prozessschritte, Automatismen oder Funktionen verwendet werden.
Der von den beiden anderen Partnern, Freicon und Sector Nord, gewählte Weg ist, eine Datensynchronisation zu vermeiden und anlassbezogen die aktuellen Daten des jeweils anderen Objekts via Schnittstelle anzuzeigen. Hier wiederum spart man sich den Aufwand der sich mit Datensynchronisation ergibt und greift in Echtzeit stets auf aktuelle Daten zu.

it-novum

it-novum benutzt die OTRS-eigene CMDB-Komponente aus dem OTRS::ITSM Framework und bietet damit eine Synchronisierung von Daten zwischen i-doit und OTRS. Gesteuert wird die Synchronisation aus i-doit heraus, dass bei diesem Ansatz immer die führende CMDB bleibt. Der i-doit/OTRS Connector ist als i-doit-Modul umgesetzt und mit allen OTRS-Versionen (Free und Enterprise) kompatibel. Der große Vorteil des Connectors liegt darin, dass er mit wenigen Klicks installiert werden kann und keine Anpassungen an OTRS vorgenommen werden müssen, da er die Webservice-API von OTRS anspricht. Er läuft dadurch mit allen OTRS Versionen ab OTRS 4. 

Dadurch dass kein OTRS Code installiert oder geändert werden muss, eignet sich der i-doit/OTRS Connector auch für Cloud-basierte OTRS Lösungen und kommerzielle Varianten wie die kostenpflichtige OTRS Business Solution™. Auch bei Migrationen auf eine aktuellere OTRS-Version bleibt der Connector funktional, da er lediglich Standard API-Funktionen anspricht. Der i-doit/OTRS Connector ist mandantenfähig und lässt sich mit der hauseigenen Monitoring-Lösung openITCOCKPIT integrieren.

becon GmbH

Die von becon angebotene Schnittstelle wird als Paket ausgeliefert, das vom Anwender selbst in wenigen Schritten installiert werden kann.

Auch hier werden alle OTRS::ITSM Funktionen weiterhin genutzt, und keine internen Strukturen von OTRS verändert. Wie auch die vorhergehende Schnittstelle synchronisiert diese Schnittstelle Daten zwischen i-doit und OTRS::ITSM. Hier wird allerdings über eine einfach zu installierende Erweiterung die Synchronisation aus OTRS heraus gesteuert. Strukturen werden aus i-doit ausgelesen und automatisch in der OTRS CMDB angelegt. Ein Vorteil dieser Methodik ist die Nutzung der in OTRS bereits integrierten Verknüpfung von Tickets mit i-doit Objekten. becon bietet über die hier besprochene Schnittstelle hinaus auch Integrationen mit mehreren Monitoring-Lösungen an.

Freicon

Die Firma Freicon wählt einen anderen Ansatz. Daten werden zwischen den beiden Werkzeugen nicht synchronisiert, sondern jeweils Referenzen gespeichert. Verknüpfungen zwischen Tickets und Objekten werden über die jeweilige API in Echtzeit abgerufen und sind damit im Anlassfall stets aktuell. Über den Primärschlüssel der E-Mail-Adresse eines Kontaktes werden so auch direkt verknüpfte Komponenten oder Services zu einem Kontakt angezeigt, dies bietet eine immense Arbeitserleichterung für den Support. Freicon bietet unter anderem auch die Integration mit der hauseigenen Lösung Monitos für Echtzeit-Monitoring an.

Sector Nord AG

Auch die Sector Nord AG wählt den Ansatz der Echtzeitverknüpfung von Informationen. Die Aktualität der Daten ist stets gewährleistet und eine einfache Abfrage von Komponenten, die Benutzern direkt oder über einen Arbeitsplatz zugeordnet sind, ist möglich. Der Schwerpunkt von Sector Nord liegt auf Prozessintegration, so haben wir in unserer Demo auch die Integration von Knowledge Base Artikeln gesehen, die in OTRS gespeichert, und auch aus i-doit abgerufen werden können. Auch Monitoringdaten aus dem hauseigenen Snag-View können über wenige Klicks vom Ticket über die i-doit Objekte abgefragt werden. Die OTRS-eigene Prozess-Engine wird intensiv zur Abbildung von wiederkehrenden Workflows verwendet, unter anderem für die Anlage neuer User in mehreren Systemen. Diese werden dann auch gleich in i-doit angelegt.

Zusammenfassung

Die Vorteile der ITSM-Prozessintegration über mehrere Werkzeuge stehen außer Zweifel. Der Trend im IT Service Management geht zügig in die parallele Umsetzung mehrerer Prozesse, die miteinander in Verbindung stehen. Diese sind natürlich auch auf möglichst hoch integrierte Tools angewiesen. Unsere Partner beweisen, dass Integration über mehrere Tools und damit auch Ende zu Ende integrierte Prozesse möglich sind, wie es vor einigen Jahren nur die “Big 4” mit ihren ITSM-Monolithen zusammen brachten.

Als zukünftiger Anwender einer solchen Integration gilt es abzuwägen, auf welcher Ebene man integrieren möchte: Genügt die effektive Prozessintegration oder benötigt man auch noch Datenintegration und -synchronität?

Da alle vier Hersteller nicht nur die eine hier vorgestellte Schnittstelle anbieten sondern mit ihrem Angebot den kompletten ITSM-Stack abdecken, lohnt sich eine intensivere Betrachtung des Angebots nach dem Motto: “Darf es noch ein bisschen mehr (Integration) sein?”.
We Do IT!

Video: OTRS Schnittstelle von i-doit

Video: OTRS Schnittstelle von i-doit

In unserem neuesten Video stellt Martin Hartkopf die scheinbar grenzenlose Integration von i-doit und OTRS vor. Anhand der Prozesse, die wir im BLOG-Artikel vorgestellt haben, zeigen sich schnell die Vorteile des Zugriffs auf eine aktuelle IT-Dokumentation aus dem Support-Tool, wie es im Zusammenspiel von OTRS und i-doit gegeben ist. Die aktuell verfügbaren Schnittstellen und deren Eigenschaften stellen wir im Artikel vor.

OTRS und i-doit: Prozess trifft auf Dokumentation

OTRS und i-doit: Prozess trifft auf Dokumentation

Früher oder später benötigt man neben einer aktuellen IT-Dokumentation auch ein Werkzeug zur Prozessabbildung. Auf der Wunschliste jedes Anwenders steht dann natürlich Datenintegration ganz oben: Doppelerfassung, redundante Arbeitsschritte und die Suche nach Informationen über zwei Tools will man sich gerne ersparen. Konkret wollen wir uns heute das zusammenspiel von OTRS HelpDesk mit i-doit ansehen. Mehrere i-doit Partner bieten solche Schnittstellen an, und das mit hohem Integrationsgrad.

Wer braucht welches Tool?

Spielt man die sprichwörtliche One-Man-Show, also IT-Admin, der selbst Systeme betreibt, Störungen beseitigt, den Anwendern persönlich hilft, muss man sich in erster Linie selbst organisieren. Hier steht selten der Aufbau eines Werkzeugs zur Prozessabbildung im Vordergrund, es reicht zumeist ein System zum Dokumentieren der IT-Infrastruktur, wie es mit i-doit gegeben ist. Und man benötigt viele Automatismen, die einem das Leben erleichtern.

Teilen sich die Aufgaben jedoch auf mehrere Personen auf und gibt es fachliche oder zeitliche Überschneidungen, braucht man bessere Koordination und vor allem: Kommunikation. Hat ein Kollege nachts einige Änderungen durchgeführt, ist es einfach notwendig, dass der Kollege diese am nächsten Tag nachvollziehen kann. Es sei denn man will ständig für’s Troubleshooting erreichbar sein. Sind Störungen vom letzten Arbeitstag offen geblieben, sollen diese in einer Liste ersichtlich sein und effizient abgearbeitet werden können. Welche Reparaturen sind beim externen Servicecenter beauftragt? Ein Service Desk Tool hat die Antwort.

Vorteile für den IT Betrieb

Die Verwendung von beiden Werkzeugen bringt folgende Vorteile im IT Betrieb:

  1. Information dort, wo man sie sucht.
    Jeder Schritt ist dokumentiert, und zwar dort, wo die Information hingehört: der Zustand der Geräte in der CMDB, der Verlauf von Störungen im Service Desk Tool. Um Zusammenhänge zu erkennen, dient die Verknüpfung der Daten.
  2. Klare Kommunikation.
    Gibt es Nachfragen oder weiteren Informationsbedarf, können alle Beteiligten, unabhängig von Dienstplan und Uhrzeit, auf den jeweils aktuellen Stand der Information zugreifen.

Was ist das Ziel?

Störungen in der IT gibt es, seit es IT gibt. Sie zu beseitigen, ist seit jeher ein langwieriges Unterfangen. ITIL® nennt den Prozess “Incident Management” und das Ziel dieses Prozesses ist vorerst nicht die nachhaltige Lösung, die das Wiederauftreten des Fehlers verhindert, sondern eine schnelle Lösung für den Anwender. Hauptsache, die Arbeit kann weitergehen. IT-Services sollen so schnell wie möglich wieder verwendbar sein, da darf auch mal gebastelt werden, sprich: Ein Workaround wird angewandt. Treten solche Fälle vermehrt auf, häufen sich auch die Bastellösungen. Man wünscht sich ein System, um diese Fälle wieder zu finden. Das Auftreten von Störungen will gezählt werden, Auswertungen sollen Serienfehler aufspüren, oder man will einfach nur herauszufinden, wo die Arbeitszeit geblieben ist.

Genügt anfangs eine Strichliste, wird man sich bald eine Excel-Tabelle bauen, oder eben ein System auswählen, das mehr kann. Ein Ticketsystem muss her, das zum Beispiel per e-Mail an Aufgaben erinnern kann, Auswertungen ohne langwierige SQL Schulung ermöglicht und vieles mehr, was erst später relevant wird. Bei der Auswahl greift man gerne zu Open Source. Denn wer zum ersten Mal ein solches System einführt, kann die Marketing Aussagen der Hersteller proprietärer Systeme meist nicht deuten: Was braucht man wirklich?

Open Source Ticket Systeme gibt es wie Sand am Meer. Man könnte meinen, dass jeder Programmierer das Rad neu erfunden und online gestellt hat. Doch in den letzten Jahren hat sich ein System vom Mitbewerb abgesetzt: OTRS, was ursprünglich “Open Ticket Request System” bedeutet und nun mit “Open Technology Real Services” umgedeutet wurde.

ITIL ist eine Schutzmarke von AXELOS, ein Joint Venture zwischen CAPITA (51 %) und Cabinet Office (49 %) (Quelle: https://de.wikipedia.org/wiki/IT_Infrastructure_Library ).

 

Noch ein Prozess

Spätestens nach der schnellen Lösung muss noch ein Post-It an den Monitor, damit die Suche nach der nachhaltigen Lösung nicht in Vergessenheit gerät. Hier spricht ITIL® nun von einem weiteren Prozess: Dem Problem Management. Hier wäre eine Art “Sammelticket” vorteilhaft, denn: während die Anwender mit dem Workaround bereits weiter arbeiten können, deren Tickets also geschlossen wurden, beschäftigen sich mitunter mehrere Personen mit dem Finden einer nachhaltigen Lösung. Hier fließt eine Menge Zeit und Energie rein. Grund genug, die jeweiligen Neuigkeiten zum Problem Ticket zu notieren – und damit auch gleich alle Beteiligten mit aktuellen Informationen zu versorgen.

 

Aller guten Dinge sind drei

Ist man sich nun sicher, was zu ändern ist, wird ein “Request for Change”, Im Admin-Sprech oft einfach “ein RfC” im Service Desk Tool eröffnet. Warum noch ein Ticket?

Änderungen werden gerne gesammelt und zu definierten Zeitpunkten umgesetzt. In diesen Wartungsfenstern ist wenig Zeit für Recherche, daher ist möglichst viel vorzubereiten. Die Risiken sollte man sich bereits im Vorfeld angesehen haben – was wäre wenn …

Um jede Änderung sauber betrachten zu können, Bemerkungen festzuhalten und auch eine Genehmigung von verantwortlicher Stelle zu dokumentieren, erhält sie eben einen eigenen “Change Record” im System. Gleiches gilt bei Reparaturaufträgen an externe Firmen: Jede Reparatur wird auch dort eigens gehandhabt, diese Vorgehensweise nutzen wir auch hier.

Mit diesen drei Prozessen gehen wir also an den Start, um uns OTRS anzusehen. Doch alle drei Prozesse werden erst so richtig “rund”, wenn sie mit aktuellen Informationen beschickt werden: Hier kommt i-doit ins Spiel.

 

Wann i-doit, wann OTRS?

Um herauszufinden, mit welchem Tool man was machen kann oder soll, müssen wir uns den eigentlichen Zweck der beiden Softwaretitel ansehen. Zusammengefasst: Bei i-doit liegen die Schwerpunkte in der flexiblen und individuell anpassbaren Dokumentation und bei OTRS in der individuellen Gestaltung der Prozesse.

Der Schwerpunkt von OTRS, das seit 2002 verfügbar ist, liegt in der Abbildung von Prozessen. Die oben beschriebenen Standardprozesse kommen in jeder IT Organisation vor, nichtsdestotrotz hat jede Organisation ihre Spezialitäten. Halten wir uns vor Augen, dass das Werkzeug auch von großen IT-Organisationen eingesetzt wird, wo beispielsweise mehrere Help Desk Agents im 1st Level Support Anwenderfragen lösen und technische Incidents in Form von Tickets an den 2nd Level weiterleiten, wird schnell klar, wo Flexibilität gefordert ist: Bei der Anpassung eben dieser Standardprozesse an den Bedarf des eigenen Unternehmens. Das kann OTRS, dafür wurde die Software geschrieben.

Überschneidung mit i-doit: Ebenso gibt es in OTRS eine integrierte Asset-Verwaltung, die einfache Anwendungsfälle wie Seriennummern- und Standortverwaltung von Geräten ermöglicht.

Der Schwerpunkt von i-doit ist das Dokumentieren in allen Facetten. Die Software ist 2004 aus konkretem Praxisbedarf entstanden und wird stetig mit Praxisbezug weiterentwickelt. Im Vordergrund steht natürlich die IT Infrastruktur mit all ihren Komponenten, egal ob physisch oder virtuell. Der gesamte Lebenszyklus kann dokumentiert werden, dazu kommen Relationen, Services, Applikationen und weitere, gut 120 vorgefertigte Objekttypen bis zum Kabel. Der Anwender hat vollkommene Flexibilität beim selbst Erstellen zusätzlicher Attribute und sogar eigener Objekttypen, sodass er im Prinzip auch seinen Fuhrpark, Bleistifte oder Satelliten dokumentieren kann.

Überschneidung mit OTRS: i-doit bringt auch eine rudimentäre Möglichkeit der Prozessabbildung mit, hier “Workflows” genannt.

 

Das Aufeinandertreffen der beiden Tools

Bleiben wir beim Incident Prozess und sehen uns an, wann der Prozess Zugriff auf die Information einer CMDB benötigt. Dazu nehmen wir einen Standardfall aus dem IT Support als Beispiel:

Der Incident

Ein Anwender meldet sich beim Service Desk und meldet eine Druckerstörung. Der Service Desk Mitarbeiter im 1st Level nimmt die Daten des Anwenders in OTRS auf, ebenso jene des Druckers. Beides wird im Ticket vermerkt. Der Druckername wird als Link zur i-doit CMDB hinzugefügt.

 

Der Change Request bzw. Reparaturauftrag

Ein Change Request in OTRS wird eröffnet, sowohl das i-doit Objekt als auch der ursprüngliche Incident werden mit dem Ticket verbunden, und als Empfänger dieses nun zum Reparaturauftrag mutierten Tickets wird die Wartungsfirma eingetragen. Die automatisch versandte Nachricht an den Service Provider enthält alle notwendigen Daten, um den Drucker zu finden (Druckername, Modell, Seriennummer, Stockwerksangabe, genauer Standort, lokaler Ansprechpartner), dazu auch den aktuellen Zählerstand, der online abgefragt wird, und natürlich Ticketnummer und Ansprechpartner im Service Desk. Der Vollständigkeit halber wird in der CMDB der Status des Druckerobjekts auf “In Reparatur” gesetzt – das zeigt allen KollegInnen, dass keine weitere Recherche oder Aktion erforderlich ist.

 

Die Vermeidung weiterer Unterbrechungen

Um nun weitere Anwender über die bereits beauftragte Reparatur zu informieren, soll diese allgemein zugänglich kenntlich gemacht und die alternativen Drucker mitgeteilt werden. Ziel ist auch hier wieder: Möglichst wenig Arbeitsunterbrechung für Anwender. Dazu wird der Störungsfall als PDF ausgedruckt und der Standort von alternativen Druckern beigefügt. Dieses Dokument sendet der Service Desk Mitarbeiter dem Einmelder des Incidents per e- Mail zu, mit der Bitte, diesen am Drucker gut sichtbar anzubringen.

Information über erfolgte Reparatur

Nachdem der Drucker repariert wurde, wird der Change Request geschlossen und der Status des i-doit Objektes wieder auf “in Betrieb gesetzt”.

Der Workaround

Durch Recherche in der Dokumentation wird einerseits der aktuelle Status festgestellt. Dieser lautet noch “in Betrieb”, es ist also noch keine Störung gemeldet worden. Die Zugangsinformation zum Drucker wird ausgehoben und der Fehler verifiziert. Nachdem mit dem Anwender geklärt wurde, dass es sich anscheinend um einen nicht durch den Anwender behebbaren Fehler handelt, wird das Druckerobjekt in i-doit als “Defekt” gekennzeichnet. Nun wird ein funktionierender Drucker als Alternative gesucht. Dazu wird die Standortinformation in i-doit verwendet und weitere verfügbare Drucker gesucht. Die Daten des alternativen Druckers werden dem Anwender direkt am Telefon mitgeteilt. Damit kann das Incident Ticket mit Workaround geschlossen werden, denn der Anwender kann wieder drucken.

 

Z

Problem Management

Nun beginnt die Arbeit, um die Reparatur des Druckers durchzuführen. Eine kurze Recherche durch Aufruf der Druckerseite (dazu hilft uns wieder die Integration von i-doit und OTRS) und der Homepage des Herstellers beschreibt den Fehler, daher wird auf das Anlegen eines Problem Tickets verzichtet – es ist keine aufwendige Recherche nötig.
Weitergehende Informationen über Servicevertrag oder Ansprechpartner werden der Dokumentation in i-doit entnommen. Da ein aktueller Servicevertrag besteht, kann direkt mit dem Servicepartner per e-Mail kommuniziert werden. Meist ist eine Reparatur binnen 5 Arbeitstagen vertraglich zugesichert.

 

Das Nachvollziehen in der CMDB

Fragen Anwender am Service Desk nach dem aktuellen Status der Reparatur, oder meldet sich der Wartungstechniker mit Neuigkeiten, muss nurmehr der Druckername, der allen Beteiligten Personen bekannt ist, genannt werden. Über den Einstieg in die CMDB findet man einerseits den Status “In Reparatur”, als auch den noch offenen Change Request in OTRS mit allen Informationen und der nachvollziehbaren Geschichte des Servicefalls.

 

Weitergedacht: Livedaten aus dem Monitoring

Liegt die Ursache in der Infrastruktur, wird diese zumeist von einem Monitoringsystem festgestellt. Hier können mit einer weiteren Kopplung viele Arbeitsschritte eingespart werden:

Nicht die Störung, die vom Anwender gemeldet wird, löst das erste Ticket aus, vielmehr wird automatisch ein Ticket aus dem Monitoringsystem eröffnet. So kann ein Techniker bereits an der Störung arbeiten, bevor ein Anwender überhaupt merkt, was los ist.

Ebenso ist die Kopplung von Ticketsystem und CMDB vorteilhaft: Der Status wird an das entsprechende Objekt in der CMDB weitergegeben, damit können sowohl die Auswirkung einer Störung, als auch Alternativen frühzeitig überblickt werden.

Wie geht es weiter?

In diesem Artikel haben wir uns mit den Grundlagen und den wichtigsten Anwendungsfällen beschäftigt.  In einem weiteren Artikel sehen wir uns die verfügbaren i-doit OTRS Schnittstellen an.

Frühling in der Knowledge Base

Frühling in der Knowledge Base

Nach einem langen, grauen Winter scheinen die ersten Frühlingsstrahlen durch unsere Bürofenster. Die ersten Knospen sprießen, die Vöglein zwitschern … auch unsere Knowledge Base wächst und gedeiht wie eh und je. Es ist wieder Zeit für einen Rundumschlag:
Was gibt es Spannendes zu entdecken?

Neu: “Kategorien und Attribute”

 

i-doit bringt bereits über 200 vordefinierte Kategorien mit. Daraus resultieren über 1000 Attribute, die theoretisch pro Objekt dokumentiert werden können. Diese Fülle führt zwangsläufig zu der häufig gestellten Frage: „Wofür ist die Kategorie XY mit all ihren Attributen gedacht?“ Es geht also darum, welche Konzepte hinter jeder einzelnen Kategorie und jedem einzelnen Attribut stecken.

In der Knowledge Base weiterlesen …

 

Neu: “Sicherheit und Schutz”

 

Die IT-Dokumentation umfasst in vielen Fällen sehr sensible Daten, die geschützt werden müssen. In diesem Artikel beleuchten wir, welche Schutzmechanismen greifen, um eine Installation von i-doit abzusichern. Insbesondere arbeiten wir auf die Schutzziele Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität und Autorisierung hin.

In der Knowledge Base weiterlesen …

 

Erweitert: “API (JSON-RPC)”

 

Die Programmierschnittstelle von i-doit wird immer beliebter, wie wir durch fortwährendes Feedback feststellen dürfen. Neben einem ausführlichen Beispiel, wie eigene Scripts mit der API kommunizieren, haben wir nun mit einer Sammlung von Clients und Libraries begonnen. Wer erfindet schon das Rad gerne neu?

In der Knowledge Base weiterlesen …

 

Erweitert: “JDisc Discovery”

 

JDisc Discovery ist eine mächtige Software zum Inventarisierung. Kein Wunder, dass viele unserer Kunden diejenigen Daten, die JDisc automatisiert findet, in i-doit importieren. Der Artikel geht unter anderem auf die umfangreichen und flexiblen Import-Profile ein.

In der Knowledge Base weiterlesen …