Vorfälle passieren. Dinge laufen schief. Systeme versagen. Manchmal versagen sie auf unerwartete und dramatische Weise, was zu größeren Vorfällen führt. PagerDuty unterscheidet sehr genau zwischen einem Vorfall und ein Vorfall . Ihre Organisation kann ebenfalls eine solche Unterscheidung vornehmen.

Die Entscheidung, ob es sich um einen schwerwiegenden Vorfall handelt oder nicht, kann von einer Reihe von Faktoren oder einer bestimmten Kombination von Faktoren abhängen, beispielsweise von der Anzahl der betroffenen Dienste, den Auswirkungen auf die Kunden und der Dauer des Vorfalls.

Diese Faktoren erfordern, dass Ihr Unternehmen zumindest über grundlegende Telemetriedaten verfügt und die Beziehungen zwischen den Diensten, aus denen Ihr technisches Ökosystem besteht, im Griff hat. Ohne diese Grundlage ist es schwierig, die tatsächlichen Auswirkungen zu erkennen und zu wissen, wo man bei der Triage eines Vorfalls ansetzen soll.

Was passiert, wenn einer Organisation wichtige Daten fehlen? Ohne die folgenden Daten wird eine Organisation Schwierigkeiten haben, auf Vorfälle zu reagieren:

• Welche Dienste sind betroffen?
• Wie stark sind sie betroffen?
• Wem gehören diese Dienste?

In Ermangelung dieser Daten entscheiden sich einige Organisationen für die Verwendung eines Schwarm Ansatz für ihre Reaktion auf Vorfälle.

Schwärmen vs. intelligentes Schwärmen

Swarming ist ein Ansatz zur Reaktion auf Vorfälle, bei dem jeder in der Organisation über ein Problem informiert wird und ein großer War Room oder eine Telefonkonferenz für alle geöffnet wird, unabhängig von ihrem Potenzial, zur Lösung des Problems beizutragen. Um die Auswirkungen eines Vorfalls zu verringern, ist es entscheidend, dass die richtigen Leute zur richtigen Zeit mobilisiert werden. Swarming ist das Gegenteil davon, die richtigen Leute zur richtigen Zeit am richtigen Ort zu haben – es sind einfach alle, für die gesamte Zeit.

Der Begriff intelligent Schwärmen wird verwendet, um sich auf einen Workflow zur Bearbeitung von Kundendienstproblemen zu beziehen, insbesondere für VIPs, über den wir gesprochen haben früher in diesem Monat . Es handelt sich um einen etwas anderen Ansatz, der vorgibt, dass das Teammitglied, das den Fall zuerst aufgegriffen hat, ihn bis zur Lösung durchziehen sollte und die Möglichkeit hat, Ressourcen aus der gesamten Organisation heranzuziehen, um das Problem zu lösen. Obwohl es mit einem allgemeinen Reaktionsschwarm verwandt ist, liegt der Fokus eines intelligenten Schwarms normalerweise auf einem einzelnen Kunden und dessen Erfahrung im Mittelpunkt.

Das Schwarmsystem für die Reaktion auf einen allgemeinen technischen Vorfall ähnelt eher dem Hören eines Feueralarms in einem Gebäude: Jeder ist in höchster Alarmbereitschaft und wird aufgefordert, zu reagieren. Im Wesentlichen wird eine Warnung an jeden gesendet, der irgendetwas wissen könnte, und er wird gebeten, sich dem Vorfall anzuschließen. Dann beginnt der mühsame Prozess, herauszufinden, wer die Triage und Abhilfe durchführen kann.

Organisationen geraten oft in einen Schwarm, weil sie nicht genügend Informationen über ihre Dienste und ihr Ökosystem haben oder weil sie keine starken Kommunikationspraktiken haben, um die Stakeholder auf dem Laufenden zu halten. Wenn etwas passiert, weiß niemand genau, was das Problem sein könnte, wo es auftreten könnte oder wer weiß, wie es zu beheben ist. Daher wird jeder mobilisiert, für den Fall, dass er wichtiges Wissen beitragen könnte. Das macht das Schwarming unglaublich teuer. Die Arbeit wird unterbrochen, Aufgaben und Besprechungen geraten ins Stocken und Ressourcen bleiben an einem Ort stecken, an dem sie nicht effektiv sind. Hunderte von Menschen könnten mobilisiert werden, um auf einen Vorfall zu reagieren, den nur eine Handvoll tatsächlich bewältigen kann, anstatt ungestört weiterzuarbeiten und entsprechende Updates zu erhalten.

Swarming ist auch schwierig. Große Anrufe mit vielen Einsatzkräften können laut und verwirrend sein. Swarming verlangsamt den Wiederherstellungsprozess bei Vorfällen, da es keine klare Koordination oder Verantwortungsverteilung gibt. Informationen kommen aus allen möglichen Richtungen, ohne zentrale Organisation oder Entscheidungsbefugnis. Teams versuchen möglicherweise, ihre eigenen Dienste zu sanieren, ohne die Auswirkungen auf andere Dienste vollständig zu verstehen. Swarming ist einer der Gründe, warum wir eine explizite Einsatzleitungspraxis – um Verwirrung zu vermeiden und eine möglichst schnelle Lösung des Vorfalls zu ermöglichen, ohne die Situation zu verschlimmern.

