Wie ist der Vorfallreaktionsprozess in Ihrer Organisation eingerichtet?

Bei PagerDuty, unsere Ansatz besteht darin, Ihre Infrastruktur, Ihre kundenorientierten Anwendungen und Ihre Produkte ganzheitlich zu betrachten. Wir unterscheiden diese Elemente, indem wir sie als „Dienste“ beschreiben, die zusammen einen „Geschäftsdienst“ bilden. Mit diesem Setup können Teams diese Dienste besser verwalten, sodass die Einsatzkräfte bei Vorfällen viel schneller einen Kontext erhalten. Aber wie?

Lassen Sie uns zunächst ein wenig darüber sprechen Dienstleistungen . Dienste sind auf Langlebigkeit ausgelegt und überleben in der Regel die Teams, die sie ursprünglich entwickelt haben. Mit anderen Worten: Mitarbeiter kommen und gehen, und Teams organisieren sich ständig neu. Und die Übertragung der Eigentümerschaft von einem Team auf einen anderen Dienst geschieht nicht nur einmal im Jahr oder nur während Umstrukturierungen. Mitarbeiter übernehmen neue Dienste, übernehmen alte und wechseln die Eigentümerschaft sogar nur für ein paar Wochen während eines bestimmten Projekts.

Wenn Sie Ihre Incident-Response-Plattform also zunächst auf die Teams und dann auf die Services ausrichten (oder schlimmer noch, gar keine Services), müssen Sie bei jeder Teamumstrukturierung Ihr gesamtes Incident-Response-Setup neu aufsetzen. Außerdem gehen bei Teamänderungen institutionelles Wissen und wichtige Analysedaten verloren. Klingt wie ein Albtraum, oder?

Deshalb hat PagerDuty unsere Plattform so aufgebaut, dass es für Organisationen einfach ist, ihre Vorfallmanagementprozesse an Diensten auszurichten. Dies ermöglicht es Teams, im Laufe der Zeit zu wachsen und sich zu verändern, und bietet eine bessere Transparenz über den Zustand und die Trends der Dienste. Und das alles ohne Auswirkungen auf die Bereitstellung, Wartung und Verbesserung dieser Dienste. Dadurch werden letztlich längere Ausfallzeiten und negative Auswirkungen auf die Kunden reduziert.

Bessere Transparenz hinsichtlich geschäftlicher Auswirkungen, Serviceintegrität und Trends im Zeitverlauf

Wenn Sie wie die meisten Unternehmen sind, richten Sie Ihre Einrichtung des Vorfallprozesses, die Produktionsunterstützung und die Konfiguration wahrscheinlich an Teams aus; das heißt, Sie verfolgen einen teambasierten Ansatz. Das bedeutet, dass Sie wahrscheinlich eine Mischung aus ITSM-, DevOps- und ITOps-Teams haben, wobei geschäftliche/technische Teams definieren Geschäftsdienstleistungen , und viele andere Teams, die verschiedene Dienste besitzen.

Wie wechselt man also von einer teambasierten zu einer servicebasierten Konfiguration? Das ist einfacher, als die meisten denken.

Identifizieren Sie zunächst Ihre wichtigsten Geschäftsdienste, die eindeutige Teile der Produkte oder Anwendungen sind, mit denen Ihr Kunde interagiert, um bestimmte Aufgaben auszuführen oder Ergebnisse zu erzielen. Beispielsweise sind „Anmelden“, „Warenkorb“ und „Suchen“ alles Geschäftsdienste. Identifizieren Sie dann für jeden Geschäftsdienst technische Dienste, die zu diesem Geschäftsdienst beitragen. Jeder technische Dienst sollte idealerweise jeweils einem Team gehören und von diesem entwickelt werden, auch wenn mehrere Teams an seiner langfristigen Wartung beteiligt sind.

Sobald Sie Ihre Geschäftsdienste und die entsprechenden technischen Dienste, die sie unterstützen, identifiziert haben, können Sie jetzt viele interessante Dinge tun. Beispielsweise können Teams jetzt in Echtzeit sehen, was im gesamten Unternehmen passiert, um besser zu verstehen, ob ein Problem isoliert ist oder umfassendere Auswirkungen hat. Dies ermöglicht eine besser koordinierte Reaktion, wenn das Problem mehrere Teams und Dienste umfasst.

Wenn Ereignisse an unterschiedliche, separate Dienste weitergeleitet werden, die die Dienste in Ihrer Umgebung widerspiegeln, ist es für alle einfacher, über das Geschehen zu kommunizieren. Darüber hinaus erhalten die Einsatzkräfte Einblick in andere Vorfälle, die in Ihrer gesamten Infrastruktur auftreten.

Nehmen wir zum Beispiel an, Sie befinden sich auf der Site-Reliability-Engineering-Team und erhalten eine Benachrichtigung über einen ausgefallenen Dienst. Aber ein anderer Mitarbeiter des Datenbankteams hat die gleiche Benachrichtigung erhalten. Da Sie sich jetzt zugehörige Vorfälle über mehrere Dienste hinweg ansehen können, können Sie erkennen, dass es sich um ein Datenbankproblem handelt. Sie können also die Arbeit an dem Problem beenden, da Sie wissen, dass sich das Datenbankteam darum kümmern wird.

Auf das Geschäft und die Geschäftsanforderungen abstimmen

