1984 sang Herbert Grönemeyer den Song: „Wann ist ein Mann ein Mann?“.
Auch wenn ich dem Lied sonst nicht viel abgewinnen kann – in dieser einen Zeile steckt so viel Tiefe: „Wann ist ein Incident (wirklich) ein Incident“?
Diese Frage schlüssig zu beantworten – daran verzweifeln viele Platform Owner. Unnötig, wie ich meine.
Das Ergebnis dieser fehlenden Definition ist für Sie als Platform Owner häufig unangenehm:
- Incidents werden nicht als solche erkannt oder Ihr Team reagiert zu spät.
- Die Qualität der Incident-Behandlung hängt ausschließlich an der Tagesform des Bearbeiters.
- Bekannte Probleme oder technische Schulden, die Sie bewusst eingehen, werden als Incident in Ihren Betriebsprozess eingesteuertund versucht zu lösen.
- Probleme außerhalb Ihres Kontrollbereichs landen bei Ihnen und belasten unnötig ihr Team.
- Wichtige Entscheidungen warten auf Sie als Platform Owner, sodass Sie den Flaschenhals bilden.
Die Crux an der Geschichte: Diese unnötigen Hindernisse lassen sich mit einer guten Vorbereitung einfach vermeiden. Dadurch gewinnt Ihr Team Entwicklungszeit, liefert durchgängig eine gute Qualität und trifft alle relevanten Entscheidungen in Ihrem Sinne.
Und es gibt noch einen weiteren Vorteil: Ihr Team gewinnt Selbstvertrauen und wird sich ohne Ihr Zutun besser organisieren.
Klingt zu gut, um wahr zu sein? Lassen Sie es uns herausfinden.
Inhalt
Incident ist nicht gleich Incident
Im Laufe der Jahre bin ich mit all meinen Kunden an den Punkt gekommen, an dem der Platform Owner folgende Fragen beantworten musste:
- In welchen Fällen ist ein Verhalten der Plattform ein Incident?
- Und wann nicht? Was ist also kein Incident? Und was ist es stattdessen?
Obwohl alle meine Kunden der Meinung waren, dass ein Incident eindeutig ist und vom Team als solcher erkannt werden kann, kam am Ende bei jedem eine andere, kontextspezifische Definition heraus. Und wir stellten oft fest, dass die Definition des Platform Owners stark von der Intuition der Platform Engineers abwich.
Eine der Leitfragen, mit der Sie den minimal tragfähigen Incident Prozess aufbauen, lautet: „In welchen Fällen sprechen Sie von einem Incident?“
In diesem Artikel erhalten Sie das passende Werkzeug, die Incident-Landkarte, mit dem Sie zukünftig eine klare Definition eines Incidents für Ihre konkrete Plattform parat haben. So müssen Sie sich zukünftig nicht mehr nur auf die Intuition und die Tagesform Ihrer Platform Engineers verlassen.
Geben Sie mir 5 Minuten und sie erfahren …
- was ein Incident wirklich ist,
- welche 5 Facetten von Vorfällen Sie meiner Erfahrung nach beachten sollten und
- welche 3 Schritte sie gehen können, um eine Incident-Landkarte zu erstellen, sodass Ihre Platform Engineers Incidents zuverlässig erkennen und behandeln.
Überblick: Incidents, Bugs, Problems, Known Issues, Technische Schulden, … Wie unterscheiden sie sich?
Störungen oder Vorfälle (Incidents), Bugs, Probleme (Problems), bekannte Probleme (Known Issues) und technische Schulden sind eng miteinander verzahnt. Leider werden sie oft synonym verwendet, was für Verwirrung statt Klarheit sorgt. Und Verwirrung ist etwas, was wir in sauberen Prozessen am wenigsten brauchen können.
Deshalb hier ein Überblick über die verschiedenen Themengebiete:
- Störung/Vorfall: nicht geplante Unterbrechung oder Qualitätsminderung des Services
- Bug: Ein Softwarefehler. Er kann unter den richtigen Voraussetzungen einen Vorfall auslösen.
- Problem: Ist das Symptom eines Vorfalls vorübergehend identifiziert und beseitigt, die Ursache aber noch nicht behoben, wird die Behebung als Problem weitergeführt.
- Known Issues: Besteht bei einemProblem aus Produktsicht kein dringender Handlungsbedarf, dann kann dieses Fehlerbild als Known Issue erfasst werden. Vielleicht wird das Problem irgendwann behoben, vielleicht aber auch nicht.
- Technische Schulden: Wird ein Problem bewusst eingegangen, dann handelt es sich um eine technische Schuld, die entweder irgendwann beglichen wird oder als Known Issue weitergeführt wird.
In diesem Artikel beschäftigen wir uns ausschließlich mit Incidents, also Störungen bzw. Vorfällen.
Definition eines Incidents nach ITIL v4
So sehr es in der IT-Welt sowohl gehasst als auch und geliebt wird – wenn es um IT Service Management geht, kommen Sie an ITIL nicht vorbei. ITIL ist eine Sammlung an Best Practices, die sich in diversen Unternehmen und Behörden bewährt haben. Dort findet sich folgende Definition zum Thema Incident/Vorfall:
„Eine nicht geplante Unterbrechung eines Service oder eine Qualitätsminderung eines Service.“
So weit, so einfach. Und dennoch so uneindeutig.
Wie Sie als Plattorm Owner sicher bereits festgestellt haben, gibt es zwei Unschärfen in dieser Definition:
- Was genau ist eine Unterbrechung des Services?
- Wie ist die Qualität definiert, sodass Sie von einer Qualitätsminderung ausgehen können?
Was ist ein Incident? – Ihre Entscheidungen als Platform Owners
Jetzt sind Sie gefragt! Diese Fragen können nur Sie als Platform Owner seriös beantworten, weil Sie dafür einige Produktentscheidungen treffen dürfen. Vor dem Hintergrund Ihrer neuen Entscheidungen werden sie dann mit Sicherheit auch Ihre bereits getroffenen Entscheidungen noch einmal überdenken und bei Bedarf anpassen.
Aber keine Sorge – es ist eine spannende Perspektive auf Ihr Produkt, sodass Sie einen ganz besonderen Einblick in Ihre Entwicklerplattform erhalten.
Aber was genau ist jetzt eine nicht geplante Unterbrechung des Services? Und wann genau ist die Qualität eines Services eingeschränkt?
Warum ich Ihnen empfehle, ins Detail zu gehen
Global lassen sich diese Fragen leider nur sehr oberflächlich beantworten. Oberflächliche Antworten führen, wie Sie ja bereits wissen, zu einem hohen Interpretationsspielraum. Dieser Spielraum führt dazu, dass Sie ihrem Team einen Bärendienst erweisen – Ihre Teammitglieder müssen Ihre Arbeit miterledigen. Dies wird jeder nach seinem eigenen Ermessen tun.
Damit haben sie neben einem Zeitverlust auch massive Qualitätsunterschiede in der Bewertung, je nachdem wer zu welcher Zeit gerade die Bewertung vornimmt. Im schlimmsten Fall delegieren Ihre Teammitglieder die Arbeit einfach zurück an Sie und Sie müssen spontan eine Entscheidung treffen.
Kein guter Zustand, denn Sie haben viel wichtigere Aufgaben und werden dadurch zum Flaschenhals im Prozess.
Einfacher und präziser wird es für Sie, wenn Sie es Ihren Teammitgliedern so einfach wie möglich machen, die richtige Entscheidung zu treffen.
Dafür lohnt sich für die meisten Platform Owner in der Regel der einmalige Aufwand, sich mit den verschiedenen Facetten der ungeplanten Unterbrechung beschäftigen und auf der Basis Ihre Incident-Landkarte erstellen.
Sie können sich dann darauf verlassen, dass Ihr Team die Entscheidungen in Ihrem Sinne treffen, ohne Sie zu behelligen. Zusätzlich erhalten Sie eine gleichbleibend hohe Qualität der Incident-Bearbeitung.
Wenn ich mich dem Thema annähere, nutze ich immer die folgende Liste.
Die 5 Facetten der ungeplanten Unterbrechung
Incidents lassen sich grob in 5 Kategorien einteilen:
- Technische Infrastrukturprobleme, z.B.
- Hardwareausfälle
- Netzwerkprobleme
- Kapazitätsengpässe
- Softwarebedingte Störungen, z.B.
- Softwarefehler
- Konfigurationsfehler
- Dateninkonsistenzen
- Schnittstellenprobleme
- Verfügbarkeitsstörungen, z.B.
- Komplettausfälle
- Teilausfälle
- zeitweise auftretende Störungen
- Performanceprobleme, z.B.
- Verlangsamung der Services
- Überlastung durch hohe Nachfrage
- Sicherheits- und Integritätsvorfälle, z.B.
- Sicherheitsvorfälle (unbefugter Zugriff, Datenlecks)
- Änderungsbedingte Störungen
- Probleme mit externen Abhängigkeiten
Die 5 Facetten geben Ihnen bereits einen guten Überblick über die verschiedenen Formen der Vorfälle, die als Incident in Frage kommen.
Wie Sie mit den 5 Facetten arbeiten – In 3 Schritten zur Incident-Landkarte
Wenn ich mit Ihnen einen Workshop durchführe, bei dem wir gemeinsam eine eindeutige Definition von Incidents erstellen, dann ist der Ablauf immer der folgende:
Schritt 1: Incident-Brainstorming
Wir schauen uns gemeinsam die 5 Facetten der Incidents an und besprechen jeden einzelnen Punkt. Optimalerweise haben Sie bereits ein Architekturdiagramm und ein Entscheidungslog, mit dem sich arbeiten lässt. Aber selbst, wenn sie keins haben, können wir gemeinsam gute Ergebnisse erzielen.
Im Brainstorming gehen ist sogenanntes divergentes Denken angesagt. Divergentes Denken ist eine Methode, bei der die Teilnehmer sich keine Grenzen setzen. Es geht nur darum, möglichst viele Anknüpfungspunkte zu sammeln, ohne sich bereits am Anfang künstlich zu beschränken und dadurch einzuschränken.
Das Motto lautet: Lieber zu viel sammeln als etwas Wichtiges vergessen.
Wir sammeln also möglichst viele mögliche Incidents und orientieren uns dabei grob an den 5 Facetten.
Schritt 2: Filtern: Incident oder kein Incident
Nun gehen wir gemeinsam durch alle Incidents und Sie entscheiden, ob es sich dabei wirklich um einen Incident handelt oder nicht. Wenn Sie mögen, ist die Liste „kein Incident“ ein perfekter Startpunkt, um technische Schulden und bekannte Probleme zu dokumentieren.
Schritt 3: Gruppieren und Kategorisierung
Nun geht die eigentliche Arbeit los. Ziel dieses Schritts ist es, die im ersten Schritt identifizierten möglichen Incidents zu Gruppen zusammenzuführen und zu kategorisieren.
Anders als im ersten Schritt geht es nun darum, konvergent zu denken. Konkret heißt das, dass wir nun Lösungsorientiert denken und damit eine Incident-Landkarte in Form einer Mindmap erstellen.
Diese Incident-Landkarte können Sie nun Ihren Platform Engineers geben – sie ist Ihre Antwort auf die Frage: „In welchen Fällen sprechen wir von einem Incident?“ und Ihr Startpunkt, sich intensiv mit dem Thema Incident Management zu beschäftigen.
Bonus: Incident-Landkarte auf die Probe stellen und verfeinern
Ihre Landkarte ist an diesem Punkt noch lange nicht perfekt – und das muss sie auch nicht sein. Sie dient Ihren Kollegen als Wegweiser, um schnell Entscheidungen in Ihrem Sinne zu treffen.
Haben Sie bereits in der Vergangenheit ein Incident Management betrieben und die Incident-Landkarte erstellt, um für meht Klarheit zu schaffen, dann haben Sie jetzt die einmalige Gelegenheit, Ihre neu erstellte Wissenslandkarte auf die Probe zu stellen und zu verfeinern.
Geben Sie Ihren Platform Engineers Ihre Landkarte. Geben Sie ihnen zusätzlich eine beliebige Anzahl an bereits bearbeiteten Incidents und lassen Sie die Incidents nach Ihrer Landkarte bewerten.
Sind Sie mit dem Ergebnis Ihrer Platform Engineers zufrieden? Super, dann haben Sie einen wichtigen Schritt in Richtung eines professionellen und tragfähigen Incident-Prozesses geschafft.
Haben Sie noch Verbesserungspotenzial erkannt? Auch super – das sind Ihre wertvollen Erkenntnisse, die Sie in die Landkarte einarbeiten dürfen. In Zukunft werden Ihre Platform Engineers auf dieser Basis sehr präzise entscheiden, ob ein Incident aus Ihrer Sicht ein Incident ist.
Letzte Warnung – Die Prozesse und die Werkzeuge dienen den Menschen, nicht umgekehrt
Wenn sie nur einen Punkt aus diesem Blogbeitrag mitnehmen, dann ist es dieser hier. Es ist meine Herzensangelegenheit, die ich gerne weitergeben möchte.
Alle Werkzeuge und Prozesse, die Sie einsetzen, sollen Ihrem Team, also den Menschen helfen, gemeinsam großartige Arbeit abzuliefern. Das funktioniert nur dann, wenn die Werkzeuge und Prozesse auf das Team abgestimmt sind.
Deshalb ist die kontinuierlichen Feedbackschleifen, der Wissenstransfer und die Anpassung der Prozesse der risikoärmste und kostengünstigste Weg zu einem professionellen Platform Engineering Team.
Ich wünsche Ihnen viel Erfolg bei Ihrer Umsetzung. Sie werden sehr schnell merken, wie wenig Sie sich zukünftig um Ihren Incident-Prozess kümmern müssen.