Swarming kann sich angenehm anfühlen, da das Team davon ausgeht, dass es bei einem Vorfallseinsatz ab der ersten Warnung immer alle benötigten Personen zur Verfügung hat, anstatt Leute hinzuzuziehen, wenn festgestellt wird, dass ihre Systeme betroffen oder involviert sind. Eine Verbesserung Ihres Bereitschaftsverhaltens mindert die Befürchtungen, dass Leute nicht zur Behebung des Problems verfügbar sein werden. Ein expliziter Bereitschaftsdienst mit vereinbarten Zuständigkeiten ist für die Einsatzkräfte weniger stressig, als sich Sorgen zu machen, dass jederzeit ein Rundruf kommen könnte. Wenn die Einsatzkräfte wissen, dass sie an bestimmten Tagen und zu bestimmten Zeiten Bereitschaftsdienst haben, können sie vorausplanen. In einem Swarming-Szenario besteht immer noch die Möglichkeit, dass die benötigte Person nicht verfügbar ist – sie kann nicht rund um die Uhr an 365 Tagen im Jahr auf Abruf bereitstehen.

Weitermachen nach dem Schwarm

Um Ihren Prozess durch Swarming zu verbessern, müssen Sie die Denkweise Ihres Teams über Dienste und die Teams, die sie besitzen, ändern. Bei PagerDuty bezeichnen wir diese Praxis als „Full Service Ownership“ und Sie können mehr darüber in unserem Ops-Handbuch . Im Rahmen einer koordinierten Reaktion auf Vorfälle bedeutet die Verantwortung für einen Dienst Folgendes:

1. Ein einzelnes Team trägt die volle Verantwortung für den Dienst, einschließlich seiner Leistung in der Produktionsumgebung.
2. Dieses Team verfügt über ein dokumentiertes Verfahren, um über ein Problem mit diesem Service benachrichtigt zu werden. Im Allgemeinen ist dies Ihr Bereitschaftsplan.
3. Die vom Dienst genutzten Abhängigkeiten werden dokumentiert.

Ihre Organisation verfügt möglicherweise über Dienste, die derzeit keinen eindeutigen Eigentümer haben. Es kann sich um ausgereifte oder veraltete Projekte handeln, die keiner aktiven Entwicklung oder Aufmerksamkeit mehr bedürfen. Es kann sich um kommerzielle Standardprodukte (COTS) handeln, die in Zusammenarbeit mit dem Anbieter gewartet werden, oder um SaaS-Lösungen oder sogar um interne Dienste, die durch organisatorische Änderungen verwaist sind. Wenn sich Dienste in Ihrem Produktionsökosystem befinden, sollten Teams damit beauftragt werden, ein Auge darauf zu haben, selbst wenn dies nur erfordert, den E-Mail-Alias des Teams für die Updates des Anbieters zu abonnieren, um loszulegen. Für jeden Dienst, der in Ihrer Umgebung ausgeführt wird, sollte ein Team vorhanden sein, das ausdrücklich verantwortlich ist – diese Dienste können immer noch in Vorfälle verwickelt sein oder Arbeiten wie Sicherheitsupdates benötigen. Einige Organisationen haben Legacy-Engineering-Teams oder Plattform-Engineering-Teams, die für diese Dienste verantwortlich sind.

Die Zuweisung von Diensten an ein einzelnes Team reduziert die Verwirrung darüber, wer in der Umgebung für was verantwortlich ist. Teams können neue Mitglieder in den Diensten schulen, die ihnen gehören, und sie zu den Dienst-SLOs führen, die am wirkungsvollsten sind. Die Erstellung eines Dienstverzeichnisses mit einer ergänzenden Team-Eigentümerstruktur, in der aufgelistet ist, wer benachrichtigt werden muss, bietet jedem in der Organisation eine Ressource, die er konsultieren kann, wenn er ein Problem sieht. Dies erreichen wir in PagerDuty mit Teams Und Eskalationsrichtlinien angehängt an Dienstleistungen .

Die Eskalationsrichtlinie legt fest, wer voraussichtlich verfügbar sein muss, um auf Vorfälle bei einem Dienst zu reagieren. Der Antwortende sollte in diesem Fall jemand sein, der sich mit dem betroffenen Dienst auskennt und über den entsprechenden Zugriff verfügt, um das Problem zu bewerten und zu beheben.

Ein klares Abhängigkeitsmodell stellt die Beziehungen zwischen den Diensten her, sodass Einsatzkräfte, Support und Stakeholder ein klares Bild davon haben, wie sich ein Vorfall bei einem Dienst auf andere Dienste in der Umgebung auswirken kann. PagerDuty geht noch einen Schritt weiter und bietet Geschäftsdienstleistungen , das technische Dienste nicht nur miteinander, sondern auch mit der kundenorientierten Funktionalität verknüpft, zu der sie beitragen. Alle technischen und geschäftlichen Dienste erscheinen auf der Servicediagramm , zusammen mit einem praktischen Link zum Teammitglied, das derzeit für diesen Dienst Bereitschaftsdienst hat.

