Störfallmanagement für Einsätze

Kapitel 4. Skalierung der Incident Response

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

Reaktion auf Vorfälle und Eskalation

Kleine Vorfälle mit geringer Auswirkung erfordern in der Regel weniger Personal und einen geringeren Managementrahmen und beruhen vielleicht mehr auf der Problemlösung durch Einzelpersonen. Große Probleme mit großen Auswirkungen erfordern in der Regel mehr Einsatzkräfte, einen größeren Managementrahmen, mehr Teamarbeit, mehr zu erledigende und zu verfolgende Aufgaben, mehr Stress und eine größere Auswirkung auf das Geschäft, die berücksichtigt werden muss. Diese größeren Vorfälle erfordern in der Regel einen robusten Managementrahmen, um organisiert zu bleiben, und einen stärkeren Incident Commander, um die Bemühungen auf eine klare und zielgerichtete Weise voranzutreiben.

Es gibt keine perfekte Managementformel für jede Situation und keine festen Regeln. Es liegt an jedem Incident Commander, die richtige Mischung aus Führung und Rahmenbedingungen zu finden, um die effektivste Lösung für einen Vorfall zu finden, die auf die Größe und den Umfang des Vorfalls abgestimmt ist. Ein guter Incident Commander muss wissen, wie er die Elemente der Führung, des Rahmens und der Problemlösung gekonnt mischt.

In manchen Fällen mag es unnötig erscheinen, bei einem scheinbar unbedeutenden Problem (Green- oder Yellow-Box-Problem) eine formale Befehlsstruktur einzuhalten, aber sieh es doch einmal so: Jede Reaktion auf einen Vorfall stärkt die Anwendung des Prozesses für alle Einsatzkräfte, denn Fähigkeiten und Fertigkeiten werden durch Wiederholung erlernt.

Wenn das IMS nur bei großen Ereignissen (Red- oder Blackbox-Ereignissen) aktiviert wird, sind diese Fähigkeiten und Fertigkeiten möglicherweise nicht vorhanden, um den Prozess schnell und erfolgreich einzusetzen, wenn es wirklich darauf ankommt. Deshalb sollten die Einsatzkräfte jede Gelegenheit nutzen, um den Übergang von der Friedens- zur Kriegszeit zu üben und sich so weit zurechtzufinden, dass die Anwendung des Systems nicht so chaotisch ist wie der Vorfall selbst.

Wenn du immer das IMS verwendest, sind die Rahmenbedingungen und der Incident Commander vorhanden und bereit, bei Bedarf zu eskalieren, egal wie unbedeutend ein Problem zunächst erscheinen mag.

Kontrollspanne

Als Menschen haben wir alle Grenzen, wie viele Informationen wir in einem bestimmten Moment verarbeiten können oder wie viel Aufmerksamkeit wir konkurrierenden Gesprächen oder Aufgaben schenken können, besonders unter Stress. In Friedenszeiten ist Multitasking alltäglich. In Kriegszeiten sollten Einsatzkräfte darauf achten, dass sie nicht von zu vielen Daten, zu vielen gleichzeitigen Gesprächen oder zu vielen Aufgaben, die in einem engen Zeitrahmen erledigt werden müssen, überwältigt werden. Es ist wichtig, die eigenen Grenzen und die der anderen zu erkennen und sich nicht bis zum Äußersten zu verausgaben, vor allem, wenn man während eines Vorfalls Menschen unter Stress führt.

Der Kontrollbereich ist die maximale Anzahl von Personen, die eine Person verwalten kann. Normalerweise liegt diese Zahl bei 5-7 Personen. Die Einhaltung einer akzeptablen Kontrollspanne stellt sicher, dass eine einheitliche Befehlsgewalt bzw. klare Befugnisse für die Berichterstattung hat. Wenn 30 Personen an einer Konferenzschaltung teilnehmen, mit oder ohne einen bestimmten Leiter, kann das Gespräch schnell unproduktiv werden und den Fokus verlieren, wodurch Zeit vergeudet wird, die nicht zurückgewonnen werden kann.

