Diensteigentum ist eine bewährte DevOps-Methode, bei der Teammitglieder die Verantwortung für die Unterstützung der von ihnen gelieferten Software in jeder Phase des Entwicklungslebenszyklus übernehmen. Dieses Maß an Verantwortung bringt Entwicklungsteams viel näher an ihre Kunden, das Geschäft und den gelieferten Wert.

Service Owner sind die Fachexperten (SMEs) für ihre Services – und in einem Service Ownership-Modell sind sie auch für die Reaktion auf Produktionsprobleme verantwortlich. Für Teams, die zu diesem Modell wechseln, kann die Bereitschaft zur Rufbereitschaft entmutigend wirken. Vielleicht haben Sie Horrorgeschichten über Wochenenden und Abende gehört, an denen Sie mit Ihrem Laptop auf Vorfälle reagieren mussten?

Man kann es nicht beschönigen: Bereitschaftsdienst ist hart. Aber Best Practices wie Service Ownership können mehr Struktur und Vorhersehbarkeit in Bereitschaftsschichten bringen, sodass im Idealfall die Lebensqualität aller steigt.

Warum ist Serviceeigentum wichtig?

Stellen Sie sich folgendes Szenario vor: Sie werden zu einem Meeting einberufen, weil etwas ist falsch irgendwo im System, aber da Sie keine Serviceinhaber bestimmt haben, weiß niemand, wer der SME ist. Aus 15 Minuten werden 20, dann 30 und so weiter. In der Zwischenzeit melden sich immer mehr Leute zu Wort, aber es kommen keine Fortschritte zustande.

Diese Art der chaotischen Reaktion auf Vorfälle verschwendet wertvolle Zeit – sie ist der Inbegriff von Ineffizienz. Und das Schlimmste ist, dass sie immer noch ständig vorkommt.

Das muss nicht so sein. Aber sehen wir uns zunächst an, warum so viele Teams durch manuelle, sich ewig hinziehende Incident Response belastet sind. Wenn man sich die Gründe für die Verlangsamung ansieht, läuft es darauf hinaus, dass die Teams nicht in der Lage sind, einige sehr wichtige Fragen zu beantworten:

• Welche Dienste sind betroffen?
• Wem gehören diese Dienste?
• Welche Abhängigkeiten bestehen zwischen diesen Diensten und wer besitzt diese Dienstleistungen?

Meetings wie das obige Beispiel versuchen, diese Fragen zu beantworten, allerdings auf reaktive Weise. Solange die Teams diese Fragen nicht beantworten können, sind sie in einer Sackgasse und können bei der Lösung des Vorfalls keine Fortschritte erzielen.

Dies kommt immer häufiger vor, da sich das Technologie-Ökosystem in Unternehmen jeder Größe ständig ändert und immer komplexer wird. Hunderte von Diensten, Mikrodiensten und verteilte Eigentümerschaft machen es schwierig zu wissen, wie man reagieren soll, wenn etwas schief geht.

Service Ownership kann Unternehmen dabei helfen, proaktiver auf Vorfälle zu reagieren. Das ist allerdings kein Zuckerschlecken. Kulturelle Veränderungen sind schwierig und selbst die erfolgreichsten Unternehmen, die den Wechsel zu DevOps und Service Ownership geschafft haben, würden zustimmen, dass die Einhaltung von Best Practices und ein Prozess zur Einführung von Service Ownership dabei helfen können, die Zusammenarbeit im gesamten Unternehmen zu festigen und die Skalierung voranzutreiben.

Wenn Organisationen in der Lage sind, Service Ownership zu übernehmen, profitiert jeder davon – von den Service Ownern über die leitenden Stakeholder bis hin zu den Kunden. Service Owner werden nur hinzugezogen, wenn es nötig ist. Stakeholder wissen, was von einem Vorfall betroffen ist, und können mit dem technischen Team zusammenarbeiten, um die Auswirkungen zu mildern. Und die Kunden erleben kürzere Serviceunterbrechungen mit klarerer Kommunikation während des gesamten Vorgangs.

In einer Welt, in der die Kundenerwartungen höher sind als je zuvor und das Kundenerlebnis entscheidend ist, kann dies Ihrem Unternehmen einen Vorsprung vor der Konkurrenz verschaffen – und gleichzeitig das Leben der Menschen verbessern, die auf den Vorfall reagieren.

