Sommer 2019 – im Büro ist es 29,5 Grad. Wir starren auf das Thermometer. Ab 30 Grad entfällt die Anwesenheitspflicht und wir dürfen ins Homeoffice wechseln – heute unvorstellbar, aber so war das damals vor der Covid-Pandemie.
Aber in diesem Sommer gibt es noch ein viel wichtigeres Ereignis, das mein Denken auf den Kopf gestellt hat. Ein Wendepunkt.
Der damalige Platform Owner, den ich als Platform Engineering Lotse begleiten durfte, hatte gerade eine ITIL v3-Schulungen besucht. Gemeinsam gingen wir seine Erkenntnisse durch. Dabei erklärte er mir den Unterschied, der meine Denkweise seitdem radikal änderte – Der Unterschied zwischen Incident Management und Problem Management.
Aber der Reihe nach.
Wir standen vor dem Problem, das ich mit jedem Kunden habe:
Wie organisieren wir mit den verfügbaren Mitteln einen modernen und schlanken Plattformbetrieb, der den Entwicklungsprozess nicht blockiert?
Um dieses Problem zu lösen haben wir damals mit vielen Experten gesprochen, großartige Bücher wie das DevOps Handbook, Site Reliability Engineering und The Practice of Cloud System Administration gelesen und viele Keynotes angeschaut – aber ohne Ergebnis.
Unsere IT Service Management Prozesse (ITSM-Prozesse) waren verstopft und wir bekamen es weder mit Kanban noch mit Scrum in den Griff. Die Blockiert-Spalte war randvoll und es gab bei jedem Ticket einen guten Grund, warum es nicht weiterging.
Commitments konnten deshalb nicht mehr eingehalten werden und die notwendige Weiterentwicklung geriet ins stocken. Der Platform Owner konnte den Stakeholdern keine vernünftigen Antworten mehr auf die Frage geben: „Wann ist Feature XY fertig?“
Das ganze Programm meines damaligen Kunden drohte in der Konsequenz krachend zu scheitern. Von unserer Entwicklerplattform waren 450 Entwickler und Millionen Endkunden betroffen – es war also besser, eine Lösung zu finden.
Und dann kam der Tag, an dem der Platform Owner und ich gemeinsam die Erkenntnisse seiner Schulung zusammentrugen – es war drückend heiß, der Arbeitsraum war klein und die Geräuschkulisse aus dem Großraumbüro nebenan kaum geeignet, um innovative Ideen aus dem verstaubten ITIL v3 zu entwickeln.
Und doch traf uns die Erkenntnis wie ein Schlag!
Der Unterschied zwischen Incident und Problem Management
Viele Platform Owner und Engineers, mich damals eingeschlossen, versuchen, Incidents gleich richtig zu lösen. Das ist nachvollziehbar und offentlichtlich gesunder Menschenverstand. Sie wollen sich ja nicht ständig mit den gleichen Problemen beschäftigen.
Leider funktioniert diese Arbeitsweise nur unter einer Bedingung – Massive, vorgehaltene freie Kapazitäten, die bei Bedarf übernehmen. Wenn Sie Ihr Team im Fall eines Engpasses nicht ad-hoc hochskalieren können, dann funktioniert diese Strategie jedoch nicht. Die mathematische Begründung finden Sie in der Warteschlangentheorie und speziell in der Theory of Constraints. Der mathematische Beweis würde hier aber zu weit führen.
Aber selbst wenn das funktionieren würde – Möchten Sie sich als Platform Owner die Priorisierung von äußeren Umständen und vermeintlicher Perfektion abhängig machen? Und möchten Sie ihr kostbares Budget so verschwenden, wo es doch eine viel günstigere und risikoärmere Lösung gibt?
Die Lösung: Zwei unterschiedliche Prozesse
Teilen Sie die Incident Bearbeitung in zwei verschiedene Prozesse, ergeben sich ungeahnte Möglichkeiten. Plötzlich wird die Bearbeitung planbar und ihr Team gelangt in einen Arbeitsfluss, bei dem Sie weiterhin entscheiden, was gerade das wichtigste Thema ist, an dem weiterentwickelt werden muss.
Dafür schauen wir uns gemeinsam die erwarteten Ergebnisse der jeweiligen Prozesse an:
Ergebnis der Incident-Bearbeitung
Incidents werden im Betriebsprozess bearbeitet. Ziel ist es, die Plattform wieder ans Laufen zu bekommen. Symptome werden beseitigt, Spuren wie Logs und Metriken gesichert und Workarounds erstellt, falls die Ursache nicht direkt behoben werden kann.
Die Umwelt entscheidet, wann Ihr Team sich kümmern muss.
Das Qualitätskriterium eines bearbeiten Incidents lautet: Es läuft wieder und wir wissen, wie wir es nächstes Mal wieder lauffähig bekommen.
Ergebnis der Problem-Bearbeitung
Probleme gehen in den Entwicklungsprozess, werden refined, geschätzt, priorisiert und dann bei Gelegenheit umgesetzt. Es sind reine Entwicklungsaufgaben.
Sie entscheiden, wann Sie freie Kapazität haben, um das Problem nachhaltig zu lösen.
Das Qualitätskriterium eines bearbeiten Problems unterscheidet sich nicht von denen der Weiterentwicklung. Sie sind in der Definition of Done und den Akzeptanzkriterien festgelegt.
Wie Sie diesen Unterschied für Ihre Zwecke nutzen können
Möchten Sie vermeiden, dass die Bearbeitung von Incidents ihre Weiterentwicklung torpedieren, dann ist die Unterscheidung zwischen Incident und Problem essenziell. Den Effekt merken Sie sofort. Sie brauchen keine großen Veränderungen in Ihrer Arbeitsweise vorzunehmen. Es reicht völlig, Ihr bereits existierendes Arbeitsvorgehen mit Betriebsprozess und Entwicklungsprozess auf bei Incidents so zu nutzen, dass es Sie wirklich unterstützt.
Ziel des ganzen ist, dass Sie am Steuer bleiben und entscheiden, was die wichtigsten Themen bei der Plattform Entwicklung für Ihr Unternehmen sind und dabei 100%ige Sicherheit haben, dass Ihr Team die Störungen und Vorfälle adäquat aus dem Weg räumt.