Vereinfacht ausgedrückt ist die Kontrollspanne eine Managementtaktik für den Incident Commander. Sie kommt zum Einsatz, wenn viele Einsatzkräfte so organisiert werden müssen, dass die Kontrolle über die zugewiesenen Aufgaben und die notwendigen Diskussionen erhalten bleibt. Es geht darum, eine große Anzahl von Aufgaben in kleinere, überschaubare Aktivitäten aufzuteilen und die Arbeit so zu delegieren, dass sie effizient nachverfolgt und verwaltet werden kann.

Das soll nicht heißen, dass die empfohlene Kontrollspanne von 5-7 Direktunterstellten niemals überschritten werden darf. Erinnere dich daran, dass Vorfälle dynamisch sind und sich oft sehr schnell und dramatisch ändern können, aber bleibe nicht bei einer zu großen Kontrollspanne hängen.

Lass uns das Konzept der Kontrollspanne anhand dieses Beispiels mit dem CAN-Berichtsformat in die Praxis umsetzen:

Bedingungen

• Die Systemleistung hat sich nach einer kürzlichen Softwareänderung in einer kritischen Anwendung verlangsamt

• Die Ursache ist unbekannt

Aktionen

• Der Level-1-Helpdesk hat festgestellt, dass das Problem über seinen Zuständigkeitsbereich hinausgeht und an das IRT eskaliert

Benötigt

• IRT soll untersuchen

Hinweis

Bei Problemen mit geringer Auswirkung kann es sich um einen Incident Commander handeln, der eine kleine Gruppe von nur zwei oder drei Einsatzkräften leitet, wie in Abbildung 4-1 dargestellt. In dieser Abbildung zeigt das Organigramm eine kleine Gruppe von Ersthelfern (KMUs), die an einer Konferenzschaltung teilnehmen: ein DBA, ein Netzwerktechniker, ein SAN/Speichertechniker und der Incident Commander.

Wie bei jedem Vorfall wird die Rolle des Incident Commanders zunächst von dem ersten qualifizierten IC auf der Brücke übernommen. Bedenke jedoch, dass die Funktion des Kommandos jederzeit an eine beliebige Person übertragen werden kann, solange diese Person für die Rolle des Incident Commanders qualifiziert ist.

Selbst für diesen einfach erscheinenden Einsatz (geringes Ausmaß, nicht komplex) sollte die Position des Einsatzleiters festgelegt werden. Wenn du dich an der Feuerwehr orientierst, könntest du so etwas wie den folgenden Funkspruch regelmäßig hören, selbst bei einem vermeintlichen Routineeinsatz: "Triebwagen 2 am Tatort eines Verkehrsunfalls mit zwei Fahrzeugen. Es sieht so aus, als hätten alle Beteiligten die Fahrzeuge verlassen. Triebwagen 2 übernimmt das Kommando in der Oak Street." Es gibt sicherlich Variationen in der Wortwahl, aber der Punkt ist, dass, auch wenn dieser Vorfall wie eine kleine grün-gelbe Box aussieht, die Feuerwehr es so macht, weil es so ist, und wenn dasselbe Löschfahrzeug bei einem großen Vorfall auftaucht, ist der Prozess der Kommandoübernahme vertraut und automatisch.

Abbildung 4-1. Einfache Befehlsstruktur für ein Problem mit geringem Schweregrad

In Abbildung 4-1 siehst du auch, dass die Kästchen nicht mit dem Namen der Person, die die Stelle besetzt, gekennzeichnet sind, sondern nur die Funktionen der Stelle genannt werden: IC, Database, Network und SAN/Storage. Um noch einmal auf das Beispiel mit der Feuerwehr zurückzukommen: Der Company Officer (Teamleiter) auf dem Löschfahrzeug 2 sagte nicht: "Frank, Pete, Bill und Kathy sind am Einsatzort". Sie wurden durch ihre Funktion identifiziert, die in diesem Fall eine Teamfunktion namens Triebwerk 2 ist. Ein weiteres Beispiel: Die großen Leiterfahrzeuge, die du bei einem Brand siehst, haben eine bestimmte Funktion, genauso wie die Gefahrguteinheit eine Funktion hat und auch ein technisches Rettungsteam. Durch die Festlegung der Befehlsgewalt und die Lenkung der Ressourcen nach Aufgabenbereichen (KMUs) und nicht nach Personennamen kann das Organigramm schnell und eindeutig wachsen, auch wenn sich die Person, die die Funktion ausfüllt, aus irgendeinem Grund ändert. Die Funktion ist die Konstante. Die Person, die sie ausfüllt, kann sich von Tag zu Tag und sogar während eines Vorfalls ändern.

Wenn in dem in Abbildung 4-1 gezeigten Beispiel mehr als ein DBA benötigt wird, kann eine Datenbankgruppe erstellt werden und der Incident Commander muss nur noch mit dem Leiter der Datenbankfunktion (Database Group Leader, DGL) kommunizieren, ohne die Übersicht über die verschiedenen Personen zu behalten, die ihr zugewiesen sind. Wenn deine Organisation klein ist und jeder jeden kennt, mag das lächerlich erscheinen, aber wenn der KMU-Pool groß oder über den ganzen Globus verteilt ist, ist es viel übersichtlicher, wenn du deine KMUs nach Funktion und nicht nach Namen auflistest.

Um mit dem Beispiel in Abbildung 4-1 fortzufahren, nehmen wir an, dass nach ein paar Minuten der Diskussion drei weitere DBAs aus einer anderen Zeitzone der Konferenzschaltung beitreten. Der Incident Commander begrüßt die neuen Teilnehmer, die der Brücke beigetreten sind, und das anschließende Gespräch könnte wie folgt aussehen:

SME: "Hallo, hier ist Allen von der Datenbank."

SME: "Kelly ist auch gerade eingetreten."

Einsatzleiter: "Hallo, Allen. Hier ist Ben. Ich bin der Incident Commander und wir arbeiten an einem SEV 1. Danke, dass du dabei bist. Ich habe auch gehört, dass Kelly dabei ist."

SME Kelly: "Ja, ich bin ein DBA in Sydney, Australien. Ich bin auch mit James hier."

Incident Commander: "Verstanden, tut mir leid, dass ich dich um diese Zeit wecke, aber wir brauchen deine Hilfe. Ich führe gerade ein Gespräch mit dem SAN/Speichertechniker und werde dir in Kürze einen KANN-Bericht geben. Bleib vorerst dran."

SME: "Verstanden. Halte dich bereit."

SME Kelly mit James: "Okay."

In diesem schnellen Austausch hat der Incident Commander die Regeln für den Beitritt der KMUs zur Brücke festgelegt und muss dann entscheiden, wann er die KMUs auf den neuesten Stand bringt und/oder sie einbezieht. Wenn ein wichtiges Gespräch im Gange ist und eine neue Person hinzukommt, kann der Incident Commander damit warten, die SME zu bestätigen, um den Gesprächsfluss nicht zu unterbrechen. Hierfür gibt es keine festen Regeln. Es liegt im Ermessen des Incident Commanders, wie er den Zustrom von Einsatzkräften, die an der Konferenzschaltung teilnehmen, steuert.

Außerdem verwenden einige IRTs eine Statusseite oder eine andere Möglichkeit, Ereignisse elektronisch zu erfassen und die Informationen allen Einsatzkräften zur Verfügung zu stellen. Dies ist ein effizienter Weg, um Status-Updates und aktuelle Informationen über den Einsatz zu liefern. Andernfalls kann der Incident Commander in regelmäßigen Abständen CAN-Berichte erstellen, um alle auf dem Laufenden zu halten.

