Ich sitze gerade im Zug nach Stuttgart. Nichts geht mehr – der Zug steht. Der einbrechende Eisregen hat das Schienensystem lahmgelegt. Zum Glück habe ich einen Platz mit Aussicht: Auf dem nahen Fabrikgelände bemüht sich ein Gabelstaplerfahrer nach Kräften, einen Kleincontainer bei wildem Schneetreiben aufzuladen. Der Gabelstapler ist offen und das verzerrte Gesicht des Steuermannes verrät, dass es da draußen ziemlich kalt ist. Im wohltemperierten Halleneingang stehen zwei Arbeiter, die ihrem Kollegen über die Ferne etwas zurufen und es offensichtlich besser wissen als er. Unweigerlich muss ich an den typischen Rechenzentrumsbetrieb denken.
Hier verhält es sich meistens so, dass im Verhältnis 2:1 auf denjenigen eingeredet wird, der so viel Hintern in der Hose hat, um die ganzen Befehle auf das Produktivsystem abzufeuern. Mit dem nötigen Druck geht das dann sicher schief. Ein Leitfaden zur Wiederherstellung eines Systems wäre jetzt hilfreich gewesen, ein Testsystem auch – das stellt jetzt sogar der arme Admin fest. Jetzt ist es nachts um drei, aber immerhin steht jetzt keiner mehr hinter ihm. Nun ist seine Müdigkeit verantwortlich für die vielen Fehler. Was für ein Tag! Dabei war es nicht mal er, der die Meldung über den ausgefallenen IT-Service vom Kunden entgegennahm. Aber was hilft es schon, sich zu beschweren – wahrscheinlich wurde die Anforderung zur Einrichtung eines entsprechenden Checks wieder per Mail an einen der vielen Burnout-geschädigten Langzeitkranken gesendet.
Reflexartiger Gedanke: Da muss man mal ITIL einführen! Aber ITIL alleine schützt vor solchen Situationen nicht. Das Niederschreiben von Prozessen bedeutet nämlich nicht, dass sie auch gelebt werden. Oft wird ITIL nur zur Absicherung eingeführt und verfolgt wenig praktischen Bezug. ISO-Zertifizierungen bekommt man damit auf jeden Fall – einen stabilen IT-Betrieb nicht zwangsläufig. ITIL ist eine Bibliothek von Best Practices, also Empfehlungen, wie man mit seinen IT-Prozessen idealerweise umgehen sollte. Aber eine Prozessbeschreibung ist aufwändig. Und wir alle wissen, dass viel Text deshalb aufgeschrieben wird, weil man nicht alles behalten kann. Merken Sie was?
Was der arme Admin braucht, ist IT-Steuerung. Um IT aktiv zu steuern, benötigen Sie IT-gestützte Prozesse. Aber was heißt das eigentlich? “Tools einführen” ist out. Man implementiert Arbeitsvorgänge, die über miteinander integrierte Applikationen gestützt werden. Die Werkzeuge folgen dem Prozess und nicht die Prozesse dem Werkzeug. Und das bedeutet: IT-Mitarbeiter müssen keine ITIL-Handbücher mehr lesen, weil sie aus einer entsprechenden Vorgehensweise nicht ausbrechen können. Die Tools geben nämlich die Arbeitsvorgänge vor. Dieser Ansatz setzt natürlich eine hohe Flexibilität der jeweiligen Applikationen voraus. Also ein Heimspiel für Open Source.
Klingt zu einfach? Ok, hier ein Anwendungsbeispiel, das unserem eingangs erwähnten Admin geholfen hätte:
Ein zentrales Monitoring-System meldet zielgerichtet eine hohe Antwortzeit eines SAP-Dienstes an das Ticketsystem. Das funktioniert deshalb so gut, weil die in der Configuration Management Database gepflegten Servicebäume mit den Host- und Service-Abhängigkeiten des Überwachungssystems automatisiert abgeglichen werden. Der Helpdesk-Mitarbeiter sieht das Ticket und wird sofort aktiv. Er grenzt den Fehler mit einem Blick auf die Monitoring Dashboards ein. Durch die zentrale Servicedokumentation mit entsprechenden Wiederherstellungsplänen kann der 1st Level Support eine Workorder an das Provisioning-Team stellen. Das passiert über das im Ticketsystem integrierte Changemanagement. Das Provisioning-Team bringt eine neue virtuelle Maschine aus, die einen Teil der Last des problematischen Dienstes übernimmt. Im Hintergrund wird die neue VM übrigens direkt ins Monitoring eingebracht und im ITSM eine Aufgabe angelegt, dass ein Wiederherstellungsplan angelegt werden muss. Daran wird der Admin zwei Mal erinnert, bis sein Manager diese Info erhält.
Ohne zu übertreiben: Open Source macht den Traum von Prozesssicherheit durch Automatisierung möglich – ganz ohne eisige Kostenstürme in innovationsfeindlichen Umgebungen. Das erwähnte Beispiel ist keine Vision, sondern gelebte Realität bei uns im Unternehmen. Wer es sich mal anschauen möchte, ist herzlich eingeladen.
