Close

Vorfallmanagement für High-Velocity-Teams

Die Zukunft des IT-Vorfallmanagements, der Reaktion und der Prävention

In der Vergangenheit wurde fast immer das IT-Team mit der Reaktion auf Technologievorfälle beauftragt. Dabei überwachte häufig ein Team, das in einem Netzwerkbetriebszentrum untergebracht war, Systeme und reagierte auf Ausfälle. Eventuell hatte ein Anbieter die Software entwickelt, die Bereitstellung und der Betrieb lag aber in der Verantwortung des IT-Operations-Teams des Kunden. Heutzutage, wo Cloud-Services weit verbreitet sind, entwickelt der Anbieter die Software und kümmert sich auch um Deployment und Betrieb.

Dennoch bleibt das Vorfallmanagement immer noch eine wichtige Praxis des ITSM. Und die IT entwickelt schon lange Leitfäden, verwaltet Budgets und war überwiegend für die Diagnose, Behebung, Dokumentation und Vermeidung größerer Vorfälle zuständig.

Natürlich ist die Vergangenheit, wie alles in der Technologie, nicht unbedingt ein guter Anhaltspunkt dafür, wie die Zukunft aussehen wird. Derzeit verändert sich nämlich die Praxis des Vorfallmanagements. DevOps-, SecOps- und Architekturteams werden stärker eingebunden. Neue Technologien und miteinander vernetzte Produkte haben die Art und Weise verändert, wie wir mit Vorfällen umgehen. Im Zuge dessen ändern sich auch Denkweisen, Verfahren und Teamstrukturen, um mit der Entwicklung Schritt zu halten.

Wie verändert sich das Vorfallmanagement und was bedeutet das für die Zukunft unserer Rollen, Produkte, Prozesse und Teams?

Ein Schritt in Richtung Dezentralisierung

Gehe fünf Jahre zurück und frage ein IT-Team, wer für das Vorfallmanagement verantwortlich ist. Die wahrscheinlich häufigste Antwort darauf wird "wir" lauten.

Stelle dir jetzt dieselbe Frage und du wirst vermutlich nicht nur von der IT, sondern auch von den DevOps-, SecOps- und Architekturteams hören. Viele Unternehmen stellen allmählich auf das "you built it, you run it"-Konzept um.

Die klaren Vorteile dieses Ansatzes bestehen darin, dass die IT-Teams entlastet und die Reaktionszeiten beschleunigt werden, indem die Verantwortung auf Personen übertragen wird, die mit dem Code am besten vertraut sind. Dies verringert Ausfallzeiten, maximiert die Produktivität des Teams und bietet außerdem Anreize dafür, einen fehlerfreien Code zu schreiben. (Wenn du diejenige bist, die um 3 Uhr morgens aufgeweckt wird, um einen Fehler zu beheben, wirst du bei der nächsten Veröffentlichung von Code diesen wahrscheinlich doppelt und dreifach prüfen, um derartige nächtliche Anrufe zu vermeiden.)

Die Herausforderung dieses Ansatzes besteht darin, dass Unternehmen noch eine gewisse Zentralisierung brauchen. Führungskräfte müssen Zugang zu Berichten und Dokumentation haben. Unternehmens-Stakeholder wollen Updates. Sie möchten Metriken zu Vorfällen sehen, wie die mittlere Problemlösungszeit und die mittlere Bestätigungszeit. Sie erwarten klare Informationen, Post-Mortem-Berichte zu Vorfällen und Behebungsmaßnahmen.

Für viele Unternehmen, die verstärkt und mit Erfolg dezentralisieren, gibt es für diese Herausforderung eine passende Technologie, die Dezentralisierung und Teamautonomie ermöglicht. Dadurch können sie Vorfälle flexibel handhaben und trotzdem Informationen zentralisieren, um sämtliche Beteiligte im Unternehmen auf dem Laufenden zu halten.

Der langsame Weg zur Dezentralisierung

Wie auch bei jeder anderen großen Veränderung, die Arbeitsabläufe stören und unvorhergesehene Konsequenzen nach sich ziehen könnte, ist es für viele Unternehmen sinnvoll, in sehr kleinen Schritten zu dezentralisieren.