Spulen wir vor und nehmen wir an, dass unser Beispiel für ein Einsatzszenario schnell an Schwere zunimmt und die Zahl der Einsatzkräfte auf neun angewachsen ist. Um ein Chaos auf der Brücke zu verhindern, muss der Incident Commander die Kontrolle behalten. Nehmen wir an, der Vorfall wird als Datenbankproblem identifiziert und es findet eine intensive Konversation zwischen den DBAs statt. Da jetzt fünf DBAs an dem Gespräch teilnehmen und je nachdem, was auf der Brücke besprochen wird, könnte es für den Incident Commander sinnvoll sein:

1. Erstelle eine Datenbankgruppe.

2. Weise einem der DBAs die Rolle des Database Group Leader (DGL) zu.

3. Weise sie an, eine weitere Störungskonferenzbrücke einzurichten und ihre Gespräche dorthin zu verlegen.

4. Bitte darum, dass nur die DGL dem Incident Commander Bericht erstattet und/oder für die Gruppe antwortet.

Der DGL kann ein friedensmäßiger Datenbankmanager oder sogar der erfahrenste DBA sein, muss es aber nicht. Tatsächlich ist es die Entscheidung des Incident Commanders (mit dem Input der DBA und dem, was für die jeweilige Situation richtig ist), aber die DBAs müssen ihre DGL unterstützen.

Die neu ernannte DGL sollte die folgenden Maßnahmen ergreifen:

1. Verschiebe die Datenbankgruppe von der Hauptkonferenzbrücke für Zwischenfälle zu einer Datenbankgruppenbrücke.

2. Führe die Diskussionen auf der Datenbank-Gruppenbrücke.

3. Weise den DBAs in der Datenbankgruppe Aufgaben zu und moderiere Diskussionen.

4. Melde dich über die Hauptkonferenzbrücke beim Incident Commander zurück.

Abbildung 4-2 zeigt das Organigramm der neu gebildeten Datenbankgruppe. Du kannst sehen, dass der Incident Commander auf die Kontrollspanne achtet, indem er die DBAs in Gruppen zusammenfasst.

Hinweis

Der Incident Commander kann bei der Kommandostruktur kreativ sein, aber die Idee ist, die Aufgaben so zu delegieren oder abzutrennen, dass die Anzahl der Personen, die einer anderen Person unterstellt sind, innerhalb der 5-7 Kontrollspanne bleibt.

Es ist angebracht, dass die DGL den Incident Commander über die Ergebnisse der Arbeit der Datenbankgruppe bzw. über Empfehlungen und Maßnahmen informiert. Bei dieser Diskussion sollte der Einsatzleiter Fragen an die DGL richten. Wichtig ist, dass die DGL die einzige Person ist, die für die Datenbankgruppe spricht. Wenn die Datenbankgruppe nach Abschluss der Aufgaben aufgelöst wird, stehen alle Mitglieder der Datenbankgruppe, einschließlich der DGL, für weitere Aufgaben zur Verfügung.

Dies ist nur eine einfache Veranschaulichung, aber mit dem modularen Charakter des IMS kann ein Einsatzleiter eine Struktur aufbauen, um den Einsatz zu rationalisieren und effektiver zu überwachen/kontrollieren. Durch die Gruppierung von Ressourcen, die Ernennung von Gruppenleitern (GL) und die Zuweisung von Aufgaben nach Funktionen ist die Kommunikation direkt und leichter zu verfolgen. Wenn eine weitere Expertengruppe benötigt wird, kann der Einsatzleiter eine weitere Gruppe mit einem anderen Namen gründen, einen Gruppenleiter ernennen, die Aufgaben mit einem Zeitplan festlegen und einen Bericht von der GL auf der Brücke der Einsatzkonferenz erwarten.

Abbildung 4-2. Das Organigramm für einen erweiterten Vorfall

