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

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.

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.

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.

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.

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?

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: