Störfallmanagement für Einsätze

Kapitel 1. Bewertung der Reaktion auf Vorfälle PROZESS

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Definition eines Vorfalls:

Ein von Menschen verursachtes oder natürliches Ereignis, das Maßnahmen oder Unterstützung durch Einsatzkräfte erfordert, um den Verlust von Menschenleben oder Schäden an Eigentum und/oder natürlichen Ressourcen zu verhindern oder zu minimieren. (National Fire Protection Association)

Eine ungeplante Unterbrechung eines IT-Dienstes oder eine Verringerung der Qualität eines IT-Dienstes. (ITIL)

Während du diesen Satz liest, ereignen sich überall auf der Welt IT-Störungen. Die Reaktion auf diese Vorfälle erfolgt in vielen Formen, von einer Person, die an einem Problem arbeitet, bis hin zu einer großen Gruppe von Personen, die sich in eine Konferenzschaltung einwählen oder von überall auf der Welt in eine Vielzahl von Kommunikations-/Workflow-/Produktivitätsanwendungen tippen. Diese Mitarbeiter können ITIL-Prozesse oder DevOps-Prinzipien oder ein intern entwickeltes System oder eine andere Methode verwenden. Die Reaktion kann vollständig organisiert oder völlig chaotisch sein. Aber so oder so, IT-Vorfälle werden gelöst. Die eigentliche Frage ist: "Werden sie so schnell gelöst , wie es möglich ist?"

Hinweis

Zur Veranschaulichung werden wir im gesamten Buch eine Konferenzschaltung als Beispiel für die IRT-Kommunikation verwenden. Es gibt viele Methoden, um während eines Vorfalls zu kommunizieren, einschließlich mündlicher und schriftlicher Kommunikation über viele Technologieplattformen, und nicht alle IRTs verwenden Konferenzbrücken für die Reaktion auf einen Vorfall, aber die Darstellung des gesprochenen Wortes dient als effektive Plattform, um zwischenmenschliche Kommunikation zu veranschaulichen.

Der erste Schritt auf dem Weg zu einer effizienten und gut organisierten Reaktion auf Vorfälle beginnt mit einer ehrlichen Bewertung des Status quo, einschließlich des Lebenszyklus eines Vorfalls (siehe Abbildung 1-1). In vielen Fällen geraten die Einsatzkräfte in ein (gutes oder schlechtes) Reaktionsmuster und halten aus Trägheit daran fest. Manche Einsatzkräfte haben vielleicht einen schweren Vorfall überlebt und sagen: "Wow, das war knapp, ich hoffe, das passiert nie wieder." Es liegt in der Natur der Sache, dass Muster und Gewohnheiten sehr bequem sind und nur schwer durchbrochen werden können.

Abbildung 1-1. Der Lebenszyklus eines Vorfalls

Unabhängig davon, ob du mit der Art und Weise, wie dein Incident Response Team (IRT) auf IT-Notfälle reagiert, zufrieden oder unzufrieden bist, ist es ratsam, zu untersuchen, ob die Leistung verbessert werden kann.

Hinweis

Aus Gründen der Einheitlichkeit wird im weiteren Verlauf dieses Buches der Begriff Incident Response Team (IRT) als allgemeiner Begriff für die Gruppe verwendet, die mit der Eindämmung von Vorfällen innerhalb einer Organisation beauftragt ist. Möglicherweise hat deine Gruppe einen anderen Begriff oder eine andere Organisationsstruktur für die Reaktion auf Vorfälle.

Schließlich stellen Vorfälle in vielerlei Hinsicht ein Risiko für das Unternehmen dar, und keines davon ist gut: Rufschädigung, Vertrauensverlust bei den Kunden, geschwächte Marke, negative finanzielle Auswirkungen und Vertrauensverlust bei den Investoren. Erfolgreiche und effiziente Incident Response Teams haben gemeinsame Merkmale, die leicht zu erkennen sind, wenn du weißt, worauf du achten musst. Unabhängig von einem After Action Review (AAR) (siehe Kapitel 6), der nach der Reaktion auf einen Vorfall stattfindet, kann es sinnvoll sein, den gesamten Prozess der Reaktion auf einen Vorfall in seiner jetzigen Form zu bewerten und zu prüfen, ob es Bereiche gibt, die verbessert werden können.

Zu Beginn ist es sinnvoll, eine Liste mit allgemeinen Fragen zu erstellen, die sowohl quantitativ als auch qualitativ gestellt und beantwortet werden können. Gute Ausgangsdaten über frühere Einsatzstatistiken und/oder die Zusammensetzung deines Einsatzteams bilden die Grundlage für die Bewertung.

Wenn du eine kleine Organisation mit nur wenigen Mitarbeitern bist, mag es offensichtlich erscheinen, wer auf die Lösung von Vorfällen reagiert. Eine der ersten Fragen, die wir den Unternehmen stellen, ist diese: Gibt es hier eine Person, die den gesamten Stack bis ins kleinste Detail versteht, um jedes Problem zu beheben, das auftreten könnte? Die offensichtliche Antwort ist nein, aber wir haben dies bei Unternehmen auf der ganzen Welt bestätigt. Außerdem wird mit dem Wachstum und der Skalierung des Unternehmens der gesamte Stack immer komplizierter und erfordert mehr spezialisierte Problemlöser, was wiederum einen ausgereifteren Incident Management Prozess erfordert. Wenn deine Organisation Unternehmen erwirbt, um ihr Geschäft und ihr Produkt- und Dienstleistungsportfolio zu erweitern, sollten die Incident-Management-Prozesse der übernommenen Unternehmen in der Due-Diligence-Phase des Geschäfts ebenfalls identifiziert, bewertet und überprüft werden. Unabhängig davon, wie dein Unternehmen wächst, solltest du dir Fragen wie die folgenden stellen, um herauszufinden, wie du das Incident Response Team am besten konfigurierst.