Außerdem siehst du, dass die Position des Schreibers (SitStat) zum Organigramm hinzugefügt wurde. Sie wird auch SitStat genannt, weil sie die Funktion ist, die den Situationsstatus zu jeder Zeit während des Vorfalls festhält. Ein Schreiber (unabhängig davon, ob es sich um eine Person handelt, die diese Aufgabe ausführt, oder ob sie auf irgendeine Weise automatisiert ist) ist nützlich, um den Incident Commander bei der Dokumentation zu unterstützen: die Einsatzkräfte, der Zeitplan für den Vorfall, die Aufgaben nach Funktionen mit Zeitvorgaben und die ergriffenen Maßnahmen. Nicht alle Organisationen verfügen über den Luxus eines großen IRT oder eines großen Pools von KMUs, daher ist diese Position für dein IRT vielleicht nicht realistisch. Wenn dies nicht der Fall ist, sollte das Aufschreiben trotzdem erfolgen, aber es wird vom Incident Commander erledigt. Du kannst die Reaktion elektronisch dokumentieren, was sicherlich nützlich ist, aber bedenke, dass die Position des Schreibers eine großartige Möglichkeit für jüngere Mitglieder des IRT ist, Erfahrungen zu sammeln und ein erfahreneres Mitglied bei der Bewältigung eines Vorfalls zu beobachten. Außerdem wird das Aufschreiben vielleicht als banale Aufgabe angesehen, obwohl es in Wirklichkeit sehr wichtig ist, um einen genauen Zeitplan für den Vorfall zu erstellen und die Grundlage für einen After Action Review (AAR) zu bilden.

Hinweis

Die Position des Schreibers (SitStat) wird hier als eine zu besetzende Funktion dargestellt und zählt nicht zur Kontrollspanne des Incident Commanders. Er hat eine unterstützende Funktion und ist nicht aktiv an der Problemlösung beteiligt.

Abbildung 4-3 zeigt einen möglichen Weg, wie das Beispiel in Abbildung 4-2 mit noch mehr Einsatzkräften eskalieren könnte, ohne dass der Kontrollbereich eingeschränkt wird.

An dieser Stelle ist es sinnvoll, den Begriff "eskalieren" zu definieren. In der IT hat der Begriff "eskalieren" zwei verschiedene, aber miteinander verbundene Bedeutungen: 1) ein Problem zur Entscheidung an einen höherrangigen Manager weiterleiten; 2) wenn eine Person, die als primäre Ressource für den Bereitschaftsdienst identifiziert wurde, nicht innerhalb eines bestimmten Zeitrahmens reagiert, die sekundäre oder tertiäre Ressource anrufen. Hier ist ein typischer Dialog für die erste Definition: "Das ist eine Netzwerkentscheidung, zu der ich nicht befugt bin, also werde ich meinen Netzwerkmanager bitten, den Anruf zu tätigen. Hier ist ein typischer Dialog für die zweite Definition: "Der primäre Bereitschaftsdienst des Netzwerks wurde vor 15 Minuten angepiepst und hat sich noch nicht in die Konferenzschaltung für den Vorfall eingeklinkt.

Bei der Feuerwehr hat "eskalieren" eine ganz andere Bedeutung: mehr oder andere Ressourcen anzufordern, wenn sich die Bedingungen bei einem Einsatz ändern. Hier ist ein typischer Feuerwehrdialog mit dem Einsatzleiter: "Das Feuer hat sich auf den zweiten Stock ausgebreitet, schicke einen zweiten Alarm und zwei weitere Krankenwagen."