Die meisten Unternehmen haben heute noch einen teambasierten Ansatz für ihren Vorfallmanagementprozess. Und obwohl dieser zunächst einfacher einzurichten ist, wird er auf lange Sicht mit zunehmendem Wachstum und Skalierung tatsächlich zu einer Herausforderung. Warum?

Der Silos Die mit diesem Ansatz erzielten Ergebnisse verwirren die Antwortenden. Es ist schwieriger, eine wirksame Reaktion orchestrieren wenn ein Vorfall eintritt, weil die Einsatzkräfte zusätzliche Zeit damit verbringen müssen, herauszufinden, was tatsächlich betroffen ist – „Werde ich wegen Service A oder B angepiept? Welche Reaktionsstufe ist erforderlich?“ – bevor sie herausfinden, was zu tun ist. Denken Sie daran: Die meisten Teams besitzen mindestens 10 verschiedene Services. Wenn Sie Ihre Ereignisinformationen so organisieren, dass Warnmeldungen an unterschiedliche Services weitergeleitet werden, können sie besser verstehen, was vor sich geht.

Im Gegensatz dazu verbinden Organisationen, die einen Service-First-Ansatz verfolgen, technische und geschäftliche Services miteinander, was sich deutlich auf das Unternehmen und die Kunden auswirkt, da es Kontext zur Bedeutung eines bestimmten Services bietet. Es bietet auch eine gemeinsame Sprache für die Kommunikation und hilft Organisationen dabei, präzise und umsetzbare Statusaktualisierungen automatisch an diejenigen weiterzugeben, die sie kennen müssen. (Beispiel: Service A unterstützt unser Quote-to-Cash-System und erfordert im Falle eines Vorfalls eine höhere Reaktionszeit als Service B, der ein nicht unbedingt notwendiger, interner Service ohne SLAs ist.)

Aber ein teambasiertes Setup ist SO viel einfacher

Wie ich bereits erwähnt habe, ist die Verwendung eines teambasierten Ansatzes bei der Konfiguration und Einrichtung Ihres Vorfallmanagementprozesses zunächst einfacher. Auf lange Sicht überwiegen jedoch die Nachteile die Vorteile. Mit einem teambasierten Ansatz wären Sie beispielsweise nicht in der Lage:

• Bewerten Sie die Auswirkungen auf das Geschäft von Vorfällen in Echtzeit
• Analysieren Sie die Auswirkungen Ihrer Dienste auf die Zuverlässigkeit oder Stabilität Ihrer Anwendung
• Bewerten Sie den Explosionsradius von Problemen genau, was wichtig ist, da sie sich normalerweise über mehrere Dienste erstrecken
• Bestimmen Sie schnell, welche Geschäftspartner bei schwerwiegenden Vorfällen benachrichtigt werden müssen

Darüber hinaus fehlt einem teambasierten Ansatz die Flexibilität, Änderungen vorzunehmen, wenn sich Teams verändern und neu organisieren. Außerdem müssen Sie bei jeder organisatorischen Veränderung Ihre Teams und Dienste ständig neu strukturieren, was Ihre Innovationsfähigkeit einschränkt.

Welcher Ansatz ist also der richtige für Sie?

Bevor Sie sich entscheiden, ob Sie einen teambasierten oder einen servicebasierten Ansatz für die Einrichtung Ihres Vorfallmanagementprozess , fragen Sie sich zunächst: „Warum richte ich überhaupt die Rufbereitschaft ein?“

Die wahrscheinlichste Antwort: Sie richten es ein, weil Sie ein Team oder jemanden brauchen, der schnell reagiert, wenn ein Vorfall eintritt. Und wir haben viele Unternehmen gesehen, ihre Konfiguration einrichten mit einem Team-First-Ansatz, denn, nun ja, Sie haben ein Team, Sie wollen sicherstellen, dass jeder im Bereitschaftsdienst ist, und auf diese Weise lässt sich das schnell und einfach einrichten.

Wenn Sie jedoch einen Schritt zurückgehen, ist es ein besserer Ansatz, über die Dienste nachzudenken, die Ihre Teams unterstützen, da dies Ihnen mehr Flexibilität im Hinblick auf Änderungen ermöglicht. Die Teams können sich im Laufe der Zeit ändern, aber die Dienste, die sie unterstützen, können dieselben bleiben.

Verstehen Sie mich nicht falsch – Teams sind sehr wichtig. Aber der Grund, warum wir empfehlen, dass Sie Ihre Vorfallmanagement-Konfiguration und -Einrichtung zunächst auf Dienste ausrichten, ist, dass Sie dadurch Folgendes erhalten:

• Transparenz ist erforderlich, um den Zustand von Services zu verstehen und Prozesse zu verbessern
• Einblicke in Trends zur Identifizierung von Hotspots
• Die Möglichkeit, einfach und schnell zu erkennen, welches Team welche Dienste unterstützt, statt erst mehrere Teams durchgehen und diese Schichten verstehen zu müssen, bevor man zum Dienst gelangt

Letztendlich ist es für das Unternehmen das Wichtigste, seine Geschäfte abwickeln zu können – und alles, was sich darauf auswirkt, muss schnell angegangen werden. Und das gelingt am besten mit einem servicebasierten Ansatz, denn so können Sie nachvollziehen, wer woran arbeiten muss und wie Sie es priorisieren, anstatt Zeit damit zu verschwenden, sich durch mehrere Teamebenen zu wühlen, um an die Services zu gelangen.