Doch was ist eigentlich eine Dienstleistung?

Einen Service zu definieren kann schwieriger sein, als es auf den ersten Blick scheint. Wir haben gesehen, dass Organisationen Services auf viele Arten aufteilen, und es ist nicht immer so einfach, Services mit dem abzugleichen, was in der Cloud bereitgestellt wird. Bei manchen Organisationen gibt es einen Monolithen, der ebenfalls berücksichtigt werden muss. Wie können Sie also bestimmen, wie Sie Dinge in überschaubare Teile aufteilen, für die ein Team verantwortlich sein kann?

Bei PagerDuty Definieren Sie einen Dienst als „eine eigenständige Funktion, die einen Mehrwert bietet und vollständig im Besitz eines Teams ist“. Man kann es sich auch so vorstellen: Ein Dienst stellt eine Entität dar, die Sie überwachen, und dient als Container für verwandte Vorfälle, der die Vorfälle mit den richtigen Eskalationsrichtlinien verknüpft.

Kurz gesagt, es lässt sich folgendermaßen zusammenfassen: Wenn Sie es überwachen und möchten, dass Vorfälle damit in Verbindung gebracht werden und dass bestimmte Personen dafür auf Abruf bereitstehen, dann ist es ein Service . Dies ist eine breitere Definition, die Teams mehr Flexibilität bei der Definition unkonventioneller Dienste bietet.

Um auf Probleme umfassend vorbereitet zu sein, müssen die Einsatzkräfte jedoch mehr als nur diese Grenzen kennen. Hier kann die Dienstkonfiguration einen großen Unterschied machen.

Was macht einen Dienst gut konfiguriert?

Bei PagerDuty haben wir eine Reihe von Standards etabliert, die unserer Meinung nach für Organisationen wertvoll sind, die ihren Weg zur Service Ownership vorantreiben möchten. Diese dienen als Richtlinien für die Erstellung unserer Services und bestimmen, was „gut“ aussieht.

Sie sind außerdem flexibel. Nicht jeder Dienst ist gleich aufgebaut und einige unserer Standards sind möglicherweise nicht in jeder Situation anwendbar. Betrachten Sie sie als Ausgangspunkt, den unsere Kunden nutzen können, um den Bereitschaftsdienst effizienter und für ihre Ersthelfer weniger schmerzhaft zu gestalten.

Es ist wichtig zu beachten, dass jede Organisation anders hochfährt und dass Service Ownership ein Prozess ist und kein einzelnes Kästchen, das von einer To-do-Liste abgehakt werden muss. Abhängig von Ihrer betrieblichen Reife müssen Sie möglicherweise Standards in einem anderen Tempo festlegen und übernehmen.

Wenn Sie relativ klein und neu in der Serviceverwaltung sind und nur eine Handvoll überwiegend Cloud-basierter Services haben, können Sie möglicherweise innerhalb weniger Tage Standards festlegen und Ihre Services entsprechend konfigurieren. Wenn Sie bei Null anfangen, ist es sogar noch einfacher: Sie können diese Standards anwenden, wenn Sie Ihre allerersten Services erstellen, und so Ihren langfristigen Erfolg sicherstellen, ohne dass Sie zurückgehen und Änderungen an zuvor konfigurierten Services vornehmen müssen.

Für größere Organisationen mit Hunderten oder gar Tausenden von Diensten kann die Umstellung jedoch schwieriger sein. Für diese Organisationen sind hier einige Fragen, die Ihnen dabei helfen können, darüber nachzudenken, wie Sie weiter vorgehen können:

1. Für welche Teilmengen bestehender Dienste könnten Sie heute Standards festlegen und wie lauten diese Standards? Möglicherweise stellen Sie fest, dass sich einige Standards problemlos auf alle Ihre Dienste anwenden lassen. Dienste sollten beispielsweise einen Namen haben, der genau beschreibt, was sie tun. Wenn es Standards wie diese gibt, von denen Sie wissen, dass die Mehrheit der Dienste sie befolgen sollte, ist dies ein guter Ausgangspunkt für die Implementierung. Überlegen Sie, wie Sie Pilotteams bitten könnten, diese Änderungen vorzunehmen.
2. Wie sieht der Prozess zur Schaffung völlig neuer Dienste aus? Sie haben vielleicht Ihre Standards festgelegt, aber alle Ihre aktuellen Dienste so zu ändern, dass sie diesen Standards entsprechen, ist ein schwieriges Unterfangen. Wenn Sie eine größere Organisation sind, ist es normalerweise nicht möglich, alle Dienste auf einmal neu zu konfigurieren – und die Neukonfiguration von Diensten kann frustrierender sein, als einem Prozess zu folgen, um sie von Anfang an richtig einzurichten.
3. Was ist Ihr langfristiges Ziel und wie sieht der Zeitplan dafür aus? Für manche Dienste sind diese Standards möglicherweise nicht erforderlich, und das ist in Ordnung. Erstellen Sie einen Plan für die restlichen Dienste mit einer Frist und beginnen Sie dann damit, weitere Teams in den Prozess einzubinden. Nehmen Sie dabei im Laufe der Zeit kleine, schrittweise Änderungen vor.
4. Woher kennen wir unsere Abhängigkeiten? Neben der Erstellung und Anwendung von Standards ist es auch wichtig zu wissen, wie Ihre Dienste zueinander passen und sich gegenseitig beeinflussen. Denken Sie beim Festlegen von Standards darüber nach, wie Sie die Kodierung dieser Informationen während des Konfigurationsprozesses fördern können.

Für sich genommen scheinen die Antworten auf diese Fragen keine großen Unterschiede zu machen. Wenn Sie jedoch über die Größenordnung nachdenken, machen sie einen großen Unterschied für die Art und Weise, wie Sie auf Vorfälle reagieren.

Wie hilft dies bei der Reaktion auf Vorfälle?

Bei der Reaktion auf einen Vorfall ist es wichtig, dass Sie weder Zeit noch Energie mit unwichtiger Arbeit verschwenden. Alles muss auf das reduziert werden, worauf sich das Team konzentrieren muss, um den Vorfall zu lösen.

Die Serviceverantwortung hilft Ihnen dabei, im gesamten Reaktionsprozess Klarheit zu gewinnen:

Wenn Sie Ihren Dienst beispielsweise gut konfiguriert haben, werden Sie mit der richtigen Dringlichkeit und minimalem Alarmrauschen gewarnt, sodass Sie nur auf die wichtigsten Signale reagieren und entsprechend Prioritäten setzen können. Sie können auch schnell die richtigen Leute vor Ort schicken, da Sie wissen, wer die Dienstinhaber sind. Mit zunehmender Reife können Sie auch Automatisierungssequenzen für Ihre Dienste erstellen, die Ihnen helfen, den Arbeitsaufwand zu reduzieren, der erforderlich ist, um den Dienst wieder in den Normalzustand zu versetzen.

Auch die Diagnose von Fehlern ist einfacher, da Sie sehen, was sich am Dienst geändert hat. Und mit Dienstzuordnung, Sie können die Gesamtauswirkung auf das System verstehen.

Während der Lösung können Sie schneller mit den Integrationen arbeiten, die Ihr Service benötigt, und die Stakeholder auf dem Laufenden halten. Sie können die Kommunikation auf diejenigen Personen beschränken, von denen Sie wissen, dass sie von Ihrem Vorfall betroffen sind, und so die Auswirkungen auch innerhalb der Organisation auf ein Minimum beschränken.

Und schließlich lernen Sie besser aus Vorfällen. Als KMU für Ihren Service erhalten Sie einen historischen Kontext und können diese Erkenntnisse in Ihren Reaktionsprozess einfließen lassen, wodurch Sie mit der Zeit widerstandsfähiger werden.

Wenn Sie die Service Ownership im gesamten Unternehmen skalieren, machen diese Verbesserungen sowohl für Kunden als auch für Teamkollegen einen drastischen Unterschied. Wenn Sie Service Ownership einführen oder Ihre betriebliche Reife verbessern möchten und einen Partner suchen, der Sie durch den Prozess führt, PagerDuty 14 Tage kostenlos testen Wenn Sie mehr über die Standardisierung des Service-Eigentums im großen Maßstab erfahren möchten, lesen Sie dieses Webinar .