{"id":22470,"date":"2021-12-08T16:16:03","date_gmt":"2021-12-08T16:16:03","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/?p=22470"},"modified":"2026-06-15T15:43:58","modified_gmt":"2026-06-15T15:43:58","slug":"sre-incident-management-uebersicht-techniken-und-tools","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/de\/sre-incident-management-uebersicht-techniken-und-tools\/","title":{"rendered":"SRE Incident Management: \u00dcbersicht, Techniken und Tools"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In der Welt eines Site Reliability Engineer (SRE)<\/a>ist ein Ausfall nicht nur eine Option, sondern auch zu erwarten. Systeme, Webanwendungen, Server, Ger\u00e4te usw. sind alle anf\u00e4llig f\u00fcr Leistungsprobleme und unerwartete Ausf\u00e4lle an einem bestimmten Punkt. Es ist eine unvermeidliche Tatsache. Diese unerwarteten Ausf\u00e4lle k\u00f6nnen zu enormen Umsatzeinbu\u00dfen, Kundenvertrauen und je nach Branche zu Bu\u00dfgeldern f\u00fchren. Gl\u00fccklicherweise ist das SRE-Vorfallmanagement eine der Kernpraktiken, um die durch unerwartete Probleme verursachten St\u00f6rungen zu begrenzen. In einem anderen Artikel haben wir \u00fcber Chaos Engineering<\/a> gesprochen und dar\u00fcber, wie SRE-Teams proaktiv nach Fehlern suchen und diese testen, um das Schlimmste zu verhindern. Wie wir jedoch alle wissen, k\u00f6nnen Probleme durch die Risse schl\u00fcpfen. Ziel ist es, zu verhindern, dass diese Vorf\u00e4lle zu gro\u00dffl\u00e4chigen kaskadierenden Ausf\u00e4llen werden. SREs und DevOps-Teams k\u00f6nnen diese Vorf\u00e4lle nutzen, um ihre Systeme und Services besser aufzubauen und zu verbessern.<\/p>\n

<\/p>\n

Was ist ein Vorfall?<\/h2>\n

Bevor wir uns mehr mit diesem Thema befassen, m\u00fcssen wir zuerst besprechen, was ein Vorfall ist. Wo verl\u00e4uft die Grenze zwischen etwas, das sofortiges Handeln erfordert, und etwas, das sp\u00e4ter untersucht werden kann? Wenn jedes Problem als dringend eingestuft w\u00fcrde, w\u00fcrde niemand eine L\u00f6sung bekommen. Im Kontext der IT (Informationstechnologie) ist ein Vorfall einfach ein Ereignis oder Problem, das den normalen Betrieb oder die Servicequalit\u00e4t st\u00f6rt. Es hat nicht zu einem Fehler gef\u00fchrt, aber wenn es nicht \u00fcberpr\u00fcft wird, hat es die M\u00f6glichkeit, gr\u00f6\u00dfere Auswirkungen auf Ihre Dienste und Abl\u00e4ufe zu haben. Und sie passieren normalerweise um 2:00 Uhr morgens, w\u00e4hrend Sie gl\u00fcckselig schlafen und durch das Ger\u00e4usch Ihres Telefons geweckt werden. Wir machen nat\u00fcrlich Witze, aber Sie wissen, dass etwas schlecht ist, wenn es so fr\u00fch am Morgen passiert. Um 2:00 Uhr morgens passiert nichts Gutes.m, besonders wenn wir \u00fcber die IT-Branche sprechen.<\/p>\n

<\/p>\n

Was ist Incident Management?<\/h2>\n

Nun, da wir dar\u00fcber gesprochen haben, was ein Vorfall ist, ist das Incident Management der Prozess, mit dem Teams diese Ereignisse l\u00f6sen und Systeme und Dienste wieder in den normalen Betrieb bringen. Wir sollten auch beachten, dass das Incident Management nur ein Element eines gr\u00f6\u00dferen Konzepts ist, das als IT Service Management oder ITSM bekannt ist. ITSM definiert, wie Teams ihre Services entwerfen, erstellen und bereitstellen. Es ist viel mehr als nur IT-Support. ITSM sind die Richtlinien, Prozesse und Strukturen hinter dem Lebenszyklus von IT-Services. ITSM ist eine der Praktiken der Information Technology Infrastructure Library (ITIL).<\/p>\n

ITIL bietet den Rahmen und die Richtlinien f\u00fcr den Aufbau von ITSM-L\u00f6sungen. M\u00f6glicherweise sind Sie bereits mit anderen Frameworks vertraut, z. B. Business Process Framework (eTOM), Control Objectives for Information and Related Technologies (COBIT), FitSM, ISO\/IEC 20000 und Microsoft Operations Framework (MOF).<\/p>\n

<\/p>\n

Das IT Service Management (ITSM) Framework<\/h3>\n

Wenn wir einen Schritt zur\u00fccktreten und uns nur ein wenig auf die Elemente innerhalb des ITSM-Frameworks konzentrieren, gibt es sechs weitere Komponenten, die das ITSM-“Rad” zusammen mit dem Incident Management ausmachen. Wir werden zwar nicht im Detail darauf eingehen, aber es ist wichtig zu verstehen, wie all diese Teile zusammen mit dem Vorfallmanagement zusammenpassen.<\/p>\n

<\/p>\n

Servicekatalog<\/h4>\n

Der IT-Servicekatalog ist in der Regel eine Datenbank oder Ressource, die eine Organisation erstellt, um Benutzern Informationen zu ihren betrieblichen Services und Angeboten bereitzustellen. Diese Servicekataloge bieten n\u00fctzliche Informationen zu aktuellen und geplanten Services sowie zu Preisen, Einkaufsprozessen, Ansprechpartnern und anderen Leistungen.<\/p>\n

<\/p>\n

Service-Desk<\/h4>\n

Der Service Desk kann als Kontaktpunkt zwischen dem Dienstleister und den Benutzern wie internen Mitarbeitern, Stakeholdern oder Kunden betrachtet werden. Es ist der zentrale “Hub”, an den Benutzer gehen, um Unterst\u00fctzung und Service zu erhalten. Nach ITIL-Definition kann der Service Desk die Form von Incident Resolution oder Service Requests annehmen, aber in jedem Fall ist das Hauptziel des Service Desks, einen schnellen und effizienten Service zu bieten.<\/p>\n

<\/p>\n

Problemmanagement<\/h4>\n

Wenn wir \u00fcber Incident Management sprechen, kann ein SRE-Team einen Vorfall m\u00f6glicherweise schnell l\u00f6sen, aber das zugrunde liegende Problem kann immer noch bestehen und noch eine Weile bestehen. Problemmanagement ist der Prozess, durch den die Ursachen von Vorf\u00e4llen dauerhaft behoben werden, was die langfristige Leistung und zuk\u00fcnftige Servicebereitstellungen verbessert.<\/p>\n

<\/p>\n

Ver\u00e4nderungsmanagement<\/h4>\n

Jede Art von \u00c4nderung, ob es sich nun um neue Servicebereitstellungen oder pers\u00f6nliche \u00c4nderungen handelt, es besteht immer ein gewisses Risiko. \u00c4nderungsmanagement ist der Prozess, bei dem ermittelt wird, wie sich \u00c4nderungen auf die Servicebereitstellung auswirken und\/oder die Auswirkungen auf das Unternehmen selbst ber\u00fccksichtigt werden. Das \u00c4nderungsmanagement wird manchmal auch mit dem Release-Management gruppiert.<\/p>\n

<\/p>\n

Verm\u00f6gensverwaltung<\/h4>\n

Man kann nicht alles virtualisieren… noch. Softwaredienste erfordern immer noch physische Ger\u00e4te und Hardware, damit sie funktionieren. Und Unternehmen m\u00fcssen diese Ger\u00e4te verfolgen, verwalten und kontinuierlich aktualisieren, um sicherzustellen, dass ihre Dienste reibungslos ausgef\u00fchrt werden k\u00f6nnen. Asset Management wird auch als IT Asset Management oder ITAM bezeichnet.<\/p>\n

<\/p>\n

Wissens-, Richtlinien- und Verfahrensmanagement<\/h4>\n

Das Ziel des Wissensmanagements ist es, Redundanzen in Bezug auf das Sammeln, \u00dcberpr\u00fcfen und Teilen von Informationen innerhalb einer Organisation zu reduzieren. Dies tr\u00e4gt zur Verbesserung der Effizienz bei und stellt sicher, dass die Informationen konsistent, aktuell und verf\u00fcgbar sind.<\/p>\n

<\/p>\n

Incident Management Lifecyle: Prozess und Schritte<\/h2>\n

Die Reaktion eines Unternehmens auf einen Vorfall, unabh\u00e4ngig davon, ob es sich um Ausfallzeiten, Sicherheitsverletzungen oder Cyberangriffe oder sogar um l\u00e4ngere Latenzzeiten und wiederholte Fehler handelt, ist entscheidend f\u00fcr den anhaltenden Erfolg des Unternehmens und das Vertrauen des Kunden oder Endbenutzers. SREs m\u00fcssen komplexe verteilte Systeme verwalten. W\u00e4hrend die Vorteile dieser Systeme darin bestehen, dass sie zuverl\u00e4ssiger, skalierbarer und fehlertoleranter sind, sind sie dadurch auch extrem komplex, was zu l\u00e4ngeren Behebungszeiten f\u00fchren kann, da Probleme schwieriger zu erkennen und zu lokalisieren sind. Die besten SRE-Incident-Management-Teams halten sich an einen strengen Incident-Management- und Behebungsprozess. W\u00e4hrend die tats\u00e4chlichen Schritte und Prozesse zwischen den Organisationen variieren k\u00f6nnen, folgen die meisten dem gleichen grundlegenden Pfad. Schauen wir uns den SRE-Incident-Management-Prozess und die SRE-Schritte an.<\/p>\n

<\/p>\n

1. Identifizierung von Vorf\u00e4llen<\/h3>\n

Sie k\u00f6nnen keine Probleme beheben, die Sie nicht kennen. Die Identifizierung von Vorf\u00e4llen beginnt mit einer Form von \u00dcberwachungs- oder Alarmierungsmechanismus. Wir haben in einem anderen Artikel \u00fcber die \u00dcberwachung verteilter Systeme<\/a> gesprochen und wie sich dies auf SRE-Teams auswirkt. Zu wissen, wann und wo ein Fehler, eine Ausfallzeit oder eine Anwendungslatenz auftritt, ist ein kritischer Faktor, um die Auswirkungen auf Benutzer und Kunden zu begrenzen. In einigen F\u00e4llen wird ein Vorfall jedoch durch ein Support-Ticket, einen Anruf oder sogar soziale Medien bekannt, was nie eine gute Nachricht ist, wenn Probleme \u00f6ffentlich f\u00fcr alle sichtbar ver\u00f6ffentlicht werden.<\/p>\n

<\/p>\n

2. Protokollierung von Vorf\u00e4llen<\/h3>\n

Unabh\u00e4ngig von der Erkennungsmethode sollte ein Vorfall, sobald er identifiziert wurde, protokolliert werden. Die Ereignisprotokollierung dient mehreren Zwecken. Es stellt sicher, dass ein formaler Datensatz eingereicht wurde, und f\u00fcr die \u00fcberpr\u00fcfung von Vorfalltrends zu einem sp\u00e4teren Zeitpunkt. Wenn derselbe oder ein \u00e4hnlicher Vorfall wiederholt auftritt, kann dies ein Hinweis auf ein komplexeres Problem sein, das angegangen werden muss. Bei der Protokollierung eines Vorfalls werden auch relevante Informationen wie Zeitstempel, Vorfallbeschreibung und wer das Problem entdeckt hat, enthalten. Je detaillierter informationen, desto besser.<\/p>\n

<\/p>\n

3. Kategorisierung von Vorf\u00e4llen<\/h3>\n

Als n\u00e4chstes folgt die Kategorisierung des Vorfalls basierend auf Faktoren wie Schweregrad, Dringlichkeit oder betroffenem Funktionsbereich. Wie bei der Protokollierung des Vorfalls k\u00f6nnen je mehr Informationen bereitgestellt werden, sp\u00e4ter bei der Bestimmung des richtigen Teams oder der richtigen Person f\u00fcr die Reaktion auf Vorf\u00e4lle hilfreich sein.<\/p>\n

<\/p>\n

4. Priorisierung von Vorf\u00e4llen<\/h3>\n

Basierend darauf, wie der Vorfall kategorisiert wurde, besteht der n\u00e4chste Schritt darin, die Priorit\u00e4tsstufe festzulegen. Auch hier treten einige dieser Schritte gleichzeitig auf, so dass sie in einigen F\u00e4llen gleichzeitig ausgef\u00fchrt werden k\u00f6nnen. Unternehmen verwenden in der Regel eine einfache Skala von niedrig, mittel oder hoch, jedoch k\u00f6nnen einige Vorf\u00e4lle automatisch in bestimmte Kategorien fallen, je nachdem, was betroffen ist. Wenn der Vorfall beispielsweise mit einem Ausfall zusammenh\u00e4ngt, w\u00fcrde dies automatisch eine hohe Priorit\u00e4t haben.<\/p>\n

<\/p>\n

5. Incident Response, L\u00f6sung und Abschluss<\/h3>\n

Der letzte Schritt besteht darin, endlich zu reagieren und den Vorfall zu l\u00f6sen, um den Abschluss zu bringen. Dieser letzte Schritt ist eher eine Kunstform als eine Wissenschaft. Hier gibt es keinen einfachen Button. Es kann mehrere Zyklen dauern und versucht zu best\u00e4tigen, dass der Vorfall endlich gel\u00f6st ist. Jeder Versuch kann mehr Informationen und zus\u00e4tzliche Theorien dar\u00fcber liefern, warum der Vorfall passieren k\u00f6nnte. Dies kann auch dazu f\u00fchren, dass weitere M\u00f6glichkeiten identifiziert werden, bei denen Schwachstellen vorhanden sein k\u00f6nnen. Sobald der Vorfall behandelt wurde, ist es an der Zeit, die Anfrage zu schlie\u00dfen und dem urspr\u00fcnglichen Benutzer zu antworten, der den Vorfall gemeldet hat.<\/p>\n

<\/p>\n

Postmortems<\/h2>\n

Nach einer Incident-Reaktion ist es in der Regel eine gute Idee, die Details des Incidents vollst\u00e4ndig zu \u00fcberpr\u00fcfen. Dies wird als Postmortem-Vorfall bezeichnet. Die Bestimmung, welche Vorf\u00e4lle eine Obduktion erfordern, wird in der Regel vom Team oder der Organisation entschieden, die Gr\u00fcnde bleiben jedoch die gleichen. Postmortems helfen dabei, Bereiche zu identifizieren, die verbessert werden k\u00f6nnen, blinde Flecken bei der Leistung zu identifizieren und Ihren Incident-Response-Prozess zu verfeinern. Ein Postmortem sollte alle Aspekte des Vorfalls zusammenfassen und die folgenden Elemente enthalten:<\/p>\n