Wir empfehlen, die Feuerwehr-Definition von Eskalation in der IT zu verwenden. Wie wir bereits beschrieben haben, ist die MTTA der einzige Teil der Reaktion auf einen Vorfall, den das IRT wirklich kontrollieren kann. Bei der zweiten Definition von Eskalation in der IT reagiert der primäre Bereitschaftsdienst nicht, was das IRT daran hindert, den Vorfall zu lösen, und wertvolle Zeit vergeudet. Wie wir bereits besprochen haben, ist ein Bereitschaftsdienst einsatzbereit, nimmt mit einem Gefühl der Dringlichkeit an einer Konferenzschaltung teil und ist in der Lage, die Aufgaben des Incident Commanders zu erfüllen.

Ein Kunde hat uns gefragt: "Wie geht die Feuerwehr mit einem Löschfahrzeug um, das zu einem Einsatz geschickt wird, aber nicht kommt?" Die Frage hat uns verblüfft, denn diese Situation kommt bei der Feuerwehr nie vor! Natürlich haben Feuerwehrfahrzeuge platte Reifen oder haben eine Panne und können nicht ausrücken, aber wenn sie für einen Einsatz verfügbar sind, sind sie einsatzbereit, reagieren mit einem Gefühl der Dringlichkeit und sind in der Lage, die Anweisungen des Einsatzleiters zu erfüllen. Das Problem des nicht ansprechbaren primären Bereitschaftsdienstes sollte mit seinem Vorgesetzten außerhalb der Konferenzschaltung besprochen werden, um zu verhindern, dass dies noch einmal passiert.

Zurück zu unserem Beispiel: Der Vorfall weitete sich schnell aus und der Incident Commander beschloss, die SEV-Stufe zu erhöhen und die verschiedenen Ressourcen anzufordern: "Ich erhöhe die Stufe auf SEV 1. Aktivieren wir das Disaster Recovery Team (DR).

Abbildung 4-3. Das Organigramm des Vorfalls zeigt eine größere Ausdehnung des Vorfalls

Wenn das DR-Team auf der Brücke eintrifft, würde sich das Organigramm entsprechend ändern. Auch hier kommen mehr Einsatzkräfte hinzu, aber die Kontrollspanne des Incident Commanders bleibt in einem akzeptablen Rahmen. Abbildung 4-4 stellt eine weitere Erweiterung des IMS-Rahmens dar. Mach dir in diesem Szenario keine Gedanken darüber, wie du die einzelnen Funktionen und ihre spezifischen Aufgaben verstehen kannst. Konzentriere dich vielmehr auf das Organigramm und darauf, wie eine große Anzahl von Einsatzkräften bei einer Ausweitung des Vorfalls durch die Zuweisung von Gruppen untergebracht werden kann. Funktionen wie Planer, Verbindungsoffizier und Schreiber werden als Kommandostabfunktionen bezeichnet (die dem Incident Commander direkt zuarbeiten) und werden nicht auf die Kontrollspanne angerechnet. Auch hier kann der Incident Commander das Organigramm so gestalten, dass er die Kontrolle über den Ressourcenpool behält und eine effektive Kontrollspanne aufrechterhalten kann.

Abbildung 4-4. IMS-Organigramm für einen eskalierenden Vorfall. Diese Stufe der Reaktion kann bei Red-Box-Vorfällen angezeigt sein.

Übertragung des Kommandos

Wenn sich ein Vorfall über einen längeren Zeitraum hinzieht, kann das Kommando (wie auch alle anderen Funktionen) an ein anderes qualifiziertes Mitglied des IRT übertragen werden. Die Übergabe sollte ein geordneter Prozess sein und auf der Konferenzbrücke angekündigt werden. Wann wird das gemacht? Die Übergabe der Einsatzleitung oder einer anderen Funktion kann jederzeit während eines Einsatzes erfolgen, aber am häufigsten geschieht dies, wenn:

• Es gibt eine natürliche Unterbrechung in einer Arbeitsperiode, wie z.B. Schichtwechsel oder globale Übergaben zwischen Teams.

• Ein Incident Commander ist übermüdet und es ist im besten Interesse des Vorfalls, eine ausgeruhte Person in diese Position zu bringen.