Zunächst wird ein Team ausgewählt, das einer solchen Veränderung gewachsen ist und risikoarme Anwendungen oder Produkte verwaltet. Diesem Team wird das Vorfallmanagement für seine spezifischen Anwendungen oder Produkte übertragen. Das Team wird geschult, es wird ein Bereitschaftsplan implementiert und seine Fortschritte im Laufe der Zeit werden beispielsweise mit folgenden Fragen verfolgt:

  • Haben sich die Wiederherstellungszeiten verbessert?
  • Auf welche kulturellen Barrieren ist das Team gestoßen?
  • Welche Tools musste das IT-Team einführen?
  • Welche Prozesse musste es kommunizieren?
  • Liefert das Team bessere Systemupdates?
  • Ist die Zahl der Vorfälle gesunken?
  • Falls wir uns dazu entschließen, diese Dezentralisierung auch für andere Teams zu übernehmen, welche Schlüsse können wir aus diesem ersten Testlauf ziehen?

Diese Testfälle sollen eine Grundlage für die Entscheidung schaffen, ob ein "you built it, you support it"-Framework im gesamten Unternehmen implementiert werden soll. Falls dem so ist, muss ermittelt werden, wie es effektiv in mehreren Teams eingeführt werden kann.

Dezentralisierung bedeutet teamübergreifende Zusammenarbeit

Dieser Schritt in Richtung Dezentralisierung erfordert auch einen Schritt hin zur teamübergreifenden Zusammenarbeit. Wenn das DevOps-Team am Vorfallmanagement beteiligt ist, muss es auch an Meetings zu IT-Vorfallmanagementprozessen teilnehmen dürfen. Wenn die IT immer noch Anleitung zu Vorfallmanagementverfahren gibt, muss sie an Post-Mortem-Reviews anderer Teams beteiligt werden.

Jedes Team bringt seine eigenen Stärken für das Vorfallmanagement mit. IT-Teams sind gut darin, Verfahren zu entwickeln, Dokumentation zu erstellen und Richtlinien zu befolgen. DevOps-Teams sind Experten für Veränderungen und Weiterentwicklung. SecOps-Teams kümmern sich um den Sicherheitsaspekt.

Um die Zusammenarbeit zwischen Teams zu fördern, gehen erfolgreiche Unternehmen wie folgt vor: Sie tauschen Informationen offen aus; fördern Empathie zwischen Teams, beseitigen Schuldzuweisungen; nutzen Chats, damit Teams während Vorfällen in Kontakt bleiben können, und priorisieren Vorfall-Reviews, an denen alle teilnehmen dürfen.

Vom reaktiven zum proaktiven Handeln

In den ITIL-Richtlinien wird das Vorfallmanagement in der Regel als eine von der Vorfallprävention separate Praxis betrachtet. Beide sind wichtige Teile des ITSM-Prozesses, stehen aber nicht oft miteinander im Zusammenhang.

Das Problem bei diesem Ansatz besteht darin, dass das Vorfallmanagement ein reaktiver Vorgang bleibt. Bereitschaftsdienstmitarbeiter haben die Aufgabe, aufgetretene Probleme zu lösen, und sobald eines gelöst ist, kümmern sie sich um das nächste. Einziges Ziel ist die Wiederherstellung, also das System wieder in Betrieb zu setzen.

Mit der Wiederherstellung allein ist es aber nicht getan. Und vielen IT-Teams wird immer häufiger bewusst, dass sie Präventionsmaßnahmen in den Vorfallmanagementprozess einbinden und anstelle der mittleren Wiederherstellungszeit Metriken wie die mittlere Problemlösungszeit verwenden müssen, um ihre Leistung zu beurteilen.

Dieser Ansatz wird oft als Problemmanagement bezeichnet und sein Ziel ist es, Prozesse einander näher zu bringen und so sicherzustellen, dass Teams nicht nur ein Problem nach dem anderen lösen. Sie sollen auf Vorfälle reagieren, diese beheben, aus ihnen lernen und diese Erkenntnisse sowohl auf das Problem als auch auf die weiteren, von ihnen verwalteten Produkt- und Servicesysteme anwenden.

Viele größere IT-Unternehmen haben speziell für das Problemmanagement vorgesehene Praktiken. Sie behandeln es in der Regel als separaten Prozess für ein separates Team. Wir bei Atlassian plädieren dafür, noch einen Schritt weiter zu gehen und einen kombinierten Ansatz zu verwenden, bei dem IT-Ops- und Entwicklerteams die Problemmanagementverfahren in ihr Vorfallmanagement einbeziehen. Dies erhöht die Sichtbarkeit des Vorfalls und stellt sicher, dass Vorfallanalysen nicht zu lange nach dem eigentlichen Vorfall durchgeführt werden.

Denn langfristig ist es effektiver, Vorfälle zu verhindern, als schnell darauf zu reagieren.

Mithilfe von Prozessen und Dokumentation auf Kurs bleiben

Eine der Herausforderungen im Zusammenhang mit der Umstellung auf die teamübergreifende Zusammenarbeit im Vorfallmanagement besteht darin, dass einige Teams in Bezug auf Prozesse und Dokumentation entspannter sind als andere.

