Diensteigentum ist eine bewährte DevOps-Methode, bei der Teammitglieder die Verantwortung für die Unterstützung der von ihnen bereitgestellten Software in jeder Phase des Entwicklungslebenszyklus übernehmen. Dieses Maß an Eigenverantwortung bringt Entwicklungsteams ihren Kunden, dem Unternehmen und dem bereitgestellten Wert deutlich näher.

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 auf dieses Modell umsteigen, kann die Bereitschaft zur Rufbereitschaft entmutigend sein. Vielleicht haben Sie schon Horrorgeschichten über Wochenenden und Abende gehört, an denen Sie Ihren Laptop in der Hand halten und auf Vorfälle reagieren mussten?

Man kann es nicht beschönigen: Bereitschaftsdienst ist hart. Doch bewährte Verfahren wie Service Ownership können mehr Struktur und Vorhersehbarkeit in den Bereitschaftsdienst bringen, sodass im Idealfall die Lebensqualität aller steigt.

Warum ist Service Ownership wichtig?

Stellen Sie sich folgendes Szenario vor: Sie werden zu einer Besprechung gerufen, weil etwas ist falsch irgendwo im System, aber da Sie keine Service-Eigentümer festgelegt haben, weiß niemand, wer der KMU ist. Aus 15 Minuten werden 20, dann 30 und so weiter. In der Zwischenzeit melden sich immer mehr Leute bei dem Anruf an, aber es kommen keine Fortschritte.

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

Das muss nicht sein. Doch zunächst wollen wir untersuchen, warum so viele Teams durch die manuelle, sich ewig hinziehende Reaktion auf Vorfälle belastet sind. Die Gründe für die Verlangsamung liegen darin, dass die Teams einige wichtige Fragen nicht beantworten können:

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

Meetings wie das obige Beispiel versuchen, diese Fragen zu beantworten, allerdings reaktiv. Solange die Teams diese Fragen nicht beantworten können, bleiben sie stehen 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 verändert und komplexer wird. Hunderte von Diensten, Microservices und verteilte Eigentümerschaft machen es schwierig zu wissen, wie man reagiert, wenn etwas schiefgeht.

Service Ownership kann Unternehmen dabei helfen, proaktiver auf Vorfälle zu reagieren. Dennoch ist das kein Zuckerschlecken. Kulturwandel ist 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 die Nachhaltigkeit fördern und die Skalierung im gesamten Unternehmen vorantreiben können.

Wenn Unternehmen Service Ownership übernehmen, profitieren alle – von Service Ownern über die Führungskräfte bis hin zu den Kunden. Service Owner werden nur bei Bedarf hinzugezogen. Stakeholder wissen, welche Personen von einem Vorfall betroffen sind, und können gemeinsam mit dem technischen Team die Auswirkungen minimieren. Und für die Kunden sind Serviceunterbrechungen kürzer und die Kommunikation ist durchgehend klarer.

In einer Welt, in der die Kundenerwartungen noch nie so hoch waren und das Kundenerlebnis im Mittelpunkt steht, 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?

Die Definition eines Dienstes kann schwieriger sein, als es auf den ersten Blick scheint. Wir haben gesehen, dass Unternehmen Dienste auf vielfältige Weise aufteilen, und es ist nicht immer so einfach, die Dienste den in der Cloud bereitgestellten Diensten zuzuordnen. Manche Unternehmen haben zudem einen Monolithen, der berücksichtigt werden muss. Wie können Sie also die Aufgaben in überschaubare Teile aufteilen, für die ein Team die Verantwortung übernehmen kann?

Bei PagerDuty Definieren Sie einen Dienst als „eine diskrete 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 Sie möchten, dass bestimmte Leute dafür auf Abruf bereitstehen, dann ist es ein Service . Dies ist eine breitere Definition, die mehr Flexibilität bei der Definition unkonventioneller Dienste durch Teams ermöglicht.

Um auf die Problembewältigung optimal vorbereitet zu sein, müssen die Einsatzkräfte jedoch mehr als nur diese Grenzen kennen. Hier kann die Servicekonfiguration 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 Unternehmen 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 zudem 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 Einsatzkräfte weniger belastend zu gestalten.

