Minimal tragfähiger Incident Prozess – Worauf es im Platform Engineering wirklich ankommt? Inkl. 33 Leitfragen

Incident Prozesse nerven.

Aber spätestens, wenn die ersten Produktteams mit Ihren Services Ihre Entwicklerplattform betreten, stellen sich alle Platform Owner dieselbe Frage – Wie behandeln wir die Incidents und Fehlerfälle?

Dafür gibt es eine Lösung – den minimal tragfähigen Incident Prozess.

Ich lade Sie deshalb ein, mein bewährtes Vorgehen zu nutzen, mit dem Sie einen einfachen und praktikablen Incident Prozess erstellen, der Ihre Entwicklungsarbeit respektiert.

Garantiert!

Schritt 1: Den Incident Prozess designen

Die folgenden Leitfragen helfen Ihnen dabei, alle Aspekte für Ihren Incident Prozess zu berücksichtigen. So können Sie sicherstellen, dass Sie nichts vergessen:

1. In welchen Fällen sprechen Sie von einem Incident?
2. Wie unterscheiden Sie Incidents und Problems?
3. Wie definieren Sie die Schwere eines Incidents? Welche Kriterien legen Sie an?
4. Wer darf einen Incident melden? Wer darf ihn ausrufen?
5. Wie kommunizieren Sie einen Incident intern?
6. Welche Rollen benötigen Sie in dem Incident-Management-Team?
7. Wie werden diese Rollen besetzt und rotiert?
8. Welche Tools nutzen Sie für die Incident-Dokumentation und -Kommunikation?
9. Welche Kontaktpunkte gibt es? (z.B. Telefon, ServiceDesk, „Hey Joe„)
10. Wie stellen Sie sicher, dass die relevanten Stakeholder informiert werden?
11. Wer sind die relevanten Stakeholder, die informiert werden müssen?
12. Wie informieren Sie Incidents nach außen (an Kunden, Partner und Behörden)? Und wann?
13. Wie oft und in welcher Form geben Sie ein Statusupdate ab?
14. Welche Eskalationsstufen benötigen Sie in dem Prozess?
15. Zu welchem Zeitpunkt und in welcher Art eskalieren Sie einen Incident?
16. Wie prioisieren Sie einen Incident im Verhältnis zur laufenden Entwicklungs- und Standardbetriebarbeiten?
17. Welche Daten benötigen Sie für die spätere Analyse? Wie sammeln sie diese?
18. Welche Metriken nutzen Sie, um den Fortschritt der Incident-Behebung zu messen?
19. Wann ist ein Incident abgeschlossen?
20. Welchen Prozess haben Sie für die Post-Incident-Reviews (z.B. Postmortems, Lessons Learned)?
21. Wie stellen Sie sicher, dass die Learnings aus dem Incident in den Entwicklungsprozess einfließt?
22. Wie dokumentieren und teilen Sie Best Practices aus der Incident Behebung?
23. Wie bereiten Sie sich auf den Incident Fall vor?
24. Wie integrieren Sie ihre Monitoring- und Alerting-Systeme in den Prozess?
25. Wie gehen Sie mit False-Positives des Alerting-Systems um?
26. Gibt es regulatorische Anforderungen, die Sie erfüllen müssen? Wie gehen Sie damit um?
27. Wie integrieren Sie externe Dienstleister und Zulieferer in Ihren Incident Prozess?
28. Wie gehen Sie mit gleichzeitig auftretenden Incidents um?
29. Wie balancieren Sie die schnelle Lösung eines Incidents gegen die Notwendigkeit, Root Causes zu identifizieren und die nötigen Daten zu sammeln?
30. Gibt es Schritte in ihrem Prozess, die Sie in Form eines Drehbuchs standardisieren können?
31. Gibt es bereits Incident Management Strukturen in Ihem Unternehmen, an die Sie sich andocken können oder müssen?
32. Welche Servicezeiten gelten für Ihr Team?
33. Welche Reaktionszeiten müssen Sie einhalten?

Haben Sie diese Fragen beantwortet, folgt Schritt 2 – Verdichten und vereinfachen.

Schritt 2: Den Incident Prozess verdichten und vereinfachen

Haben Sie all diese Fragen beantwortet, ergibt sich ein erstes, vages Bild davon, wie Sie Ihre Incidents behandeln möchten.

Viele machen jetzt den Fehler, auf dieser Basis bereits einen Prozess zu Papier zu bringen und dann die Nutzung einzufordern.

Das Argument: Lieber schnell und vollständig starten und dabei iterativ etwas streichen, als später etwas zu vergessen.

So bestechend dieses Argument ist – es passt nicht zur menschlichen Natur.

Wir Menschen, vor allem Ihre kreativen Platform Engineers, brauchen einfach zu befolgende Abläufe, damit wir uns auf den hochkreativen Prozess der Entstörung eines Incidents konzentrieren können. Denn am Ende zählt vor allem eins: Es ist wichtiger, den Incident schnell und nachhaltig zu lösen als einem formalen Prozess zu folgen.

Ein Pilot wird fürs Fliegen bezahlt, nicht fürs obligatorische Abarbeiten der Start-Checkliste.

Ein Arzt wird für die OP bezahlt, nicht fürs obligatorische Abarbeiten der Checkliste.

Genauso wird ein Platform Engineer für die Erstellung und den Betrieb einer Entwicklerplattform bezahlt, nicht für die Abarbeitung eines stumpfen Prozesses.

Es gibt zwei Wege, wie sie ihren Prozess schlank und einfach halten, sodass Ihre Experten Expertendinge tun:

1. Möglichkeit – Strukturiert alle resultierenden Schritte in einer Tabelle sammeln und dann den Wert jedes Schritts bewerten. Alle Schritte, die nicht zwingend nötig sind, wandern auf die Optimierungsliste, aus der Sie sich im Zweifel bedienen können.
2. Möglichkeit – Sie fragen sich bei jedem Schritt: Und was passiert, wenn ich diesen Schritt ignoriere? Wenn die Antwort „gar nichts“, „nicht viel“ oder „vielleicht brauchen wir das irgendwann“ lautet, kann der Schritt gestrichen werden.

Haben sie den Prozess erstellt, dürfen Sie diesen in Ihrem bestehenden Entwicklungsprozess integrieren.

Schritt 3: Den Incident Prozess integrieren

Ob Scrum oder Kanban, SAFe oder LeSS – Ein schlanker Incident Prozess lässt sich überall integrieren.

Nach meiner Erfahrung hat ein Incident Prozess die höchste Überlebenschance, wenn er sich nahtlos in den bestehenden und gelebten Entwicklungsprozess einfügt.

Das Problem dabei ist: Es gibt keinen Entwicklungsprozess, bei dem der Betrieb bereits vorgesehen ist – selbst Kanban in der Entwicklung ist für den Betrieb völlig ungeeignet.

Wie schaffen Sie es also, den bewährten Entwicklungsprozess so zu erweitern, dass die Entwicklungsarbeiten nicht übermäßig gestört werden, der Betrieb aber nicht zu kurz kommt?

An der Stelle haben Sie viele Möglichkeiten – jeweils mit einigen Vor- und Nachteilen.

Hier drei Beispiele, die sich alle in meinen vergangenen Platform Teams funktionierten.

Beispiel 1: Incidents werden als eigener Aufgabentyp in Ihrem Board gepflegt

Idee:

• Sie haben genau ein Board, auf dem jegliche Arbeit sichtbar ist.
• Sie haben den vollen Überblick darüber, woran gerade gearbeitet wird.
• Sie können Incidents wie Backlog Items verwenden und priorisieren.

Fragen:

• Welche Schritte des Entwicklungsprozesses sind für den Incident relevant?
• Muss ein Incident refined werden?
• Ist jeder Incident wichtig und muss sofort behandelt werden?
• Wie schützen Sie ihren Sprint/ihre Entwicklung?
• Gibt es einen Unterschied zwischen einem Bug und einem Incident?

Beispiel 2: Incidents werden von einem gesonderten (rotierenden) Betriebsteam bearbeitet

Idee:

• Um Ihre Entwicklung zu schützen, bauen Sie ein eigenes rotierendes Betriebsteam auf, die sie für einen bestimmten Zeitraum ausschließlich um den Betrieb und die Behandlung von Incidents kümmert.
• Sie pflegen die Incidents parallel zum Entwicklungsboard, sodass Klarheit herrscht, wer woran arbeitet.
• Sie überprüfen jeden Tag im Daily, ob es notwendig ist, die Betriebsressourcen aufzustocken.

Fragen:

• Wie stellen Sie sicher, dass im Betriebsteam die Leute sitzen, die dann auch die Incidents entstören können?
• Wie stellen Sie sicher, dass die Betriebsteam-Kollegen sich nicht todlangweilen, während der Sprint kollabiert?
• Wie fördern Sie einen regelmäßigen Austausch zwischen dem Betriebsteam und dem Entwicklungsteam?

Beispiel 3: Incidents werden von einem Dispatcher entgegengenommen und bei Bedarf delegiert

Idee:

• Statt alle Engineers jederzeit an Incidents arbeiten zu lassen, wie es in Beispiel 1 vorgesehen ist, oder ein gesondertes, rotierendes Betriebsteam abzustellen, die sich ausschließlich um Betrieb kümmern, ist in diesem Beispiel genau ein Engineer in einer Art Tag- oder Wochendienst.
• Dieser Engineer kümmert sich darum, dass die Incidents priorisiert und in die Bearbeitung gegeben werden.
• Er kümmert sich darum, dass die meisten Themen bereits bearbeitet oder in einem Bearbeitbarem Zustand sind, um die Entwicklung so wenig wie möglich zu stören.

Fragen:

• Wie stellen Sie sicher, dass der Dispatcher als Single Point of Failure nicht ausfällt?
• Welche Informationen benötigt der Dispatcher dafür, die Incidents gegen die Entwicklung zu priorisieren?
• Wie schaffen Sie es bei der Unsicherheit, eine vernünftige Planung durchzuführen?

Fazit – Es gibt nicht die eine Lösung für alle Platform Teams

Ein funktionierender minimal tragfähiger Incident Prozess entscheidet über Erfolg oder Scheitern beim Betrieb und der Weiterentwicklung Ihrer Entwicklerplattform.

Dabei ist weniger entscheidend, wie der Prozess genau aussieht – viel wichtiger ist, dass der Prozess jeden einzelnen Tag gelebt wird und sich dabei sauber in den Entwicklungsprozess integriert.

Das in diesem Artikel beschriebene Vorgehen schafft die Basis für einen Minimal Valuable Incident Process, der genau den Zweck erfüllt, für den er da ist: Incidents schnell und sauber zu identifizieren, zu beheben und so den Betrieb aufrechtzuerhalten ohne dass die Weiterentwicklung ausgebremst wird.

Wollen Sie den Weg nicht allein gehen und stattdessen in wenigen Stunden einen sauberen und einfach umsetzbaren Incident Prozess etablieren? Dann sprechen Sie mich gerne an.

In nur einem Tag entwickeln wir Ihren individuellen Incident Prozess, auf den Sie sich komplett verlassen können und der sich nahtlos in ihren bisherigen Entwicklungsprozess eingliedert.

Bis dahin wünsche ich Ihnen viel Erfolg bei der Umsetzung!