Was ist Incident Management?

Verschiedene Arten von Vorfallmanagementprozess

Je nach Art des Unternehmens werden tendenziell unterschiedliche Varianten des Vorfallmanagementprozesses genutzt. Es gibt keinen Universalprozess, der für alle Unternehmen optimal ist.

Viele Teams nutzen einen traditionelleren Vorfallmanagementprozess im IT-Stil, wie er in ITIL-Zertifizierungen beschrieben wird. Andere Teams tendieren zu einem eher SRE- (Site Reliability Engineer) oder DevOps-orientierten Vorfallmanagementprozess.

IT-Vorfallmanagementprozess

Ein Vorfallmanagementprozess hilft IT-Teams beim Untersuchen, Aufzeichnen und Lösen von Serviceunterbrechungen oder -ausfällen. Der ITIL-Workflow für das Vorfallmanagement soll Ausfallzeiten reduzieren und die Auswirkungen von Vorfällen auf die Produktivität der Mitarbeiter minimieren. Mithilfe von speziell für diesen Zweck erstellten Vorlagen kannst du einen reproduzierbaren Workflow für das Vorfallmanagement erstellen, damit Teams Vorfälle protokollieren, diagnostizieren und lösen sowie ihre Aktivitäten aufzeichnen können.

Das ITIL-Framework wird hauptsächlich von IT-Teams eingesetzt, die Services in Unternehmen betreiben. In der Regel nutzen Teams bei ITIL nur das, was sie tatsächlich benötigen. ITIL deckt fast alle Arten von Vorfällen, Vorgängen und Prozessen ab, mit denen IT-Teams möglicherweise konfrontiert werden. ITIL ist ein großartiges Framework für Teams, für die die aktive Fehlerbehebung im Fokus steht. Die vorgeschriebenen Prozesse unterstützen Teams bei der konsequenten Nachverfolgung von Vorfällen und Aktionen, was die Berichterstattung und Analyse verbessert und letztlich zu einem stabileren Service und einem erfolgreicheren Team führen kann.

Schritte beim IT-Vorfallmanagement

Vorfall identifizieren und protokollieren

Ein Vorfall kann von ganz unterschiedlichen Seiten gemeldet werden: von Mitarbeitern, Kunden, einem Anbieter oder von Überwachungssystemen. Unabhängig von der Quelle der Meldung sind die ersten beiden Schritte ganz einfach: Jemand identifiziert einen Vorfall, und ein anderer protokolliert ihn. Diese Vorfallprotokolle (d. h. Tickets) umfassen normalerweise Folgendes:

• Name der Person, die den Vorfall meldet
• Datum und Uhrzeit der Meldung des Vorfalls
• Beschreibung des Vorfalls (Was ist ausgefallen oder funktioniert nicht richtig?)
• Eine dem Vorfall zugewiesene eindeutige Identifikationsnummer zur Nachverfolgung

Kategorisieren

Weise jedem Vorfall eine logische, intuitive Kategorie (und ggf. auch Unterkategorie) zu. So kannst du deine Daten analysieren und nach Trends und Mustern suchen – ein wichtiger Bestandteil eines effektiven Problemmanagements, um zukünftige Vorfälle zu verhindern.

Priorisieren

Jedem Vorfall muss ein Schweregrad zugeordnet werden. Beginne mit der Bewertung der Auswirkungen auf das Unternehmen. Berücksichtige die Anzahl der betroffenen Personen, die betroffenen Service Level Agreements (SLAs) und die potenziellen Auswirkungen auf Finanzen, Sicherheit und Compliance. Vergleiche diesen Vorfall mit allen anderen offenen Vorfällen, um seine relative Priorität zu ermitteln.

Reagieren

• Erstdiagnose: Im Idealfall kann dein Supportteam an vorderster Front einen Vorfall von der Diagnose bis zum Abschluss betreuen. Sollte dies nicht der Fall sein, besteht der nächste Schritt darin, alle relevanten Informationen zu protokollieren und an das Team der nächsten Stufe zu eskalieren.
• Eskalation: Das nächste Team setzt die Diagnose anhand der protokollierten Daten fort. Wenn dieses Team den Vorfall nicht diagnostizieren kann, eskaliert es ihn an das nächste Team.
• Kommunikation: Das Team gibt regelmäßig Mitteilungen an die betroffenen internen und externen Stakeholder weiter.
• Untersuchung und Diagnose: Dieser Prozess wird fortgesetzt, bis die Art des Vorfalls feststeht. Manchmal ziehen Teams externe Ressourcen oder andere Abteilungsmitglieder hinzu, um sich beraten zu lassen und Hilfe bei der Lösung zu erhalten.
• Lösung und Wiederherstellung: In diesem Schritt gelangt das Team zu einer Diagnose und ergreift die zum Lösen des Vorfalls nötigen Maßnahmen. Die Wiederherstellung bezieht sich schlicht auf die Zeitdauer, bis Vorgänge vollständig wiederhergestellt werden können. Bestimmte Fehlerkorrekturen (wie Bug-Patches) erfordern eventuell noch Tests oder müssen erst bereitgestellt werden, obwohl die richtige Lösung bereits identifiziert wurde.
• Abschluss: Wenn der Vorfall eskaliert wurde, wird er abschließend an den Servicedesk zurückgegeben, damit er geschlossen werden kann. Um die Qualität aufrechtzuerhalten und einen reibungslosen Ablauf zu gewährleisten, dürfen nur Servicedesk-Mitarbeiter Vorfälle schließen. Derweil sollten sich Vorfallverantwortliche bei der Person, die den Vorfall gemeldet hat, erkundigen, ob die Lösung zufriedenstellend war und der Vorfall tatsächlich geschlossen werden kann.

