„Wenn die Bundeswehr und das Technische Hilfswerk ausrücken, weil die Feuerwehr das Problem nicht in den Griff bekommt – dann sprechen wir von einem Major Incident.“ – Johannes Born, Born IT Consulting.
Neulich stand einer meiner Kunden vor einem Major Incident – und niemand erkannte die drohende Gefahr.
Rückblende: Den Engineers ist schnell klar, was gerade passiert: Die genutzte Virtualisierungsumgebung hat Schwierigkeiten und steht kurz vor dem Kollaps.
Den Engineers ist auch klar, was das für sie bedeutet: Sie können nicht normal weiterarbeiten und ärgern sich darüber.
„Eigentlich wussten wir, was da passiert, aber ….“
Allerdings übersehen sie ein „kleines“, aber entscheidendes Problem: Wenn die Virtualisierungsumgebung auf die Bretter geht, dann
- stehen einige tausende Endanwender von jetzt auf gleich ohne funktionierende Systeme da,
- sind viele Geschäftsprozesse gestört,
- haben viele Produktteams einen Desaster Fall, teilweise mit Datenverlust und
- können Kunden nicht mehr mit dem Unternehmen interagieren.
In ihrer Arbeit vertieft übersehen die Engineers also den nahenden Blackout des Gesamtsystems – und der Platform Owner versteht die Welt nicht mehr.
Warum wir Monitoring als Lösung sofort ausgeschlossen haben
Im darauffolgenden Postmortem schauen wir uns genau an, was da passiert ist.
Die Management Summary aus dem Post Mortem
„Ein Partnerteam spielte unangekündigt einen Patch ein. Das ging schief und führte dazu, dass sich der Cluster in einem instabilen Zustand befand. Die fehlenden Meldungen und der instabile Zustand des Clusters sorgten für den Major Incident im Platform Team. Eine Auflösung der Situation erfolgte erst 4 Stunden später.“
Die Analyse zusammengefasst
Sofort kommen von allen Seiten die Rufe nach einem besseren Monitoring. Doch hätte uns das geholfen?
Schauen wir uns genau an, was passiert ist.
Dafür nutzen wir die Finding-Phase meines Postmortem-System und gehen die 5 Kategorien durch:
Detektion: Die Engineers haben sofort festgestellt, dass etwas nicht nach Plan lief. Also starteten Sie den Incident Prozess und gingen in die Fehleranalyse.
Identifikation: Bei der Fehleranalyse erkannte das Plattform Team, dass es sich wirklich um einen Incident handelt und dieser Incident außerhalb ihres Einflussbereichs liegt. Außerdem stufte das Plattform Team den Incident als Arbeitsverhindernd ein.
Reaktion: Das Team eröffnete ein Ticket beim Partnerteam, dass den Infrastruktur-Dienstleister steuert. Das Partnerteam informierte den Infrastruktur-Dienstleister allerdings erst zwei Stunden später, da unser Team die Situation als Arbeitsverhindernd und nicht als Betriebskritisch wahrgenommen und kommuniziert hat.
Prävention: Hier gab es für das Plattform Team nichts zu tun, weil es sich außerhalb des Einflussbereichs des Teams befindet.
Kommunikation: An dieser Stelle stolperte das Team – die Identifikation des Incidents als Arbeitsverhindernd und die darauffolgende zaghafte Kommunikation. Dadurch war weder dem Partnerteam noch dem Infrastruktur-Dienstleister das wahre Ausmaß der Notsituation der Plattform bewusst.
Das zeigt: Auch wenn es viele meiner Kunden nicht wahrhaben wollen – die meisten ihrer Incidents werden nicht durchs Monitoring, sondern durch ihre Prozesse gelöst.
Die Identifikation des Incidents über die reine Technik hinaus und die oft zaghafte Kommunikation sorgen für unnötige Notsituationen.
Die Geschichte geht noch weiter – die Überreaktion
Im Postmortem legen wir also eine zentrale Maßnahme fest: Das Platform Teams erweitert den bestehende Incident Prozess, sodass der Dispatcher einen Major Incident „mit verbundenen Augen“ erkennt und als solchen behandelt.
Externe Komponenten, deren Ausfall die Plattform gefährden
Dafür nutzen wir das Architekturbild und identifizierten alle kritischen Komponenten von Partnern, deren Ausfall einen Major Incident in der Plattform auslösen kann. Typische Beispiele sind hier:
- DDI (DNS, DHCP, IPAM)
- NTP (Zeitserver)
- Netzwerk, Firewalls, Routing
- Virtualisierungsumgebung und Cloud
- Container Registry
- Git-Server
- …
Plattform-Komponenten, die bei den Produktteams einen Incident auslösen
Dann gehen wir noch einen Schritt weiter und schauen uns an, welche der angebotenen Komponenten bei den Produktteams einen Major Incident auslösen.
Auch hier ergibt sich eine Liste:
- Service Mesh
- Eventing-Infrastruktur
- CI/CD Services
- Observability Services
- Backup-Lösung
- CVE-Scanner
- …
Dabei fällt uns auf: Das Platform Team stuft alle Komponenten als Betriebskritisch für die Produktteams ein. Und es gibt keinen Unterschied zwischen den verschiedenen produktiven Clustern – den Entwicklungs-, Test- und Produktionsclustern.
Wenn alles ein Major Incident ist, dann gibt es keinen Major Incident
Schnell kommt das Team dann selbst darauf: Wenn es alles als Major Incident klassifiziert, was ist dann ein Incident?
Unsere (Neu-)Definition des Begriffs Major Incident
Der Zweck der Auflistung der betriebskritischen Komponenten ist es, dem Dispatcher ein Entscheidungsinstrument in die Hand zu geben. Der Dispatcher soll sofort erkennen, ob es sich um einen Major Incident oder um einen Incident handelt.
Das Platform Team hat bereits einen funktionierenden Incident Prozess. Die wichtige Erkenntnis für das Team ist also: Ein Major Incident wird nicht schneller bearbeitet als ein Incident. Der Major Incident hat nur drei wichtige Ergänzungen:
- Priorität: Ein Major Incident hat immer Vorrang. Zur Not bleibt die Weiterentwicklung und andere Incidents liegen.
- Kommunikation: Bei einem Major Incident wird flächendeckend kommuniziert. Es müssen mindestens die Produktteams und die IT-Leitung informiert und auf dem laufenden sein.
- Laut: Bei einem Major Incident muss der Platform Owner „lautstark“ alarmiert werden, sodass dieser die Kritikalität erkennt und entsprechend handelt.
Vom Arbeitsfluss der Engineers her wird ein Major Incident wie ein normaler Incident im gleichen Incident Management-Prozess bearbeitet.
Die Auswirkungen dieser Neudefinition
Die Neudefinition des Major Incidents sorgt für Klarheit. Die meisten der vom Platform Team bereitgestellten Komponente sind nicht Betriebskritisch. Jeder Ausfall einer Komponente muss über den Incident-Prozess laufen. Ausfälle von Betriebskritischen Komponenten müssen und zu Ausfällen der Plattform oder der Services der Produktteams führen können, müssen zusätzlich sofort und lautstark kommuniziert werden.
Das betrifft aber nur die Ausfälle, die eine unmittelbare Gefahr für die Produktion darstellen. Alle anderen werden ruhig, besonnen und zügig repariert und dann kommuniziert.
Die Klarheit darüber, was Betriebskritisch – und vor allem, was nicht Betriebskritisch ist – hat zu einem Effizienzbooster im Platform Team geführt.
Alle Entscheidungen über die Kritikalität werden nun direkt am Eingang vom Dispatcher anhand der genannten Kriterien getroffen – und wenn er ausnahmsweise falsch liegt, wird der Incident einfach umklassifiziert und entsprechend kommuniziert.
Sie können sich nicht vorstellen, wie ruhig plötzlich das Alltag des Platform Owners ist. Das Incident-System ist nun so ausgereift, dass er sich 100% darauf verlassen kann – und das ohne „besseres Monitoring“.
Wie Sie mit 3 einfachen Schritten Ihren Incident Prozess um Major Incidents erweitern?
Drei Schritte reichen Ihnen, um Ihren Incident Prozess um Major Incidents zu erweitern.
Schritt 1: Identifikation standardisieren
Wir Platform Owner arbeiten mit hochintelligenten Menschen zusammen, denen nur wenige etwas vormachen können.
Diese Stärke hat allerdings einen gravierenden Nachteil: Unsere Platform Engineers sind voll auf die technischen Lösungen fokussiert und verlieren dadurch gerne den Überblick über das große Ganze – und das Verhalten ist gewollt, damit sie effektiv und effizient an den Lösungen arbeiten können.
Mit einem guten Incident-Prozess lässt sich diese vermeintliche Schwäche einfach in den Griff bekommen.
Ihr Platform Team braucht Klarheit über die kritischen Komponenten. Damit kann der Dispatcher schnell erkennen, ob ein Incident Betriebskritisch oder „nur“ unangenehm ist.
Sobald der diensthabene Dispatcher über diese Information verfügt, kann er die Kritikalität eigenständig entscheiden und damit dem restlichen Platform Team und dem Platform Owner viel Zeit und Nerven sparen.
Schritt 2: Kommunikation klären
Wir Platform Owner und unser Platform Team sind sehr gut darin, im Maschinenraum alles in Gang zu halten. Wenn allerdings etwas Unerwartetes auftritt, ist uns oft nicht klar, wer in welcher Form wie und wann benachrichtigt werden muss.
Genau dieses Problem lässt sich mit einem Incident-Drehbuch einfach lösen. Dort steht genau beschrieben, wer was zu tun hat und welche Kommunikation in welcher Form stattfinden muss.
Dadurch vermeiden Sie unnötige Abstimmungen und sind gut auf das Unerwartete vorbereitet.
Schritt 3: Üben, üben, üben…
Jetzt gilt es, die neuen Abläufe einzuüben – denn nichts ist schädlicher als ein dokumentierter, nicht gelebter Prozess.
Dabei ist wichtig: Es muss nicht von Anfang an alles reibungslos klappen – dafür machen Sie ja die Feuerwehrübungen. Wichtig ist für Sie, Schwächen im Prozess zu erkennen und zu beheben.
Dafür eignen sich verschiedene Formate:
- Szenarien und Feuerwehrübungen, die Sie mit Ihrem Team durchspielen
- echte Fälle aus der Vergangenheit, die sie in Form von Postmortem-Analysen aufarbeiten
- jeder neue Incident, der direkt als Beispiel herhalten darf
So gelangen Sie schnell in den täglich gelebten Prozess und entlasten sich und Ihr Team.
Falls Sie neugierig geworden sind und erfahren möchten, wie Sie Ihre Major Incidents möglichst geräuschlos in Ihren Incident Prozess einbetten können, dann melden Sie sich gerne bei mir.
Wir schauen uns gemeinsam in einem 1-Stündigen Termin Ihren Incident Prozess an, finden gemeinsam eine Lösung und vereinbaren Ihre konkreten nächsten Schritte.
Und falls Sie noch keinen gelebten Incident Prozess haben? Dann lassen Sie uns darüber sprechen – ich garantiere Ihnen, dass wir eine gute und vor allem schlanke Lösung finden werden.
Bis dahin wünsche ich Ihnen viel Erfolg als Platform Owner.