Dies ist eine der Stellen, an denen die IT-Abteilung die Aufsicht übernehmen und einen erheblichen Nutzen bringen kann, auch wenn andere Teams die Verwaltung ihrer eigenen Produkte übernehmen. Schließlich will sich niemand ohne einen soliden Plan gegen 3 Uhr morgens schlaftrunken um einen großen Vorfall kümmern.

Wenn Teams in den Vorfallmanagementprozess eingebunden werden, kann die IT-Abteilung ihnen helfen, wichtige Fragen zu beantworten, denen dieser Plan folgen wird. Beispiel:

  • Wie sieht unsere Incident Response aus?
  • An welchen Werten wirst du dich orientieren?
  • Wie wirst du bei einem Vorfall reagieren?
  • Wo sind die Informationen, die du zur Unterstützung deiner kritischen Systeme benötigst? Falls es sich um mehrere Systeme handelt, wie kannst du diese Informationen zusammenführen und für Bereitschaftsmitarbeiter leicht zugänglich machen?
  • Sind dein Prozess und deine Dokumentation für die Zusammenarbeit geeignet und vom Team einsehbar?

Ist deine Unternehmenskultur bereit für Veränderungen?

Diese Verlagerung hin zu Dezentralisierung, Zusammenarbeit und einer Kombination von Vorfall- und Problemmanagement erfordert mehr als nur die Umverteilung von Verantwortlichkeiten und die Teilnahme eines IT-Experten bei einer Post-Mortem-Analyse der DevOps-Abteilung. Der Schlüssel zum Erfolg liegt hier nicht in der Technologie oder gar in den Prozessen. Es ist die Schaffung einer internen Kultur, die diese Veränderungen unterstützt.

Diesen Teil versuchen viele Unternehmen oft zu überspringen, obwohl er die Grundlage für einen erfolgreichen Wandel ist. Wie sieht also eine Kultur aus, die ein dezentrales, kollaboratives, zukunftsorientiertes Vorfallmanagement unterstützt?

Wir bei Atlassian glauben, dass die folgenden die wichtigsten Komponenten sind:

Offenheit und Austausch von Informationen

Wenn ein Team nicht weiß, was das andere macht, und auch keinen Zugriff auf die Arbeit anderer Teams hat, gibt es keine Aha-Erlebnisse, die zu einer besseren Kommunikation oder zu besseren Prozessen und Produkten führen.

Kundenorientiertes Denken

Wenn wir uns beispielsweise fragen, was für den Kunden das Beste ist, decken sich unsere Antworten manchmal nicht mit unseren derzeitigen Praktiken. Nur mit einer ausdrücklichen Kundenorientierung gelangen wir zu der richtigen Kommunikation, dem passenden Prozess und der strukturellen Effizienz, die unsere Produkte letztendlich für die Kunden verbessern.

Regelmäßige Zustandsprüfungen

Wie sieht es in den jeweiligen Teams aus? Was meinen einzelne Teammitglieder? In welchen Bereichen kann sich das Team verbessern? Wo erzielt es besonders gute Ergebnisse? Wir bei Atlassian nutzen ein Team-Playbook, das uns dabei hilft, den Zustand unserer Teams zu überprüfen und ihnen neue Arbeitsweisen vorzustellen.

Einfühlungsvermögen

Wenn die DevOps-Abteilung mit dem Finger auf die IT-Abteilung zeigt und die IT-Abteilung angesichts des entspannteren Ansatzes von DevOps mit den Augen rollt, ist das für die Zusammenarbeit nicht ideal. Die Förderung gegenseitiger Empathie und Beziehungen zwischen Teams ist unerlässlich, wenn sie miteinander kommunizieren, Neuerungen einbringen und gut zusammenarbeiten sollen.

Unterstützung

Teams sollten in die Lage versetzt werden, Probleme schnell zu beheben und nach Möglichkeit selbstständig Entscheidungen zu treffen. Einzelne Teammitglieder sollten sich motiviert fühlen, laut Fragen zu stellen, Vorschläge zu machen oder Bedenken zu äußern; und das unabhängig von ihrer Position im Team oder ihrer Erfahrung in Jahren.

Wenn Nachwuchsentwicklern das Gefühl gegeben wird, dass sie sich in Meetings beteiligen und auf Probleme hinweisen können – auch wenn erfahrenere Kollegen für einen bestimmten Code verantwortlich waren –, entstehen daraus innovative neue Ideen und verbesserte Prozesse, und es werden Fehler erkannt, bevor sie mit dem Code veröffentlicht werden.