Diese Liste von Fragen ist sicherlich nicht vollständig und soll dich lediglich dazu anregen, darüber nachzudenken, wie du eine Grundlage für die Bewertung eines Incident Response Teams schaffen kannst:

• Was ist deine Definition von einem Vorfall und einem Ereignis?

• Auf wie viele Vorfälle reagierst du in einem bestimmten Monat?

• Wie ist das Verhältnis von Vorfällen zu Ereignissen und reagierst du auf beide gleich?

• Wie viele Vorfälle gab es in den letzten zwei Jahren pro Monat?

• Wie viele Ereignisse gab es in den letzten zwei Jahren pro Monat?

• Identifiziere und beschreibe die aktuellen Schwere-/Prioritätsstufen für die Reaktion auf Vorfälle.

• Werden in der gesamten Organisation für die Reaktion auf Vorfälle Schweregrad-/Prioritätsstufen verwendet und/oder einheitlich angewendet?

• Welche Berichte/Datenanalysen zur Reaktion auf Vorfälle gibt es?

• Werden deiner Meinung nach Vorfälle einheitlich und effizient verwaltet und geleitet? Wenn nicht, nenne die Herausforderungen/Hindernisse.

• Gibt es einen festgelegten Plan für die Reaktion und Eskalation, wenn ein Vorfall eintritt?

• Gibt es ein Kernteam, das rund um die Uhr im Einsatz ist, oder ist das Team auf Abruf?

• Stelle eine Liste aller potenziellen Einsatzkräfte (Incident Commanders und SMEs) nach Geschäftsbereichen und geografischen Standorten auf.

• Beschreibe den Schichtplan und die Personalstärke des primären Notfallteams, aufgeschlüsselt nach Standort und Funktion.

• Liste der Drittanbieter, die an der Reaktion auf einen Vorfall beteiligt sind, mit Funktion, Standort und Kontaktinformationen.

• Haben die IRT-Mitglieder Zeitvorgaben für die Reaktion auf einen Vorfall? Werden diese Zeitvorgaben von den Einsatzkräften eingehalten und von der Führungsebene durchgesetzt?

• Welche Herausforderungen gibt es bei der Einbindung von KMU in eine Antwort?

• Gibt es ein Organigramm für die Reaktion auf Vorfälle, in dem das primäre Incident Response Team und alle anderen Beteiligten aufgeführt sind?

• Wie erfolgt die Kommunikation während eines Vorfalls (z. B. Telefonkonferenz, webbasierte Tools usw.)?

• Wird die Sprachkommunikation bei Vorfällen (z. B. Konferenzbrücken, WebEx usw.) aufgezeichnet? Archiviert? Überprüft?

• Ist jemand mit der Vorbereitung und Durchführung der Ursachenanalyse (RCA) und der AARs beauftragt?

• Gibt es einen Prozess, um die aus den AAR-Empfehlungen gewonnenen Informationen in die Entwicklung in Friedenszeiten einfließen zu lassen?

• Welche Rolle spielen leitende Angestellte bei der Reaktion auf einen Vorfall?

Denke daran, dass es bei einer effizienten Reaktion auf einen Vorfall um einen Prozess geht, mit zehn allgemeinen, aber unterschiedlichen Schritten im Lebenszyklus eines Vorfalls:

1. Erkenne das Problem.

2. Bestimme, ob es sich um einen Vorfall oder ein Ereignis handelt.

3. Schicke das entsprechende Incident Response Team los.

4. Stelle das Einsatzteam zusammen (MTTA - mean time to assemble).

5. Setze das Kommando fest, organisiere die Ressourcen und lege die Ziele für den Vorfall fest.

6. Leite die Lösungsbemühungen mithilfe von IMS.

7. Benachrichtige die entsprechenden Interessengruppen.

8. Löse den Vorfall auf und gib die Ressourcen frei.

9. Führe AARs durch.

10. Qualitätsverbesserung (QI) und Qualitätssicherung (QS) umsetzen (mehr dazu später im Kapitel).

