In der Welt eines Site Reliability Engineer (SRE)ist ein Ausfall nicht nur eine Option, sondern auch zu erwarten. Systeme, Webanwendungen, Server, Geräte usw. sind alle anfällig für Leistungsprobleme und unerwartete Ausfälle an einem bestimmten Punkt. Es ist eine unvermeidliche Tatsache. Diese unerwarteten Ausfälle können zu enormen Umsatzeinbußen, Kundenvertrauen und je nach Branche zu Bußgeldern führen. Glücklicherweise ist das SRE-Vorfallmanagement eine der Kernpraktiken, um die durch unerwartete Probleme verursachten Störungen zu begrenzen. In einem anderen Artikel haben wir über Chaos Engineering gesprochen und darüber, wie SRE-Teams proaktiv nach Fehlern suchen und diese testen, um das Schlimmste zu verhindern. Wie wir jedoch alle wissen, können Probleme durch die Risse schlüpfen. Ziel ist es, zu verhindern, dass diese Vorfälle zu großflächigen kaskadierenden Ausfällen werden. SREs und DevOps-Teams können diese Vorfälle nutzen, um ihre Systeme und Services besser aufzubauen und zu verbessern.
Was ist ein Vorfall?
Bevor wir uns mehr mit diesem Thema befassen, müssen wir zuerst besprechen, was ein Vorfall ist. Wo verläuft die Grenze zwischen etwas, das sofortiges Handeln erfordert, und etwas, das später untersucht werden kann? Wenn jedes Problem als dringend eingestuft würde, würde niemand eine Lösung bekommen. Im Kontext der IT (Informationstechnologie) ist ein Vorfall einfach ein Ereignis oder Problem, das den normalen Betrieb oder die Servicequalität stört. Es hat nicht zu einem Fehler geführt, aber wenn es nicht überprüft wird, hat es die Möglichkeit, größere Auswirkungen auf Ihre Dienste und Abläufe zu haben. Und sie passieren normalerweise um 2:00 Uhr morgens, während Sie glückselig schlafen und durch das Geräusch Ihres Telefons geweckt werden. Wir machen natürlich Witze, aber Sie wissen, dass etwas schlecht ist, wenn es so früh am Morgen passiert. Um 2:00 Uhr morgens passiert nichts Gutes.m, besonders wenn wir über die IT-Branche sprechen.
Was ist Incident Management?
Nun, da wir darüber gesprochen haben, was ein Vorfall ist, ist das Incident Management der Prozess, mit dem Teams diese Ereignisse lösen und Systeme und Dienste wieder in den normalen Betrieb bringen. Wir sollten auch beachten, dass das Incident Management nur ein Element eines größeren 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).
ITIL bietet den Rahmen und die Richtlinien für den Aufbau von ITSM-Lösungen. Möglicherweise 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).
Das IT Service Management (ITSM) Framework
Wenn wir einen Schritt zurücktreten 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.
Servicekatalog
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ützliche Informationen zu aktuellen und geplanten Services sowie zu Preisen, Einkaufsprozessen, Ansprechpartnern und anderen Leistungen.
Service-Desk
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ützung 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.
Problemmanagement
Wenn wir über Incident Management sprechen, kann ein SRE-Team einen Vorfall möglicherweise schnell lösen, aber das zugrunde liegende Problem kann immer noch bestehen und noch eine Weile bestehen. Problemmanagement ist der Prozess, durch den die Ursachen von Vorfällen dauerhaft behoben werden, was die langfristige Leistung und zukünftige Servicebereitstellungen verbessert.
Veränderungsmanagement
Jede Art von Änderung, ob es sich nun um neue Servicebereitstellungen oder persönliche Änderungen handelt, es besteht immer ein gewisses Risiko. Änderungsmanagement ist der Prozess, bei dem ermittelt wird, wie sich Änderungen auf die Servicebereitstellung auswirken und/oder die Auswirkungen auf das Unternehmen selbst berücksichtigt werden. Das Änderungsmanagement wird manchmal auch mit dem Release-Management gruppiert.
Vermögensverwaltung
Man kann nicht alles virtualisieren… noch. Softwaredienste erfordern immer noch physische Geräte und Hardware, damit sie funktionieren. Und Unternehmen müssen diese Geräte verfolgen, verwalten und kontinuierlich aktualisieren, um sicherzustellen, dass ihre Dienste reibungslos ausgeführt werden können. Asset Management wird auch als IT Asset Management oder ITAM bezeichnet.
Wissens-, Richtlinien- und Verfahrensmanagement
Das Ziel des Wissensmanagements ist es, Redundanzen in Bezug auf das Sammeln, Überprüfen und Teilen von Informationen innerhalb einer Organisation zu reduzieren. Dies trägt zur Verbesserung der Effizienz bei und stellt sicher, dass die Informationen konsistent, aktuell und verfügbar sind.
Incident Management Lifecyle: Prozess und Schritte
Die Reaktion eines Unternehmens auf einen Vorfall, unabhängig davon, ob es sich um Ausfallzeiten, Sicherheitsverletzungen oder Cyberangriffe oder sogar um längere Latenzzeiten und wiederholte Fehler handelt, ist entscheidend für den anhaltenden Erfolg des Unternehmens und das Vertrauen des Kunden oder Endbenutzers. SREs müssen komplexe verteilte Systeme verwalten. Während die Vorteile dieser Systeme darin bestehen, dass sie zuverlässiger, skalierbarer und fehlertoleranter sind, sind sie dadurch auch extrem komplex, was zu längeren Behebungszeiten führen 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ährend die tatsächlichen Schritte und Prozesse zwischen den Organisationen variieren können, folgen die meisten dem gleichen grundlegenden Pfad. Schauen wir uns den SRE-Incident-Management-Prozess und die SRE-Schritte an.
1. Identifizierung von Vorfällen
Sie können keine Probleme beheben, die Sie nicht kennen. Die Identifizierung von Vorfällen beginnt mit einer Form von Überwachungs- oder Alarmierungsmechanismus. Wir haben in einem anderen Artikel über die Überwachung verteilter Systeme 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ällen wird ein Vorfall jedoch durch ein Support-Ticket, einen Anruf oder sogar soziale Medien bekannt, was nie eine gute Nachricht ist, wenn Probleme öffentlich für alle sichtbar veröffentlicht werden.
2. Protokollierung von Vorfällen
Unabhängig 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ür die überprüfung von Vorfalltrends zu einem späteren Zeitpunkt. Wenn derselbe oder ein ähnlicher 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.
3. Kategorisierung von Vorfällen
Als nächstes folgt die Kategorisierung des Vorfalls basierend auf Faktoren wie Schweregrad, Dringlichkeit oder betroffenem Funktionsbereich. Wie bei der Protokollierung des Vorfalls können je mehr Informationen bereitgestellt werden, später bei der Bestimmung des richtigen Teams oder der richtigen Person für die Reaktion auf Vorfälle hilfreich sein.
4. Priorisierung von Vorfällen
Basierend darauf, wie der Vorfall kategorisiert wurde, besteht der nächste Schritt darin, die Prioritätsstufe festzulegen. Auch hier treten einige dieser Schritte gleichzeitig auf, so dass sie in einigen Fällen gleichzeitig ausgeführt werden können. Unternehmen verwenden in der Regel eine einfache Skala von niedrig, mittel oder hoch, jedoch können einige Vorfälle automatisch in bestimmte Kategorien fallen, je nachdem, was betroffen ist. Wenn der Vorfall beispielsweise mit einem Ausfall zusammenhängt, würde dies automatisch eine hohe Priorität haben.
5. Incident Response, Lösung und Abschluss
Der letzte Schritt besteht darin, endlich zu reagieren und den Vorfall zu lösen, 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ätigen, dass der Vorfall endlich gelöst ist. Jeder Versuch kann mehr Informationen und zusätzliche Theorien darüber liefern, warum der Vorfall passieren könnte. Dies kann auch dazu führen, dass weitere Möglichkeiten identifiziert werden, bei denen Schwachstellen vorhanden sein können. Sobald der Vorfall behandelt wurde, ist es an der Zeit, die Anfrage zu schließen und dem ursprünglichen Benutzer zu antworten, der den Vorfall gemeldet hat.
Postmortems
Nach einer Incident-Reaktion ist es in der Regel eine gute Idee, die Details des Incidents vollständig zu überprüfen. Dies wird als Postmortem-Vorfall bezeichnet. Die Bestimmung, welche Vorfälle eine Obduktion erfordern, wird in der Regel vom Team oder der Organisation entschieden, die Gründe bleiben jedoch die gleichen. Postmortems helfen dabei, Bereiche zu identifizieren, die verbessert werden können, 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:
- Zusammenfassung und Zeitleiste des Vorfalls auf hoher Ebene.
- Ursachenanalyse und Quelle des Vorfalls.
- Maßnahmen zur Lösung des Vorfalls und welche wirksam oder nicht wirksam waren.
- Zukünftige Vorfallprävention zusammen mit zusätzlichen Informationen, die entdeckt wurden.
Postmortems sind eine der Kernregeln der SRE-Kultur. Tatsächlich nennen sie es schuldloses Postmortem. Die Idee hinter diesem Konzept ist, dass jeder im Team mit den besten Absichten gehandelt hat und niemand an dem Vorfall schuld ist. Der Fokus liegt darauf, herauszufinden, warum es passiert ist und wie die Systemleistung in Zukunft verbessert werden kann. Fehler sind ein natürlicher Teil der Branche, daher liegt der Fokus darauf, ein robusteres, widerstandsfähigeres System zu schaffen, damit Probleme nie wieder auftreten.
Fazit: SRE Incident Management – Übersicht, Techniken und Tools
Das SRE-Incident-Management ist entscheidend, um Systeme, Anwendungen, Standorte und Services am Laufen zu halten. Sekunden sind wichtig, besonders wenn es um die Benutzererfahrung geht. In großen verteilten Systemen kann das kleinste Problem kaskadierende Probleme verursachen. Das proaktive Einrichten der richtigen Warnungen und Benachrichtigungen kann den Unterschied ausmachen, wenn Probleme auftreten, und sicherstellen, dass die Auswirkungen auf die Benutzer begrenzt sind. Weitere Informationen darüber, wie sich die Dotcom-Monitor-Plattform in diese Incident-Management-Tools integriert, finden Sie in unserer Knowledge Base.
Testen Sie Dotcom-Monitor kostenlos und erhalten Sie Zugriff auf alle Lösungen, Integrationen und Funktionen innerhalb der Plattform.