Vorfälle, Probleme und Änderungen: Wo liegen die Unterschiede?

Es gibt verschiedene Arten von Problemen, denen IT-Teams typischerweise begegnen. Wir klassifizieren sie, damit wir die entsprechenden Managementtechniken auf sie anwenden können.

• Serviceanfrage: Dies ist die offizielle Aufforderung eines Kunden, etwas bereitzustellen, beispielsweise einen neuen Laptop.
• Vorfall: Bezeichnet eine ungeplante Unterbrechung bei einem IT-Service oder eine Abnahme der Servicequalität, beispielsweise einen Ausfall der Website.
• Problem: Ein Problem ist die grundlegende Ursache eines Vorfalls, beispielsweise die fehlerhafte Konfiguration eines Servers. Diese Punkte solltest du im Blick behalten, um schwerwiegende Vorfälle zu vermeiden.
• Änderung: Eine von dir durchgeführte Aktion. Es kann sich um eine standardmäßige, eine normale oder eine Notfalländerung handeln. Für Standardänderungen gibt es festgelegte Verfahren. Normale Änderungen sind oft weitreichend und müssen vorab genehmigt werden. Eine Notfalländerung wird unmittelbar beschlossen und im Idealfall getestet, bevor sie umgesetzt wird.

DevOps- und SRE-Vorfallmanagementprozess

Beim DevOps- oder SRE-Ansatz für das Vorfallmanagement ist das Team, das den Service erstellt hat, auch für seinen Betrieb und bei Vorfällen für die Lösung zuständig. Dieser Ansatz erfreut sich großer Beliebtheit, seit dauerhaft verfügbare Cloud-Services, global genutzte Web-Anwendungen, Microservices und SaaS-Lösungen (Software-as-a-Service) gängig sind.

Immer häufiger wird die Software, die du für dein Privatleben und deine Arbeit benötigst, nicht mehr auf einem Server in deiner Nähe gehostet. Es handelt sich zunehmend um über das Internet verfügbare Anwendungen, die in einem Rechenzentrum für Tausende oder Millionen von Benutzern weltweit bereitgestellt werden. Teams, die für den Betrieb dieser Services zuständig sind, müssen flexibel und schnell handeln können. Ausfälle wirken sich nicht nur auf ein einziges Unternehmen aus, sondern potenziell auf mehrere Tausend.

Wenn das Team, das einen Service entwickelt hat, diesen auch betreibt, hat dies den Vorteil, dass die Teams genügend Flexibilität erhalten. Manchmal bleibt allerdings unklar, wer wann wofür zuständig ist. DevOps-Teams kommen unter Umständen auch mit weniger strukturierten Entwicklungsprozessen zurecht und können damit erfolgreich sein. Es empfiehlt sich jedoch, eine Reihe von Kernprozessen für das Vorfallmanagement als Standard festzulegen, damit im Ernstfall klar ist, wie auf einen Vorfall reagiert werden soll. Außerdem kannst du so Probleme nachverfolgen und über ihre Behebung berichten.

Drei Überzeugungen von DevOps-Vorfallmanagementteams

• Teams sollten sich bei der Bereitschaft abwechseln: In der Regel gibt es in DevOps-Teams kein einzelnes Teammitglied, das auf Bereitschaft spezialisiert ist, sondern die Zuständigkeit rotiert, sodass sich alle Teammitglieder die Verantwortung teilen und abwechselnd das Risiko tragen, bei einem Vorfall mitten in der Nacht geweckt zu werden.
• Der Entwickler eines Service ist am besten für die Problembehebung bei diesem Service qualifiziert: Diese zentrale Idee steht hinter dem Ansatz, dass das Team, das einen Service entwickelt hat, diesen auch betreiben sollte.
• Teams müssen schnell und dennoch verantwortungsbewusst entwickeln: Wenn die Entwickler wissen, dass bei einem Ausfall sie selbst und ihre Teamkollegen zur Verantwortung gezogen werden, sind sie motivierter, auf die Qualität ihres bereitgestellten Codes zu achten.

Dieser Ansatz sorgt für kurze Reaktionszeiten und schnelleres Feedback an die Teams, die wissen müssen, wie ein zuverlässiger Service entwickelt wird.

In unserem Atlassian-Handbuch zum Vorfallmanagement beschreiben wir einen sehr DevOps-freundlichen Ansatz für das Vorfallmanagement.

Tools für das Vorfallmanagement

Für das Vorfallmanagement genügt kein einzelnes Tool. Vielmehr ist eine Kombination aus passenden Tools, Verfahren und Mitarbeitern gefragt. Hier einige der gängigsten Toolkategorien für effektives Vorfallmanagement:

• Vorfallverfolgung: Jeder Vorfall sollte verfolgt und dokumentiert werden, damit du Trends erkennen und im Laufe der Zeit Vergleiche anstellen kannst.
• Chatraum: Kommunikation in Echtzeit ist für die gemeinsame Diagnose und Lösung eines Vorfalls im Team unverzichtbar. Außerdem hast du so später umfassende Daten für die Reaktionsanalyse zur Verfügung.
• Videochat: Der Videochat ergänzt bei vielen Vorfällen den Textchat. Im Videochat können Teams Erkenntnisse besprechen und eine Reaktionsstrategie planen.
• Benachrichtigungssystem: Ein Tool wie Opsgenie wird mit dem Überwachungssystem integriert und übernimmt das Management von Bereitschaftsrotationen und Eskalationen.
• Dokumentationstool: In einem Tool wie Confluence kannst du Dokumente zum Vorfallstatus und Post-Mortem-Analysen festhalten.
• Statuspage: Per Statuspage lässt sich der Status mit internen Stakeholdern und mit Kunden teilen, damit alle auf dem Laufenden bleiben.