• Es kann sein, dass ein Incident Commander Probleme hat und eine qualifiziertere Person verfügbar ist.

• Aus geschäftlichen Gründen sollte eine ranghöhere Person in Friedenszeiten die Reaktion auf einen Vorfall leiten.

Wie bereits erwähnt, sollte der scheidende Incident Commander der Gruppe ankündigen, dass das Kommando übergeben wird und den neuen Incident Commander der Gruppe vorstellen. Zuvor sollte der scheidende Incident Commander dem neuen Incident Commander außerhalb der Konferenzschaltung einen CAN-Bericht zukommen lassen, um ihn über die aktuellen Bedingungen und Aktivitäten auf der Brücke auf dem Laufenden zu halten. Der Grund dafür, dass dies außerhalb der Konferenzschaltung geschieht, ist, dass die beiden Einsatzleiter ein offenes Gespräch über den Einsatz führen können. Wenn es ein KMU-Problem gibt, das der abwesende Incident Commander nicht in den Griff bekommen hat, können sie eine Strategie für den Umgang mit dieser Situation besprechen. Der scheidende Incident Commander wollte vielleicht eine andere Richtung einschlagen, aber das Team hat sich geweigert. Der neue Incident Commander kann dann den neuen Plan vorstellen und ihn vorantreiben. Wenn eine neue Richtung erforderlich ist, kann ein Wechsel des Einsatzleiters diese Neuausrichtung erleichtern.

Zusammenfassung

In der Welt der öffentlichen Sicherheit sind einige Vorfälle groß und komplex und erfordern eine Menge Leute, um koordiniert und gemanagt zu werden - wie der Vorfall im World Trade Center am 11. September 2001. Manche Vorfälle sind relativ klein und können in den meisten Fällen von einem kleinen Team von Einsatzkräften bewältigt werden, wie zum Beispiel ein kleiner Hausbrand. Ein medizinischer Routineeinsatz erfordert einen kleineren Einsatz und wird in der Regel von einem kleineren Team aus Sanitätern und Feuerwehrleuten bewältigt.

In der IT kann das IRT aufgefordert werden, große, komplexe Vorfälle zu lösen und wiederherzustellen, wie z.B. einen ausgedehnten, anhaltenden DDoS-Angriff. Große SEV-Vorfälle können die kollektiven Problemlösungsfähigkeiten von Netzwerktechnikern, DBAs, wichtigen Führungskräften in Friedenszeiten, externen Anbietern und vielleicht sogar einem Disaster Recovery Team erfordern, was dazu führen kann, dass Dutzende von Personen bei einer Konferenzschaltung zu einem Vorfall ein- und aussteigen. Umgekehrt kann eine Handvoll Techniker/innen an einem Problem mit einem einzelnen Kunden arbeiten, der ein Problem mit einer Anwendung hat.

• Der beste Weg, um Fähigkeiten und Fertigkeiten im Incident Management aufzubauen, ist die regelmäßige Nutzung von IMS für Green- und Yellow-Box-Probleme und nicht nur für große, komplexe Red- und Black-Box-Vorfälle.

• Jeder Incident Commander sollte sich bemühen, die richtige Mischung aus Befehl, Rahmen und Problemlösungsbemühungen zu finden, um die effektivste Umgebung für die Behebung eines Zwischenfalls zu schaffen, die auf die Größe und den Umfang des Zwischenfalls abgestimmt ist.

• Der Kontrollbereich ist die maximale Anzahl von Personen, die eine Person verwalten kann. Normalerweise sind es 5-7 Personen.

• Die Funktion des Kommandos (oder jede andere Funktion in einer Antwort) kann jederzeit aus beliebigen Gründen an eine beliebige Person übertragen werden, solange diese Person qualifiziert ist, die Funktion zu übernehmen.

• Die Aufträge während eines Einsatzes sind konstant. Die Personen, die die Funktion ausfüllen, können variieren.