Es ist wichtig zu beachten, dass jede Organisation die Implementierung unterschiedlich durchführt und dass Service Ownership ein Prozess ist, kein einzelnes Häkchen auf einer To-do-Liste. Je nach betrieblicher Reife müssen Sie Standards möglicherweise in unterschiedlichem Tempo festlegen und übernehmen.

Wenn Sie relativ klein und neu in der Serviceverwaltung sind und nur eine Handvoll überwiegend Cloud-basierter Dienste nutzen, können Sie möglicherweise innerhalb weniger Tage Standards festlegen und Ihre Dienste entsprechend konfigurieren. Wenn Sie bei Null anfangen, ist es sogar noch einfacher: Sie können diese Standards bereits bei der Erstellung Ihrer ersten Dienste anwenden und so langfristig erfolgreich sein, ohne zuvor konfigurierte Dienste ändern zu müssen.

Für größere Unternehmen mit Hunderten oder gar Tausenden von Diensten kann die Umstellung jedoch schwieriger sein. Für diese Unternehmen sind die folgenden Fragen hilfreich, um die weitere Vorgehensweise zu planen:

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 leicht auf alle Ihre Dienste anwenden lassen. Beispielsweise sollten Dienste einen Namen haben, der ihre Funktion genau beschreibt. Wenn Sie wissen, dass solche Standards für die meisten Dienste gelten sollten, ist dies ein guter Ausgangspunkt für die Implementierung. Überlegen Sie, wie Sie Pilotteams mit der Umsetzung dieser Änderungen beauftragen können.
2. Wie sieht der Prozess zur Schaffung neuer Dienste aus? Sie haben zwar Ihre Standards festgelegt, aber die Anpassung aller Ihrer aktuellen Dienste an diese Standards ist ein schwieriges Unterfangen. In größeren Organisationen ist es in der Regel nicht möglich, alle Dienste auf einmal neu zu konfigurieren. Und die Neukonfiguration von Diensten kann frustrierender sein, als sie von Anfang an korrekt 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 auch in Ordnung. Erstellen Sie einen Plan für die restlichen Dienste mit einer Frist und beginnen Sie dann mit der Einbindung weiterer Teams in den Prozess. Nehmen Sie dabei im Laufe der Zeit kleine, schrittweise Änderungen vor.
4. Wie 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. Überlegen Sie bei der Festlegung von Standards, wie Sie die Kodifizierung 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 Skalierung 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, weder Zeit noch Energie mit unwichtiger Arbeit zu verschwenden. Alles muss auf das reduziert werden, worauf sich das Team zur Lösung des Vorfalls konzentrieren muss.

Die Serviceverantwortung hilft Ihnen, während des gesamten Antwortprozesses Klarheit zu gewinnen:

Wenn Sie Ihren Dienst beispielsweise gut konfiguriert haben, werden Sie mit der richtigen Dringlichkeit und minimalem Alarmgeräusch alarmiert. So können Sie nur auf die wichtigsten Signale reagieren und entsprechend priorisieren. Da Sie wissen, wer die Dienstverantwortlichen sind, können Sie außerdem schnell die richtigen Leute vor Ort einsetzen. Mit zunehmender Reife können Sie zudem Automatisierungssequenzen für Ihre Dienste erstellen, die den Aufwand für die Wiederherstellung des Normalbetriebs reduzieren.

Die Diagnose des Fehlers ist ebenfalls einfacher, da Sie sehen, was sich am Dienst geändert hat. Und mit Dienstzuordnung, Sie können die Gesamtauswirkungen auf das System verstehen.

Während der Problemlösung können Sie schneller mit den für Ihren Service erforderlichen Integrationen arbeiten und die Beteiligten 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 des Unternehmens auf ein Minimum reduzieren.

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 Serviceverantwortung unternehmensweit ausweiten, machen sich diese Verbesserungen sowohl für Kunden als auch für Teamkollegen deutlich bemerkbar. Wenn Sie Serviceverantwortung übernehmen oder Ihre operative Reife verbessern möchten und einen Partner suchen, der Sie durch den Prozess begleitet, Testen Sie PagerDuty 14 Tage lang kostenlos Wenn Sie mehr über die Standardisierung des Service-Eigentums im großen Maßstab erfahren möchten, schauen Sie sich an: dieses Webinar .