Close

Der Weg zu einem besseren Vorfallmanagement beginnt hier

Die sich ändernden Rollen des Vorfall- und Problemmanagements

In den letzten zehn Jahren hat sich das Vorfallmanagement stark verändert.

Die ITIL-Richtlinien wurden aktualisiert. IT-Teams haben begonnen, ihre Verantwortung mit DevOps und SecOps zu teilen. Immer kompliziertere Systeme haben zu immer komplizierteren Lösungen für das Vorfallmanagement geführt. Und viele Unternehmen setzen auf Post-Mortem-Analysen ohne Schuldzuweisungen und neue Möglichkeiten zur Leistungsmessung.

Während sich das Vorfallmanagement weiter verändert und weiterentwickelt, ändert sich auch sein naher Verwandter, das Problemmanagement, sowie die Beziehung zwischen den beiden Verfahren.

Was ist ein Problem und wie unterscheidet es sich von einem Vorfall?

Die ITIL definiert ein Problem als "eine Ursache oder eine potenzielle Ursache für einen oder mehrere Vorfälle".

Ein Vorfall ist ein einzelnes ungeplantes Ereignis, das zu einer Serviceunterbrechung führt.

Mit anderen Worten, Vorfälle sind die unangenehmen Episoden, die die Bereitschaftsmitarbeiter in der Regel so schnell und vollständig wie möglich beheben wollen, und Probleme sind die Hauptursache für diese störenden Ereignisse.

Ein Problem kann einen einzelnen Vorfall oder auch mehrere Vorfälle verursachen. Ein Vorfall kann auf ein einzelnes Problem oder manchmal auf mehrere Probleme zurückgeführt werden.

Serverkolonne, in der ein Server umkippt und Probleme verursacht

Zum Beispiel war der fünfstündige Ausfall, der Delta Airlines im Jahr 2016 150 Millionen US-Dollar kostete, ein Vorfall. Das Problem, das diesen Vorfall verursacht hat, war ein Stromausfall in einem Betriebszentrum, und vermutlich war kein Backup-Plan für einen solchen Stromausfall vorhanden.

Ebenso war der zwölfstündige Ausfall des App Store, der Apple schätzungsweise 25 Millionen US-Dollar kostete, ein Vorfall. Das Problem dahinter? Ein DNS-Problem.

Wenn wir diese Begriffe außerhalb der Technologiewelt verwenden würden, wäre es ein Vorfall, wenn du wegen einer Migräne zum Arzt gehst. Die Ursache der Migräne – Allergien oder Sehprobleme oder Stress – wäre das Problem.

Problemmanagement und Incident Management

Offensichtlich sind Probleme und Vorfälle untrennbar miteinander verbunden. Das eine bewirkt das andere und die Teams müssen auf beides achten.

Für traditionelle IT-Teams fordern die neuesten ITIL-Richtlinien, dass Teams sowohl Probleme als auch Vorfälle verwalten, dies jedoch separat tun. Problemmanagement ist eine Praxis, die sich darauf konzentriert, Vorfälle zu verhindern oder deren Auswirkungen zu reduzieren. Das Vorfallmanagement konzentriert sich auf die Behebung von Vorfällen in Echtzeit.

Der Vorteil des ITIL-Ansatzes besteht darin, dass er die Kernziele sowohl des Problemmanagements als auch des Vorfallmanagements priorisiert. Indem sie diese Verfahren trennen und ihnen dieselbe hohe Bedeutung zusprechen, versuchen die Richtlinien vermutlich, das häufige Problem zu vermeiden, dass IT-Teams ständig dringende Vorfälle beheben, ohne sich mit der eigentlichen Ursache dieser Vorfälle zu befassen.

Wenn das Hauptziel eines Vorfallmanagers die schnelle Behebung von Vorfällen und das Hauptziel eines Problemmanagers die Prävention ist, kann die Kombination dieser Rollen bedeuten, dass eines dieser Ziele zugunsten des anderen zu kurz kommt, obwohl beide für ein Unternehmen gleichermaßen von Bedeutung sind.

Der Nachteil dieses Ansatzes besteht darin, dass die Trennung der beiden Verfahren, die in der Realität so eng miteinander verbunden sind, Wissenslücken und einen Zusammenbruch der Kommunikation zwischen der Behebung von Vorfällen und der Ursachenanalyse führen kann, die zur zugrunde liegenden Ursache führt.

DevOps und die sich verändernden Rollen des Problem- und Vorfallmanagements

Wie üblich hat die kollaborative DevOps-Bewegung die Grenzen der traditionellen IT-Denkweise verwischt, bei der das Problem- und Vorfallmanagement nicht als zwei eigenständige Verfahren, sondern als überlappende Hälften einer ganzheitlichen Sichtweise betrachtet wurden.

ITIL-Diagramm mit separaten Problem- und Vorfallmanagement-Kreisen und DevOps-Diagramm mit Venn-Diagramm des Problem- und Vorfallmanagements

Dieser Wandel ergibt sich nicht nur aus der Tatsache, dass die Verfahren zwei Seiten derselben Medaille sind – Vorfälle verhindern und beheben –, sondern auch aus einem DevOps-Ansatz, der typischerweise folgende Prinzipien befolgt:

  • Es gibt oft mehr als eine Ursache für einen Vorfall.
  • Post-Mortem-Analysen sollten frei von Schuldzuweisungen sein und jedes Team einbeziehen, das von dem Vorfall betroffen ist.
  • Zusammenarbeit steht im Mittelpunkt einer kontinuierlichen Verbesserung.

Die Überschneidung im Problem- und Vorfallmanagement kann auch mit der branchenweiten Verlagerung hin zu einem "you build it, you run it"-Ansatz zusammenhängen. Wenn die Teams, die Systeme entwickeln, für die Behebung von Vorfällen in diesen Systemen verantwortlich sind, ist es logisch, dass dasselbe Team auch dafür verantwortlich ist, Post-Mortem-Analysen durchzuführen und Detektivarbeit zu leisten, um die Ursache eines Vorfalls herauszufinden und Empfehlungen abzugeben, die in Zukunft Ausfälle verhindern oder die Auswirkungen verringern.

Die Brücke zwischen Problem- und Vorfallmanagement ist hier die Post-Mortem-Analyse ohne Schuldzuweisungen, bei der sich die Vorfallmanager, sobald die heiße Behebungsphase vorüber ist, als Detektive betätigen und sich dem Problemmanagement und der Prävention zuwenden.

Die größte Herausforderung für DevOps-Teams, die die Grenzen zwischen diesen beiden Verfahren aufweichen, besteht darin, sicherzustellen, dass das Problemmanagement mit seinen weniger dringenden, aber äußerst wertvollen langfristigen Zielen nicht zugunsten der Dringlichkeit des Vorfallmanagements an Priorität verliert.

Weiter geht's
ChatOps