Wie ist der Incident-Response-Prozess in Ihrem Unternehmen eingerichtet?

Bei PagerDuty, unsere Ansatz ist die ganzheitliche Betrachtung Ihrer Infrastruktur, Ihrer kundenorientierten Anwendungen und Ihrer Produkte. Wir unterscheiden diese Elemente, indem wir sie als „Dienste“ bezeichnen, die zu einem „Geschäftsdienst“ zusammengefasst werden. Dieses Setup ermöglicht Teams eine bessere Verwaltung dieser Dienste, sodass sich die Einsatzkräfte bei Vorfällen schneller einen Überblick verschaffen können. 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 Verantwortung von Team zu Dienst erfolgt nicht nur einmal im Jahr oder nur bei Umstrukturierungen. Mitarbeiter übernehmen neue Dienste, erben alte und wechseln die Verantwortung – selbst wenn es nur für ein paar Wochen während eines bestimmten Projekts ist.

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?

Aus diesem Grund hat PagerDuty unsere Plattform entwickelt, um es Unternehmen zu erleichtern, ihre Vorfallmanagementprozesse an den Diensten auszurichten. Dies ermöglicht es den Teams, im Laufe der Zeit zu wachsen und sich zu verändern, und bietet eine bessere Transparenz hinsichtlich des Zustands und der Trends der Dienste. Und das alles ohne Auswirkungen auf die Bereitstellung, Wartung und Verbesserung dieser Dienste. Dies trägt letztlich dazu bei, längere Ausfallzeiten und negative Auswirkungen auf die Kunden zu reduzieren.

Erhalten Sie im Zeitverlauf bessere Einblicke in geschäftliche Auswirkungen, Service-Zustand und Trends

Wie die meisten Unternehmen richten Sie wahrscheinlich die Einrichtung Ihres Incident-Prozesses, die Produktionsunterstützung und die Konfiguration auf Teams aus. Sie verfolgen also einen teambasierten Ansatz. Das bedeutet, dass Sie wahrscheinlich eine Mischung aus ITSM-, DevOps- und ITOps-Teams haben, wobei die geschäftlichen/technischen Teams definieren Unternehmensdienstleistungen und viele andere Teams, die unterschiedliche Dienste besitzen.

Wie gelingt der Wechsel von einem teambasierten zu einem servicebasierten Setup? Das ist einfacher, als die meisten denken.

Identifizieren Sie zunächst Ihre wichtigsten Geschäftsdienste, die eigenständige Bestandteile der Produkte oder Anwendungen sind, mit denen Ihre Kunden interagieren, um bestimmte Aufgaben auszuführen oder Ergebnisse zu erzielen. Beispielsweise sind „Anmelden“, „Warenkorb“ und „Suchen“ Geschäftsdienste. Identifizieren Sie anschließend für jeden Geschäftsdienst die technischen Dienste, die zu diesem Geschäftsdienst beitragen. Jeder technische Dienst sollte idealerweise jeweils von einem Team entwickelt und verwaltet werden, auch wenn mehrere Teams langfristig an der Pflege beteiligt sind.

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

Wenn Ereignisse an separate Dienste weitergeleitet werden, die die Dienste in Ihrer Umgebung widerspiegeln, können alle Beteiligten leichter über die aktuellen Ereignisse kommunizieren. Darüber hinaus erhalten die Einsatzkräfte Einblick in weitere Vorfälle in Ihrer gesamten Infrastruktur.

Nehmen wir zum Beispiel an, Sie sind auf der Site Reliability Engineering-Team und erhalten eine Benachrichtigung über einen ausgefallenen Dienst. Ein anderer Mitarbeiter des Datenbankteams erhielt dieselbe Benachrichtigung. Da Sie nun zugehörige Vorfälle über mehrere Dienste hinweg einsehen können, erkennen Sie, dass es sich um ein Datenbankproblem handelt. Sie können die Arbeit daran beenden, da Sie wissen, dass sich das Datenbankteam darum kümmert.

An das Geschäft und die Geschäftsanforderungen anpassen

Die meisten Unternehmen setzen heute noch auf einen teambasierten Incident-Management-Prozess. Und obwohl dieser zunächst einfacher einzurichten ist, wird er mit zunehmendem Wachstum und Skalierung langfristig zu einer Herausforderung. Warum?

Der Silos Die mit diesem Ansatz erzeugten Verwirrungen bei den Antwortenden. Es ist schwieriger, eine wirksame Reaktion orchestrieren Wenn ein Vorfall eintritt, müssen die Einsatzkräfte zusätzliche Zeit darauf verwenden, herauszufinden, was tatsächlich betroffen ist – „Werde ich wegen Service A oder B angepiept? Welche Reaktionsstufe ist erforderlich?“ – bevor sie entscheiden, was zu tun ist. Bedenken Sie: Die meisten Teams sind für mindestens 10 verschiedene Services zuständig. 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 Unternehmen, die einen Service-First-Ansatz verfolgen, technische und geschäftliche Services. Dies wirkt sich deutlich auf das Unternehmen und die Kunden aus, da es die Bedeutung eines bestimmten Services in Kontext setzt. Es bietet außerdem eine gemeinsame Kommunikationssprache und hilft Unternehmen, präzise und umsetzbare Statusaktualisierungen automatisiert an die Beteiligten weiterzugeben. (Beispiel: Service A unterstützt unser Quote-to-Cash-System und erfordert im Falle eines Vorfalls eine höhere Reaktionszeit als Service B, ein nicht essenzieller, interner Service ohne SLAs.)

Aber ein teambasiertes Setup ist SO viel einfacher

Wie bereits erwähnt, ist die Konfiguration und Einrichtung Ihres Incident-Management-Prozesses mit einem teambasierten Ansatz zunächst einfacher. Auf lange Sicht überwiegen jedoch die Nachteile. 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 typischerweise über mehrere Dienste erstrecken
• Ermitteln Sie schnell, welche Geschäftsinteressenten 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 Ihre Teams und Dienste bei jeder organisatorischen Veränderung 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 einen Bereitschaftsdienst 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 und möchten sicherstellen, dass jeder im Bereitschaftsdienst ist. Und auf diese Weise lässt sich das schnell und einfach einrichten.

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

Verstehen Sie mich nicht falsch – Teams sind sehr wichtig. Wir empfehlen Ihnen jedoch, Ihre Incident-Management-Konfiguration und -Einrichtung zunächst auf Services auszurichten: Dadurch erhalten Sie Folgendes:

• Transparenz ist erforderlich, um den Zustand der Dienste 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, anstatt zuerst mehrere Teams durchlaufen und diese Ebenen verstehen zu müssen, bevor man zum Dienst gelangt

Letztendlich geht es dem Unternehmen vor allem darum, seine Geschäfte abwickeln zu können – und alles, was sich darauf auswirkt, muss schnell angegangen werden. Der beste Weg hierfür ist ein servicebasierter Ansatz, da Sie so erkennen, wer woran arbeiten muss und wie die Aufgaben priorisiert werden müssen. So müssen Sie sich nicht zeitaufwändig durch die verschiedenen Teamebenen wühlen, um zu den Services zu gelangen.