Der Aufbau dieser Infrastrukturdaten, insbesondere des Abhängigkeitsmodells, kann sehr aufwändig sein, wenn sie für einen Dienst nicht auf dem neuesten Stand gehalten werden. Die vollständigen Auswirkungen eines Vorfalls auf einen Backend-Dienst zu kennen, ist jedoch unmöglich, wenn das Team nicht weiß, welche anderen Dienste den Dienst mit dem Problem nutzen.

Auch Kundensupportteams profitieren von dieser Arbeit. Intelligentes Swarming hängt davon ab, dass Ihr Supportteam alle diese Informationen zur Hand hat. Wenn Ihre Kunden eine Lösung benötigen, muss Ihr Team in der Lage sein, alle richtigen Informationen zu finden und die richtigen Leute zu mobilisieren.

Verbesserung der Vorfallkommunikation

Die Reaktion auf Vorfälle ist kein Zuschauersport – die Lösung eines Vorfalls ist oft nicht besonders aufregend. Es kann lange Wartezeiten geben, bis Prüfungen und Prozesse ausgeführt werden, Fehlermeldungen aufgespürt werden oder Neustarts erforderlich sind. Während diese Arbeit weitergeht, ändert sich nicht viel. Während diese Aufgaben jedoch ausgeführt werden, möchten Leute, die nicht direkt an der Behebung beteiligt sind, trotzdem wissen, was los ist. Das Fehlen eines starken Kommunikationsplans für Vorfälle ist ein weiterer Grund, warum Teams auf Swarming zurückgreifen. Wenn jemand wissen möchte, was los ist, besteht die einzige Möglichkeit, es herauszufinden, darin, sich an der Telefonkonferenz zu beteiligen und zuzuhören, unabhängig davon, wie lange die Lösung dauert.

Ein starker, im Voraus festgelegter Kommunikationsplan für größere Vorfälle hat zwei Funktionen: Er hilft internen Benutzern, über die aktuellen Geschehnisse auf dem Laufenden zu bleiben, und hält externe Benutzer auf dem Laufenden. In unserer Leitfaden zur Reaktion auf Vorfälle Wir legen zwei Rollen für die Kommunikation während eines Vorfalls fest: die Kundenkontakt und das interne Verbindung . Es ist zu erwarten, dass Sie für diese beiden Gruppen unterschiedliche Updates haben. Abhängig von Ihrer Organisation müssen Ihre öffentlichen Mitteilungen zu einem Vorfall möglicherweise überprüft werden oder eine bestimmte Sprache verwenden. Das Erstellen von Vorlagen und die Zuweisung bestimmter Teammitglieder zur Rolle des Kommunikationsbeauftragten erleichtert dies. Ihre interne Kommunikation wird wahrscheinlich mehr Details enthalten, sodass andere Teams feststellen können, ob ihre Dienste betroffen sein könnten.

Die besten Pläne basieren darauf, alle Beteiligten regelmäßig auf dem Laufenden zu halten. Durch frühzeitige und häufige Kommunikation weiß jeder, dass an der Situation gearbeitet wird, und wird informiert, wenn die Dinge behoben sind.

Sie müssen nicht mit einem NOC schwärmen

Es ist möglich, zu einem modernen Incident-Response-Modell überzugehen, wenn Ihre erste Anlaufstelle ein allgemeines NOC-Team ist. Explizite Serviceverantwortung bedeutet, dass das NOC komplexe Probleme an Serviceteams weiterleiten kann, wenn sie einen Vorfall nicht lösen können. Es gibt dem NOC einen direkten Draht, wen es anrufen kann, wenn ein Problem zusätzliche Unterstützung von den Fachexperten erfordert – den Bereitschaftsmitarbeiter des Teams, das für Service A zuständig ist, anzurufen, ist viel einfacher, als eine Vielzahl von Leuten aus der gesamten Organisation zusammenzurufen.

Zusammenfassung

Durch die Modernisierung Ihrer Reaktionsmethoden spart Ihr Unternehmen Zeit und Ressourcen. Die Kunden von PagerDuty mögen SAFT profitieren von der Mobilisierung nur der wirklich benötigten Helfer und zwar dann, wenn diese gebraucht werden, und können sich so auf die Bereitstellung der wirksamsten Reaktion konzentrieren.

Wenn Ihr Team nach einer Möglichkeit sucht, die Zeit bis zur Lösung eines Problems zu verkürzen und die Notwendigkeit dieser riesigen Schwarmanrufe zu reduzieren, schauen Sie sich unsere Ressourcen in unserem Leitfaden für Incident Response Ops . Nicht sicher, was alles erforderlich sein könnte Volle Service-Eigentümerschaft ? Schauen Sie sich unsere Video und besuchen Sie unsere Community-Foren um mit Gleichgesinnten zu chatten.