Blog-Reihe: „Houston, wir haben ein Problem“ (IT-Support. Teil 1)
Oxana MartevaiaNachdem wir in der vorangegangenen Blogserie eine eigene Banking-IT aufgebaut haben, bleibt nun die Frage, wie man eigentlich diese ganzen Systeme ordentlich am Laufen hält. Die Antwort heißt natürlich: Tech Support!
Aber wie organisiert man den IT-Support für die vielen verschiedenen Applikationen und Systeme, die eine Bank am Laufen halten? „ITIL“ lautet das Zauberwort!
Information Technology Infrastructure Library (ITIL) steht für eine Sammlung von sogenannten „Best Practice“-Ansätzen, also Konzept-Ideen, die sich in der Praxis bewährt haben. ITIL ist keine Norm oder Vorschrift, wie man einen IT-Service organisieren muss – aber die dort zusammengetragenen Ideen haben sich eben bewährt.
Astronaut Jim Lovell hat die durch sein Film-Pendant Tom Hanks geäußerten Worte „Houston, wir haben ein Problem“ tatsächlich so nie gesagt. Besser könnte man jedoch aber die Arbeit in einem IT-Support gar nicht beschreiben – bis auf eine Kleinigkeit: Im Jargon von ITIL würde man den lauten Knall verbunden mit dem Druckverlust der O2-Tanks an Bord von Apollo 13 nicht als „Problem“, sondern als „Störung“ (engl. „Incident“) bezeichnen.
Incident und Problem sind zwei grundlegende Begriffe, wenn man IT-Support verstehen will. Ein Incident ist definiert als eine Störung oder als Verminderung der Qualität eines vorher vereinbarten IT-Services. Also, wenn zum Beispiel das Online-Banking-Portal unser neu gegründeten Bank für die Kunden nicht verfügbar ist, sprechen wir hier von einer Störung. Die Quintessenz des Incident-Managements ist es, den IT-Service möglichst schnell wiederherzustellen – wenn nötig mit Spucke und Klebestreifen, Hauptsache es läuft wieder!
Erst im Nachgang, wenn der Service wiederhergestellt ist, stellt sich die Frage, wie es überhaupt zu der Störung kommen konnte und wie man sie zukünftig vermeiden kann – das ist die Aufgabe des Problem-Managements.
Ein „Problem“ ist die eigentliche Ursache („root cause“) für die aufgetretene Störung. Wenn wir im Zuge unserer Untersuchungen feststellen, dass es zur Störung des Online Bankings kam, weil im Rechenzentrum jemand über das Kabel gestolpert ist, das unsere Server mit dem Internet verbindet (eine zugegebenermaßen sehr plastische Vorstellung), dann muss das Problem-Management darin bestehen, die Kabelverbindung so zu verlegen, dass dies in Zukunft nicht mehr auftreten kann. Wenn dazu aber umfangreichere Umbauarbeiten im Rechenzentrum nötig sein sollten, die längere Zeit erfordern, kann man bis zur endgültigen Lösung des Problems einen zeitweiligen „Workaround“ definieren – in unserem Fall müsste dieser lauten: „Wenn du über das Kabel gestolpert bist, steh auf, klopf dir den Staub ab und steck so schnell wie möglich das Kabel wieder in den Server! Oder besser noch: Steck erst das Kabel wieder in den Server und klopf dir dann den Staub ab!“
Incident- und Problem-Management werden durch ein dezidiertes Knowledge-Management abgerundet, um bekannte Fehlerszenarien und deren Workarounds und Lösungen richtig zu dokumentieren, so dass man im Fall einer erneut auftretenden Störung schnell an die nötigen Informationen kommt, um den Service wiederherzustellen.
Im zweiten Teil dieser Blogreihe werden wir uns mit der RTB/CTB-Konzepte und moderne, agile Verfahren, wie z.B. SCRUM oder DevOps, die zur Optimierung der Zusammenarbeit zwischen Entwicklung und Betrieb dienen, auseinandersetzen.
Quellen:
Kommentare
Popular Posts