Ereignis: Eine Tatsache zu einem bestimmten Zeitpunkt, die für den Betrieb deiner Infrastruktur oder Anwendung relevant ist (z.B. CPU hat die 95%-Schwelle auf host-abc überschritten oder Change #1234 wurde erfolgreich auf host-abc implementiert), aber nicht als Vorfall angesehen wird. Ereignisse erfordern nicht die Einführung des Incident Management Systems (IMS) oder eines Incident Commanders (IC). Ereignisse können sich zu Vorfällen entwickeln.

Es kann sein, dass du eine Version dieser Liste in einer anderen Reihenfolge oder mit einem anderen Schritt hier oder da findest, aber im Großen und Ganzen entwickelt sich ein IT-Vorfall folgendermaßen. In Abbildung 1-1 ist der Lebenszyklus eines Vorfalls dargestellt. QA und QI sind Teil des AAR-Prozesses und werden hier nicht gesondert aufgeführt.

Wir treffen häufig auf Incident Response Teams, die von einem Vorfall überwältigt wurden, der größer und/oder bösartiger wurde und/oder schneller verlief, als sie darauf vorbereitet waren. Vielleicht konnten sie nicht schnell die richtigen technischen Ressourcen zusammenstellen oder waren frustriert, weil nur wenige Teammitglieder "in der Lage waren, einen Vorfall zu bearbeiten". Oder es mangelte an einer klaren und zielgerichteten Führung, was zu einem Chaos auf der Konferenzschaltung oder einem anderen Kommunikationskanal führte. Der erfolgreiche Betrieb von hochzuverlässigen Produktionsumgebungen hängt von einer starken Führung und einem fähigen Team von technischen Experten für Netzwerk, Compute, Speicherung und Anwendungen ab, egal ob es sich um ein kleines DevOps-Team oder ein globales Unternehmensteam handelt. In den täglichen Arbeitsabläufen ist DevOps zum Beispiel ein Teamsport mit einer kollaborativen Methodik, die in einem bestimmten Rhythmus abläuft. Die Reaktion auf Vorfälle ist ebenfalls ein Mannschaftssport, der von einer starken Führung und einem fähigen Team von technischen Experten abhängt, aber das Tempo, in dem sich das Team zusammensetzt und mit der Lösung beginnt, ist anders als bei einem Sprint oder einer anderen nicht vorfallbezogenen Aufgabe.

Wir haben ein Akronym entwickelt, das die sieben wichtigsten Eigenschaften eines effektiven Programms zur Reaktion auf Vorfälle darstellt. PROCESS steht fürPredictable,Repeatable,Optimized,Clear,Evaluated,Scalable undSustainable.

Zu diesem Zweck ist jeder Buchstabe von PROCESS ein voneinander abhängiges Glied in der Reaktionskette auf Vorfälle. Nutze diese Glieder als schrittweises Analyseinstrument, um zu bewerten, wie dein derzeitiger IT-Reaktionsansatz aussieht. Der Lebenszyklus eines Vorfalls ist auch eine Reihe von miteinander verbundenen Schritten, die schrittweise auf dem vorherigen Schritt aufbauen und alle anderen nachgelagerten Schritte beeinflussen. Wenn es dem Unternehmen zum Beispiel wichtig ist, die mittlere Reparaturzeit (MTTR) für einen IT-Vorfall zu verkürzen, musst du jedes Element des Incident Lifecycle betrachten, von der Erkennung eines Problems über die Entsendung des Teams und die Zeit, die es braucht, um das richtige Team zusammenzustellen, bis hin zu den Lösungsbemühungen und dem AAR.

Viele Unternehmen verschwenden schon früh im Lebenszyklus eines Unfalls wertvolle Zeit, weil sie ihre Einsatzkräfte ineffizient entsenden. Außerdem stellen wir fest, dass viele Unternehmen keinen klaren Unterschied zwischen einer Benachrichtigung und einer Meldung machen. Es ist typisch, dass nicht klar unterschieden wird zwischen denjenigen, die über einen Vorfall informiert sind, und denjenigen, die zum Einsatz gerufen werden.

Disposition: Die Kontaktaufnahme mit einer bestimmten Person, die eine bestimmte Funktion (z. B. Datenbank, Netzwerk, Speicherung, Sicherheit), ein Team oder eine andere Gruppe vertritt, um eine benötigte Funktion zum Vorfall zu rufen. Die Disposition unterscheidet sich von der Benachrichtigung dadurch, dass es sich um einen Befehl und nicht um eine Anfrage handelt. Bei der Feuerwehr ist der Einsatz eine Anweisung, die wie jede andere Anweisung zu befolgen ist und nicht verhandelt oder als optional betrachtet wird.

Benachrichtigung: Eine (dringende oder nicht dringende) Nachricht, die an eine Person gesendet wird (z. B. per SMS, Telefon oder E-Mail) und sich in der Regel auf einen Alarm oder Vorfall bezieht. Benachrichtigungen sind als Information gedacht und nicht als Meldung. Benachrichtigungen sind keine Aufforderung zu reagieren, obwohl sie dazu verwendet werden können, Personen über Ereignisse zu informieren.

Zum Vergleich und zur Verdeutlichung kannst du es dir so vorstellen: Die Menschen werden benachrichtigt und die Einsatzkräfte werden losgeschickt.

Warnung: Stellt den Status einer Prüfung/eines Zustands eines Überwachungs-Tools dar, die/der durch ein Ereignis ausgelöst/aufgelöst wurde (z. B. von Pingdom - deine Website ist derzeit DOWN). Alarme werden von Überwachungs-Tools generiert, um eine Anomalie in der Umgebung zu erkennen. Warnungen können der erste Zeitpunkt sein, an dem ein Ereignis erkannt wird. Durch weitere Untersuchungen kann festgestellt werden, ob es sich um ein Ereignis oder einen Vorfall handelt.

Manche Unternehmen wenden die Methode des "Spray and Pray" oder "Group Think" an, bei der sie eine Reihe von technischen Experten, Führungskräften und anderen Personen benachrichtigen, die dann zu Dutzenden an einer offenen Telefonkonferenz (oder einer anderen Kommunikationsmethode) ohne einen bestimmten Leiter teilnehmen, in der Hoffnung, dass die Gruppe das Problem in einer angemessenen Zeit lösen wird. In der Praxis mäandern diese Gruppen auf dem Weg zur Lösung. In anderen Fällen gibt es keine klare Erwartung, dass ein Notfallhelfer nach der Alarmierung mit einem Gefühl der Dringlichkeit auf der Telefonkonferenzbrücke erscheinen muss. Viele Unternehmen sind ziemlich nachlässig, wenn es darum geht, klare Erwartungen an den Bereitschaftsdienst zu definieren und zu kommunizieren. Wenn du auf Abruf bereitstehst, musst du dich sofort darum kümmern, nicht erst in ein paar Minuten oder wenn du gerade mit anderen Dingen beschäftigt bist. Zeit ist Geld und je länger es dauert, das richtige Team zu entsenden und zusammenzustellen, desto länger dauert es, das Problem zu lösen. Du kannst mehr Einsatzkräfte einstellen oder mehr Code schreiben, aber du kannst nicht mehr Zeit gewinnen. Zeit kann nur gespart oder verschwendet werden.

Tipp

Wenn du ein IT-Notfallhelfer bist, ist ZEIT das wichtigste Gut, das es gibt.

Viele Teams (und Unternehmensleitungen) konzentrieren sich darauf, in den ersten Minuten eines Vorfalls nach einer Ursachenanalyse (RCA) zu fragen. Das ist die falsche Frage. Die Frage "Warum ist es passiert?" (Grundursache) ist viel weniger wichtig als die Frage "Wie beheben wir es?" (Lösung des Problems). Unserer Meinung nach solltest du dich zuerst auf die MTTA (Mean Time to Assemble) des richtigen Teams konzentrieren. Mit langsamen MTTAs wirst du keine guten MTTRs haben! In der Anfangsphase eines Vorfalls werden die Fakten erst nach und nach entdeckt. Die besten Entdecker von Fakten sind die technischen Experten, die auf den Vorfall reagieren, denn sie können sich Protokolle ansehen, Abfragen durchführen und Analysen durchführen. Diese KMUs sind die Augen und Ohren des Incident Response Teams. Ohne dringende MTTA von KMUs gibt es keine Daten. Ohne Daten fliegt das Incident Response Team im Blindflug und es können keine Korrekturmaßnahmen ergriffen werden. Konzentriere dich zuerst darauf, das Problem zu beheben und den Dienst wiederherzustellen! Wie wir bei der Feuerwehr sagen: "Wenn du das Feuer löschst, werden die Bedingungen besser".

Sei deshalb hart zu dir selbst und deinen Erwartungen und sei realistisch, wenn es darum geht, deinen aktuellen Prozess zur Reaktion auf Vorfälle zu bewerten. In den meisten Unternehmen lässt sich der MTTA leicht aufheben, wenn das Unternehmen bereit ist, klare Erwartungen zu stellen. Überleg mal: Der MTTA-Teil des Incident Lifecycle umfasst alle Aktivitäten vor der Reaktion. MTTA ist die einzige Aktivität, die vom Incident Response Team kontrolliert wird! Die Lösung eines Vorfalls ist ein Joker, denn deine Betriebsumgebung ist komplex und die Bedingungen des Vorfalls können sich jederzeit ändern. Wir wiederholen es noch einmal, um es zu betonen: MTTA ist die einzige Aktivität, die vom Incident Response Team kontrolliert wird!

Die Antworten, die du findest, wenn du PROCESS als Bewertungsvorlage verwendest, werden von Unternehmen zu Unternehmen unterschiedlich ausfallen, denn es gibt kein Kochbuch. Dies ist eher eine Denkübung, mit der du die verschiedenen Aspekte eines PROZESS-gesteuerten Incident Response Teams erkunden und abbilden kannst, um auf diese Weise Schwachstellen in deinem System zu entdecken und zu beheben.

Vorhersehbar

Die Grundlage exzellenter Incident Response Teams ist Vorhersehbarkeit. Kunden kaufen und erwarten von ihren Dienstleistern 7×24×365 Verfügbarkeit. Wir wissen, dass eine 100%ige Verfügbarkeit fast unmöglich ist, deshalb streben die Unternehmen 99,99% oder mehr an. Tatsächlich werden mit jeder weiteren 9 hinter dem Komma enorme Investitionen getätigt, um die Verfügbarkeit von 99,99% auf 99,999% zu verbessern. Wenn also die ultimative Verfügbarkeit in Produktionsumgebungen schwer zu erreichen ist, ist die Vorhersagbarkeit der Reaktion auf Vorfälle absolut notwendig.

Vorhersehbarkeit bei der Reaktion auf einen Vorfall bedeutet, dass die Rollen und Verantwortlichkeiten sowie das erwartete Verhalten jeder Person vor und nach dem Einsatz klar sind. Es geht darum, Unsicherheiten in der Aufbauphase der Reaktion zu beseitigen. Gibt es klare Erwartungen, welche KMUs für eine bestimmte Art von Vorfall benötigt werden und wer die Führungsrolle des Incident Commanders übernehmen wird? Effiziente Notfallteams, egal wie groß oder klein sie sind, haben klare, genau definierte Abläufe für den Bereitschaftsdienst und ziehen ihre Mitarbeiter zur Verantwortung!

Haben deine technischen Experten in verschiedenen Zeitzonen Bereitschaftsdienst? Gibt es Vertretungen für die Haupt-Bereitschaftsdienstleistenden? Ist ihnen klar, dass "Bereitschaft" bedeutet, dass sie innerhalb eines vom Unternehmen festgelegten Zeitrahmens auf einen Anruf, eine SMS oder eine andere Benachrichtigung reagieren können?

Entscheidend für den Erfolg ist, dass die Einsatzkräfte ihre Rolle verstehen. Bei der Reaktion auf einen Vorfall geht es nicht darum, dass du zur Lösung des Problems kommst, wenn es dir gerade passt. Wenn du auf Abruf zur Verfügung stehst, ist das keine Option. Vielleicht bist du in deinem normalen Job jeden Tag sehr beschäftigt. Wenn du im Dienst bist oder auf Abruf zur Verfügung stehst, musst du sicherstellen, dass du bereit bist, schnell zu reagieren. Sei bereit, willens und in der Lage, dem Ruf zu folgen und das Unternehmen zu schützen!

Die Sicherstellung, dass die Erwartungen an die Reaktion klar sind, ist die am leichtesten zu erreichende Aufgabe, da sie bereits vor dem Eintreten des Vorfalls erledigt werden kann. Die Identifizierung der Akteure oder zumindest der Art von Akteuren, die du brauchen könntest, ist eine Vorplanung und kann weitgehend in einem definierten Reaktionsplan festgehalten und im Rahmen des AAR ausgewertet/verbessert werden. Denke über deine letzten 10 Vorfälle nach und bewerte den MTTA im Hinblick darauf, ob du die richtigen Leute zum Einsatz gebracht hast. Hast du die richtigen Leute dazu gebracht, schnell und mit einem Gefühl der Dringlichkeit zu reagieren? Haben sie sich positiv verhalten und beteiligt? Wenn nicht, warum nicht? Betrachte die Vorhersehbarkeit als den "Wer"-Teil der Reaktion.

Wiederholbar

Wenn nicht klar ist, wer auf einen Vorfall reagiert, wer die Verantwortung trägt und wie du sie für eine Reaktion zusammenbringst, kann deine Reaktion auf Vorfälle verbessert werden.

Wiederholbarkeit ist der "Wie"-Teil der Reaktion, mit dem Ziel, die im Abschnitt Vorhersagbarkeit genannten Personen konsistent und effizient einzusetzen. Hocheffiziente Incident Response Teams haben eine Liste von häufigen oder wahrscheinlichen Vorfallstypen durchgesehen, jedem einen Schweregrad (SEV) zugewiesen, KMUs nach Funktion identifiziert, die reagieren sollen, und die Entsendung von KMU-Respondern auf diese Schweregrade abgestimmt. Für die SEV-Stufe 1 gibt es z. B. eine vorgegebene Liste mit technischen Fachleuten (Netzwerk, Computer, Speicherung, Anwendungen), die für einen bestimmten Vorfallstyp geeignet sind. Jede Organisation ist anders, daher werden wir keine konkreten Beispiele nennen. Es genügt zu sagen, dass die rechtzeitige Erkennung eines IT-Vorfalls, die ein schnelles und spezifisches Einsatzverfahren mit klaren Erwartungen darüber, wann und wie die Einsatzkräfte zusammenkommen (je schneller, desto besser), der Schlüssel zur Vorhersehbarkeit ist. Wiederholbarkeit zeigt, dass jede Reaktion auf jede Art von Vorfall gleich sein sollte, egal zu welcher Tageszeit, an welchem Wochentag oder zu welcher Jahreszeit er auftritt. Vorhersehbare und wiederholbare Reaktionen sollten zum Beispiel um 2:00 Uhr morgens am Weihnachtsmorgen oder um 14:00 Uhr an einem normalen Arbeitstag auf die gleiche Weise erfolgen. Vorhersehbarkeit und Wiederholbarkeit sind der natürliche Feind von Spray and Pray!

Das bedeutet nicht, dass eine Organisation rund um die Uhr im Einsatz sein muss, um eine nachweislich wiederholbare Reaktion zu haben. Es geht vielmehr darum, dass die Einsatzkräfte wirklich verfügbar sind, wenn sie für den Bereitschaftsdienst eingeteilt sind, und dass sie jedes Mal auf dieselbe Weise reagieren.

Optimiert

Die Optimierung baut auf einem vorhersehbaren und wiederholbaren Mechanismus für die Reaktion auf einen Vorfall auf, indem sichergestellt wird, dass die identifizierten Einsatzkräfte die Einsatzregeln bei Vorfällen verstehen und geschult, ausgerüstet und eindeutig darauf vorbereitet sind, das zu tun, was von ihnen verlangt wird. Hast du ein formelles Schulungsprogramm für die Responder (und wir hoffen, dass es auf dem IMS basiert!)? Wird es in deinem Team einheitlich durchgeführt, vor allem, wenn es sich um ein globales Team handelt? Versteht jeder, welche Rolle er bei der Reaktion auf einen Vorfall spielt? Gibt es klare Eskalationsrichtlinien? Welche Bedingungen müssen erfüllt sein, um eine Eskalation auszulösen? Wer erhält die Eskalation?

Eskalation: Die Hinzufügung von mehr oder anderen Ressourcen (KMUs, Teams, externen Anbietern usw.), die über die ursprüngliche Entsendung hinaus zur Lösung eines Vorfalls erforderlich sind. Wenn der IC z. B. mehr oder andere Datenbankadministratoren (DBAs) für einen Vorfall benötigt, sollte er diese zusätzlichen Ressourcen hinzuziehen. Eskalation kann auch bedeuten, dass interne Stakeholder innerhalb des Unternehmens auf einer höheren Ebene als der IC benachrichtigt oder anderweitig kontaktiert werden. Dies könnte bedeuten, dass ein Vorfall an die Unternehmensleitung eskaliert wird.

Wenn du mit Verkäufern oder anderen Dritten zusammenarbeitest, wissen sie, wie sie reagieren und sich beteiligen sollen? Teilen sie das gleiche Gefühl der Dringlichkeit wie du? Wird das Konzept der Einsatzleitung allgemein verstanden und umgesetzt?

Es ist leicht, diejenigen zu erkennen, die es einfach "nicht kapieren", wenn es darum geht, das Gefühl für die Dringlichkeit und die Konzentration zu haben, die erforderlich sind, um einen Vorfall zu lösen, oder die sich von vornherein durch den Bereitschaftsdienst belästigt fühlen. Wurde ihnen jedoch die Bedeutung des Notfallplans erklärt? Wurden sie in ihrer individuellen Rolle und der Rolle ihres Teams bei der Reaktion auf Vorfälle geschult? Die Reaktion auf Vorfälle ist ein Mannschaftssport und lässt keinen Platz für Egoismus und mangelndes Vertrauen innerhalb des Teams. Es ist wichtig, die Mitarbeiter zur Verantwortung zu ziehen, aber es ist unfair, wenn sie zur Verantwortung gezogen werden, ohne dass sie jemals geschult oder über die Erwartungen des Unternehmens informiert wurden. In unserer Beratungspraxis betonen wir die Notwendigkeit, alle potenziellen Einsatzleiter, technischen Experten, Führungskräfte, Lieferanten und alle anderen Personen, die zum Einsatz gerufen werden könnten, zu identifizieren. Auf diese Weise können wir sicherstellen, dass sie alle ein spezielles Incident Response Training absolviert haben und die Erwartungen genau kennen, so dass zumindest jeder Incident Responder weiß, was von ihm erwartet wird und darauf vorbereitet ist, einen angemessenen Beitrag zu leisten. Vorhersehbarkeit ist das "Wer" und Wiederholbarkeit ist das "Wie" der Reaktion auf Vorfälle. Die Optimierung ist der Teil des PROZESSES, bei dem du sicherstellen musst, dass alle geschult und ausgerüstet sind, um die Aufgabe zu erfüllen!

Klar

Klarheit stellt sicher, dass die allgemeinen programmatischen Ziele und die Ziele der Reaktion auf einen Vorfall allen IRT-Mitgliedern und allen anderen, die an einer Reaktion teilnehmen können, vermittelt werden. Es ist leicht anzunehmen, dass alle, die in irgendeiner Funktion an der Reaktion auf einen Vorfall beteiligt sind, sich über die Ziele der Bemühungen zur Behebung des Vorfalls im Klaren sind. Leider ist das nicht immer der Fall. Häufig stellen wir fest, dass den IT-Mitarbeitern nicht klar ist, warum sie in Bereitschaft versetzt oder gebeten werden, an einer Konferenzschaltung teilzunehmen. Wir hören das häufig, wenn wir uns aufgezeichnete Überbrückungen für unsere Kunden anhören. Ein technischer Experte meldet sich und fragt: "Warum bin ich hier?" oder "Warum braucht ihr mich?" Es kommt zu einer Diskussion, um den Experten darauf einzustimmen, dass er zur Lösung eines IT-Problems hinzugezogen wurde. Es wird wertvolle Zeit verschwendet, die nicht wiedergewonnen werden kann. Deshalb muss sichergestellt werden, dass alle, die zu einem Einsatz gerufen werden, genau wissen, warum sie gerufen werden, welche Aufgabe sie haben und wann sie vom IC wieder entlassen werden.

Diese Erwartungshaltung beginnt an der Spitze des Organigramms des Unternehmens. Es ist von entscheidender Bedeutung, dass die Führungskräfte den Ton für die Entwicklung und Unterstützung der Reaktion auf Vorfälle angeben, indem sie den Bemühungen sowohl innerhalb des IRT als auch im gesamten Unternehmen einen Wert beimessen. Die Führungskräfte sollten sich bemühen, eine Kultur der Reaktion auf Vorfälle aufzubauen, die Vorhersehbarkeit, Wiederholbarkeit und Optimierung des Teams sicherstellt. Auch hier scheint es einfach zu sein, aber es ist wichtig, dass alle Einsatzkräfte wissen und verstehen, was von ihnen erwartet wird, wenn sie zu einem Einsatz gerufen werden, und dass die Konsistenz, mit der das Team auf einen Vorfall reagiert, gewährleistet ist. Damit die Reaktion auf einen Vorfall erfolgreich ist, müssen dieser Denkprozess und die Unterstützung in der Unternehmenskultur verankert sein. Die Art des IT-Vorfalls kann und wird variieren, aber die Vorgehensweise bei der Reaktion auf einen Vorfall sollte klar und einheitlich sein.

Ist allen Einsatzkräften wirklich klar, dass sie im Grunde genommen die Feuerwehr des Unternehmens sind? Wir hören viele Hinweise auf die Feuerwehr von Ingenieuren, KMUs und Führungskräften, die sich mit der Zuverlässigkeit von Standorten beschäftigen. Ein Beispiel dafür ist das Wort Triage, das in der IT-Branche häufig verwendet wird. Es stammt aus der Notfallmedizin und bedeutet, dass man bei einem Vorfall mit vielen Opfern Prioritäten setzt. Die erste Person, die auf ein IT-Problem reagiert, ist buchstäblich ein Ersthelfer. Wenn sich das Problem zu einem Vorfall ausweitet, muss auch die Reaktion angepasst werden, ähnlich wie bei einem Feuer, das zu einem zweiten, dritten oder vierten Alarm eskaliert. Seltsam ist, dass viele Responder die Verbindung zwischen der öffentlichen Sicherheit und den IT-Respondern nicht sehen und auch nicht das damit einhergehende Verantwortungsgefühl spüren. "Wir sind so sehr damit beschäftigt, Brände zu löschen", sagte ein Ingenieur, "dass ich keine Zeit finde, meinen normalen Job zu machen!" Anders ausgedrückt: Während der Rest des Unternehmens das Geschäft aufbaut, sollten die Incident Responder das Unternehmen vor Schaden bewahren.

Betrachte den Punkt der Klarheit so: Wir müssen bei einer Antwort nicht alle auf die gleiche Weise denken, aber wir müssen in die gleiche Richtung denken, mit dem gleichen Blickwinkel, der gleichen Zielsetzung, Methodik und dem gleichen Fokus.

Bewertet

Bis zu diesem Punkt lag der Schwerpunkt darauf, die Voraussetzungen für ein ausgezeichnetes Programm zur Reaktion auf Vorfälle zu schaffen. Wir werden den AAR-Prozess in Kapitel 6 besprechen, aber bis dahin solltest du dir darüber im Klaren sein, dass jede Reaktion auf einen Vorfall die Gelegenheit bietet, zu lernen, wie man auf den nächsten Vorfall besser reagieren kann. Wie wir im Incident Management seit Jahren hören: "Eine gute Krise darf man nicht vergeuden!" Wenn du dir die Zeit und Mühe nimmst, jeden Teil des Lebenszyklus eines Vorfalls objektiv und genau zu betrachten, von der Entdeckung eines Problems über die Entsendung von Einsatzkräften und die Zusammenstellung des Notfallteams bis hin zur endgültigen Lösung des Vorfalls, wirst du mit Sicherheit Lektionen lernen oder Bereiche finden, die verbessert werden können. Die Bewertung ist der Teil, in dem die Qualitätssicherung (QS) und die Qualitätsverbesserung (QI) an den PROZESS anknüpfen.

Qualitätssicherung (QA)

Einen objektiven Blick auf ein Verhalten, eine Entscheidung oder einen Umstand werfen und ihn mit den festgelegten Standards vergleichen, um sicherzustellen, dass das erwartete Verhalten auch tatsächlich eintritt.

Qualitätsverbesserung (QI)

Auffinden von Möglichkeiten, Schwächen oder fehlenden Teilen des Reaktionsmechanismus auf Vorfälle und Ergreifen von Maßnahmen zur Korrektur/Verbesserung der Mängel.

QA und QI sind Investitionen, die sich auf lange Sicht auszahlen. Wenn du den Reaktionsprozess, die Art und Weise, wie die technischen Experten den Vorfall gelöst haben, und/oder die Führungsfähigkeiten des Incident Commanders optimierst, kannst du Schwachstellen aufdecken, die dich daran hindern, eine hervorragende Leistung zu erbringen. Auf dem Gebiet der "tadellosen Nachuntersuchungen" wird viel getan, und wir begrüßen diese Bemühungen. Die IT-Umgebungen von heute sind groß und komplex. Nicht jeder Anwendungsfall lässt sich vorhersehen oder die Konfiguration für einen einwandfreien Betrieb mit allen anderen Elementen im Stack testen. Auch Zwischenfälle bieten die Möglichkeit, Fehler zu finden und zu beheben. Schaffen wir eine Lernkultur, in der Informationen über Vorfälle zur Verbesserung des Betriebs genutzt werden. Es geht darum, besser zu werden - nicht darum, Fehler zu finden oder Schuld zuzuweisen!

Wenn du "Landminen" für schlechte oder inkonsistente Leistungen entdeckst, musst du sie identifizieren, sie anerkennen und alles tun, um die Mängel zu verbessern. Ohne eine durchdachte Methode zur objektiven Bewertung des Reaktionsprozesses auf Vorfälle können schlechte Leistungen zur Norm werden, und es wird schwieriger sein, die Kultur zu ändern.

Skalierbar

Ein starkes Merkmal von IMS ist, dass es sowohl für das kleinste Startup-Unternehmen mit ein paar Mitarbeitern als auch für die größten Unternehmen mit Niederlassungen auf der ganzen Welt funktioniert. Die Skalierbarkeit des Prozesses hängt mit der Vorhersehbarkeit und Wiederholbarkeit zusammen, denn ein solider Prozess zur Reaktion auf Vorfälle kann schnell wachsen oder schrumpfen, je nach den Anforderungen des Vorfalls oder dem Wachstum des Unternehmens. Letzteres bezieht sich auf die Skalierbarkeit auf Programmebene und nicht auf die Ebene des Vorfalls, aber mit dem Wachstum der Organisation wächst auch der Bedarf an einem größeren und tieferen Ressourcenpool. Wir bezeichnen dies als " Bench Strength". Die Stärke der Ersatzbank ist vergleichbar mit der Skalierbarkeit von Sportmannschaften, die auf eine Vielzahl von gleichwertigen Talenten zurückgreifen können, um die Lücken zu füllen, die durch das Auswechseln, Ausruhen oder Ersetzen von Spielern während des Spiels entstehen. Wenn ein Unternehmen zum Beispiel wächst, wird wahrscheinlich auch die Zahl der Vorfälle steigen und das Unternehmen wird mehr qualifizierte Leute brauchen, um den Produktionsbetrieb und die Vorfälle zu bewältigen. Die Bankstärke trägt sowohl zur Skalierbarkeit als auch zur Nachhaltigkeit von PROCESS bei.

Für die IT-Abteilung ist es wichtig, Urlaube, Krankheitszeiten, Reisen, Schichtabdeckungen usw. zu berücksichtigen, um jederzeit ein hohes Maß an Kompetenz und Verfügbarkeit der Einsatzkräfte zu gewährleisten. Da man nicht weiß, wann der nächste große Vorfall eintritt, sollte die IT-Abteilung wie die Feuerwehr immer einsatzbereit sein. Ein Team, das über eine starke Bank verfügt, hat nicht nur eine Handvoll Starspieler. Es besteht aus einer Reihe von Talenten, die ausgetauscht, hinzugefügt oder erweitert werden können, um den jeweiligen Bedarf zu decken. Wir haben beobachtet, wie die Umgebungen unserer Kunden immer größer und komplexer wurden, weil wir die Kapazitätsplanung für den künftigen Bedarf mit Programmen zur technologischen Erneuerung kombiniert haben, und das alles in der Geschwindigkeit von kontinuierlichen Code-Releases. Das hat zur Folge, dass diese Umgebungen häufiger fehlschlagen und im Laufe der Zeit ein gezielteres Incident Management erfordern.

Im Idealfall legt das Incident Response Team seine Identität und die verfügbaren Ressourcen nach Funktionen fest, damit es nicht nur von einer Handvoll Personen abhängig ist, die regelmäßig reagieren. Viele IT-Umgebungen sind bereits so komplex, dass es eine ganze Reihe von Fachleuten braucht, um die verschiedenen betrieblichen Details zu verstehen. Nicht selten sind ganze Entwicklungsteams, Anwendungsteams und Datenbank-/Speicher-/Netzwerkexperten erforderlich, um einen einzigen IT-Vorfall zu lösen. Mit zunehmender Größe und Komplexität steigt auch die Spezialisierung und die Notwendigkeit, eine größere Anzahl und Komplexität von IT-Störungen zu bewältigen, die möglicherweise gleichzeitig auftreten. Wenn du in der Lage bist, schnell eine größere Anzahl unterschiedlicher und hochqualifizierter technischer Experten, möglicherweise aus der ganzen Welt, zu entsenden und zu erhalten, wird dies dazu beitragen, eine Kultur der effektiven Reaktion in der Organisation aufzubauen.

Nachhaltig

Wenn das Verkaufsteam wachsen muss, Talente verliert oder seine Strategie aufgrund einer veränderten Geschäftsausrichtung oder -philosophie anpassen muss, geht das Unternehmen diese Probleme schnell an, indem es mehr Mitarbeiter einstellt oder umorganisiert, um das Risiko eines finanziellen Verlusts zu vermeiden. Wenn die Reaktion auf Vorfälle über die anfängliche Schulung hinausgeht und zu einer formellen Aktivität innerhalb eines Unternehmens wird, muss das Unternehmen das Incident Response Team wie jede andere Geschäftseinheit betrachten, pflegen und wertschätzen.

Nachhaltigkeit bedeutet, dass die Incident Response in der Tat genauso wertvoll ist wie jeder andere Unternehmensbereich und dass sie das gleiche finanzielle Engagement, die gleiche Führungsrolle und die gleiche organisatorische Entwicklung verdient. Incident Response im IT-Bereich sollte nicht als notwendiges Übel betrachtet werden, wie wir es in vielen Unternehmen gesehen haben. Der Bereitschaftsdienst sollte innerhalb der Organisation respektiert werden, um großartige und qualifizierte Talente anzuziehen. Der Bereitschaftsdienst ist manchmal schmerzhaft - niemand steht gerne regelmäßig mitten in der Nacht auf - aber diese Unannehmlichkeiten sind entscheidend für die finanzielle Gesundheit und das Wohlergehen des Unternehmens.

Wir sagen das alles, um diesen Punkt der Nachhaltigkeit zu unterstreichen. Nur wenige in der IT-Notfallbranche haben eine formale Ausbildung zum Notfallsanitäter erhalten. Vielmehr werden sie aufgrund ihrer technischen Fähigkeiten oder ihrer einzigartigen Kenntnisse einer Betriebsumgebung ungewollt zur "Speerspitze" der Incident Response. Weil eine Person ein hervorragender Ingenieur ist, wird sie vielleicht dem Incident Response Team zugewiesen. Der Betrieb, insbesondere die Reaktion auf Vorfälle als Teil des Betriebs, ist der Ort, an dem sich Technologie und Fehler überschneiden, und der Prozess zur Behebung von Vorfällen muss effizient sein, damit der Betrieb weiterläuft. Zu diesem Zweck wird häufig ein großes technisches Talent mit einer Schulung zur Störungsbehebung kombiniert, um die betreffende Person zum Incident Responder zu ernennen, unabhängig davon, ob sie für diese Aufgabe geeignet ist oder nicht. In vielen Fällen funktioniert dieser Ansatz gut, und die Personen machen einen reibungslosen Übergang vom technischen Experten zum technischen Experten für die Reaktion auf Zwischenfälle, was nicht unbedingt dasselbe ist. Aber oft funktioniert es auch einfach nicht.

Auch hier gilt, dass die Etablierung einer Kultur der formalisierten Reaktion auf Vorfälle und die Betreuung des Teams durch Unterstützung, Führung und finanzielles Engagement die Anwerbung und Bindung großartiger Talente erheblich erleichtert.

Zusammenfassung

Das Ziel eines jeden Unternehmens ist es, zu wachsen und Werte zu schaffen. Jeder Mitarbeiter hat eine Aufgabe und die meisten verbringen ihre Zeit damit, das Unternehmen aufzubauen. Incident Responder schützen das Unternehmen vor den Risiken, die mit Serviceunterbrechungen und Ausfällen verbunden sind. IT Incident Response ist ein eigener Fachbereich und sollte für seinen Beitrag zum langfristigen finanziellen Wohlergehen des Unternehmens geschätzt werden. Der erste Schritt zum Aufbau eines erfolgreichen Störungsmanagement-Teams ist eine ehrliche Bewertung des Status quo. Die folgende Liste der wichtigsten Punkte und Konzepte ist eine Zusammenfassung von PROCESS in einem leicht verdaulichen Format:

• PROZESS ist ein Akronym, das du als programmatisches Bewertungsinstrument verwenden kannst. Wenn du die einzelnen Punkte als Leitfaden für eine Diskussion über die verschiedenen Aspekte deines Prozesses zur Reaktion auf Vorfälle verwendest, kannst du herausfinden, in welchen Bereichen du dich verbessern kannst.

• Es sollte kein Zweifel daran bestehen, wer zur Verfügung steht und wer im Talentpool für die Reaktion auf Vorfälle verfügbar ist.

• Du solltest in der Lage sein, jede Minute jeder Geschäftsstunde auf die gleiche Weise zu reagieren.

• Die Teammitglieder sollten geschult, ausgerüstet und bereit sein, die Aufgaben zu erfüllen, die das Unternehmen von ihnen verlangt.

• Jeder im Incident Response Team sollte genau wissen, was von ihm erwartet wird, welche Rolle er spielt, welchen Entscheidungsspielraum er bei einem Vorfall hat und dass er die Unterstützung der Geschäftsleitung hat, um Vorfälle zu lösen und das Unternehmen zu schützen.

• Ein guter Prozess zur Reaktion auf einen Vorfall kann schnell erweitert und verkleinert werden, um den Anforderungen des Vorfalls gerecht zu werden.

• Erfolgreiche Incident-Response-Programme sind so aufgebaut, dass sie nachhaltig sind, wenn es darum geht, die besten Talente zu rekrutieren und zu halten.

• Eine Organisation sollte eine Kultur der Reaktion auf Vorfälle aufbauen und aufrechterhalten und sie als genauso wichtig wie jede andere Geschäftseinheit betrachten.

• Es gibt einen Unterschied zwischen Ereignis, Alarm, Vorfall, Einsatz und Benachrichtigung. Wenn dein Unternehmen das noch nicht allen Einsatzkräften und dem gesamten Unternehmen klar gemacht hat, solltest du das tun. Wir treffen auf viele Unternehmen, die das nicht getan haben, und das sorgt für Verwirrung, wenn es darum geht, das richtige Team zur richtigen Zeit zusammenzustellen, um die richtigen Dinge zu tun.