Digitales Betriebsmanagement geht es darum, die Macht der Daten zu nutzen, um zu handeln, wenn es am wichtigsten ist. Es geht auch darum, die richtigen Prozesse und Verfahren zu haben, um Teams zu unterstützen, wenn jede Sekunde entscheidend ist. Die Weiterentwicklung Ihrer digitalen Abläufe erfordert Zeit, Iteration und Engagement. Die Veränderung wird nicht über Nacht passieren. Aber wenn Sie sich anstrengen, werden Sie enorme Vorteile ernten. Sie werden in der Lage sein, aus Vorfällen zu lernen und Ihre Dienste im Laufe der Zeit proaktiv zu verbessern.

Eine Möglichkeit zur Verbesserung der digitalen Betriebsreife ist die Einführung Dienstleistungseigentum. In diesem Blogbeitrag erklären wir Ihnen, was Service Ownership ist, wie Sie den Übergang gestalten, sobald Ihr Unternehmen die Neuausrichtung bekannt gibt, und wie Ihre Teams im Laufe der Zeit an Reife gewinnen.

Was also ist Serviceeigentum?

Service Ownership bedeutet, dass Mitarbeiter in jeder Phase des Software-/Service-Lebenszyklus die Verantwortung für die Unterstützung der von ihnen bereitgestellten Software übernehmen. Dieses Maß an Verantwortung bringt Entwicklungsteams viel näher an ihre Kunden, das Geschäft und den bereitgestellten Wert.

Die Vorteile des Serviceeigentums sind vielfältig, hier sind jedoch einige der wichtigsten:

• Ihre Teams wissen, wer wann Bereitschaft hat. Dadurch fühlen sie sich bei der Bereitschaft sicherer und übernehmen mehr Verantwortung für die Dienste, die sie erbringen.
• Die Servicezuverlässigkeit verbessert sich. Wenn sich ein Team auf einen bestimmten Service konzentriert, lassen sich Trends leichter erkennen. Zuverlässigkeitsprobleme treten schneller zutage und Verbesserungen können priorisiert werden.
• Die Kunden erleben weniger Serviceverschlechterungen und Ausfallzeiten. Zufriedenere Kunden bedeuten ein erfolgreicheres Geschäft. Mit Service Ownership können Sie schneller auf Vorfälle reagieren und diese sogar lösen, bevor es zu erheblichen Auswirkungen auf den Kunden kommt.

Viele Organisationen entscheiden sich für den Wechsel zum Service Ownership, um schneller Innovationen zu entwickeln und sich einen Wettbewerbsvorteil zu verschaffen. Die Flexibilität des Service Ownership ermöglicht es Ihnen, neue Wege einzuschlagen und sich schnell an Veränderungen anzupassen. Dies kann jedoch nicht isoliert erreicht werden. Service Ownership ist Teil eines neuen Kultur- und Betriebsmodells, das unternehmensweit eingeführt werden muss, um erfolgreich zu sein. Sehen wir uns an, wie Sie damit beginnen können.

Wie kann ich Serviceverantwortung übernehmen?

Wie jeder sinnvolle Kulturwandel ist Service Ownership keine Initiative, die Sie in einem einzigen Sprint abschließen können. Und damit diese Initiative erfolgreich ist, muss sich die gesamte Organisation in diese Richtung bewegen. Für die Zwecke dieses Blogbeitrags gehen wir davon aus, dass Ihre Organisation bereit ist, Service Ownership einzuführen, und dass Ihr Team nach der besten Möglichkeit sucht, die Veränderung umzusetzen. Um loszulegen, gibt es ein paar Dinge, die Sie tun können.

• Erstellen Sie eine Liste der Dienste. Wenn Sie keine Liste aller Dienste in Ihrem System erstellt haben, arbeiten Sie funktionsübergreifend mit anderen Teams zusammen, um alle beweglichen Teile zu verstehen. Auch wenn Sie irgendwann Geschäftsdienste einbeziehen möchten, sollten Sie es Schritt für Schritt angehen und sich zunächst auf diejenigen konzentrieren, die den Technologieteams gehören. Sobald Sie eine Liste der Dienste haben, ist es an der Zeit, mit dem „Eigentümer“-Teil zu beginnen.
• Definieren Sie das Team, das für den Dienst verantwortlich sein wird . Überlegen Sie zunächst, wer für den von Ihnen definierten Dienst verantwortlich ist. Ein Dienst sollte vollständig dem Team gehören, das ihn im Rahmen eines Bereitschaftsdiensts unterstützt. Wenn mehrere Teams die Verantwortung für einen Dienst teilen, ist es besser, diesen Dienst (falls möglich) in separate Dienste aufzuteilen. Einige Organisationen nennen dies „Dienstmitose“ – die Aufteilung einer Zelle in zwei separate Zellen, die jeweils sehr ähnlich aussehen wie das vorherige Ganze. Es gibt mehrere Methoden, um zu entscheiden, wie Dienste getrennt werden sollen, z. B. die Aufteilung basierend auf Teamgröße oder Codevolumen, das sie verwalten. Weitere Informationen dazu, wie wir das gemacht haben, finden Sie bei PagerDuty.
• Richten Sie den Bereitschaftsdienst für diesen Dienst ein. Stellen Sie sicher, dass die Teammitglieder gemeinsam für die Verfügbarkeit des Dienstes in der Produktion verantwortlich sind. Erstellen Sie Bereitschaftspläne, in denen Mitarbeiter und Ersatzkräfte regelmäßig wechseln, sowie Richtlinien, die Eskalationskontakte einschließen.
• Stellen Sie sicher, dass das Team die richtige Größe hat. Dienste sollten so detailliert eingerichtet werden, dass die Mitglieder des Teams schnell dabei helfen können, die Ursache von Problemen zu identifizieren. Dies kann für die Erstellung eines Dienstes gelten, dessen Umfang so groß ist, dass das zur Unterstützung erforderliche Wissen über die Fähigkeiten des Teams hinausgeht. Es gilt aber auch für die zu kleine Einteilung eines Teams. Wenn sich beispielsweise zwei Microservices effektiv wie ein einziger verhalten und die Behebung eines Problems bei einem Dienst auch die Behebung eines Problems bei einem anderen Dienst bedeutet, kann es sinnvoll sein, sie zu kombinieren.
• Fangen Sie klein an. Es ist wichtig, diese Änderung schrittweise einzuführen. Auf diese Weise können Sie frühzeitig Erfolge vorweisen und andere Teams dazu inspirieren, diese Denkweise zu übernehmen. Dies gibt den Teams auch Zeit, von anderen zu lernen, bevor sie selbst Service Ownership implementieren. Im Idealfall sollte die Änderung bei jedem Team reibungsloser erfolgen.

Passen Sie Dienste, Teams und Bereitschaftsrotationen entsprechend an, wenn Ihr System wächst und sich ändert. Das ist keine Aktion, die man einrichtet und dann vergisst. Stattdessen sollten Sie damit rechnen, dass sich Ihr Unternehmen ändert. Planen Sie Zeit für die Quartalsplanung ein, um zu verstehen, wie es Ihrem Team geht. Wenn Sie sich überfordert fühlen, sprechen Sie den Bedarf nach mehr Unterstützung an. Teams müssen sicherstellen, dass dieses Feedback an die Manager weitergegeben wird, und die Manager sind dafür verantwortlich, entsprechend zu eskalieren.

Brauchen wir dafür nicht eine Dokumentation?

Jeder Dienst benötigt eine Dokumentation, egal wie klein er ist. Die Dokumentation hilft allen, besser zu verstehen, was der Dienst ist und tut, wie er mit anderen Diensten interagiert und was zu tun ist, wenn Probleme auftreten. In diesem Sinne sind dies die wichtigsten Punkte, die beim Erstellen der Dokumentation angesprochen werden müssen.

Benennen und Beschreiben: Die besten Namen für Dienste sind nicht die, die clever benannt sind. Wenn Sie einen Dienst benennen, sollten Sie versuchen, die Funktion so einfach und anschaulich wie möglich auszudrücken. So vermeiden Sie spätere Verwirrungen, wenn Sie wachsen und skalieren. Stellen Sie sicher, dass Ihre Beschreibung ebenso informativ ist. Die Beschreibung sollte Fragen beantworten wie:

• Was ist der Zweck dieses Dienstes, dieser Komponente, dieses Funktionsteils?
• Welchen Mehrwert bietet dieses Ding?
• Wozu trägt es bei?
• Wenn dies Teil einer kundenorientierten Funktion ist, erklären Sie, welche Auswirkungen dies auf die Kunden hat und wie es sich auf die größere Geschäftskomponente auswirkt.

Abhängigkeiten ermitteln: Dienste funktionieren nicht im Vakuum. Unsere Arbeit wäre viel einfacher, wenn ein Problem in einem Dienst isoliert wäre und keine anderen Dienste beeinträchtigen würde. Dies ist jedoch nicht der Fall, da wir uns immer mehr in Richtung Mikrodienste bewegen. Sie müssen wissen, von welchen Diensten Ihre Dienste abhängen und welche Dienste von Ihren abhängen.

An diesem Punkt ist es äußerst wertvoll, eine Servicediagramm das sowohl die technischen als auch die geschäftlichen Dienste und ihre Zuordnung zueinander zeigt. Im Idealfall wäre dies ein dynamisches Tool, mit dem Sie verstehen, wie sich ein Ausfall in einem Teil des Systems auf den Rest des Systems als Ganzes auswirkt.

Neben der Abbildung dieser Abhängigkeiten sollten Sie auch Kommunikationspläne für sie haben. Wie werden Sie abhängige Dienste benachrichtigen, wenn ein Vorfall auftritt? Wie werden Sie technische Probleme an andere Geschäftsbereichsbeteiligte kommunizieren? Wenn Sie diese Pläne im Voraus ausarbeiten, können Sie Vorfälle in Bezug auf Folgendes betrachten: Reaktion des Unternehmens.

Runbooks : Runbooks sind ein wichtiges Werkzeug für Teams. Sie sind wie ein Spickzettel für jeden Service. Dokumentieren Sie, wie Sie häufige Aufgaben erledigen und häufige Vorfälle lösen. Wenn Sie mit Ihrem Service vertrauter werden, können Sie sogar Integrieren Sie die Automatisierung in Ihre Runbooks . Diese Automatisierung kann von erweiterten automatischen Korrektursequenzen, die bei manchen Vorfällen die Notwendigkeit menschlichen Eingreifens überflüssig machen, bis hin zur einfachen Kontexterfassung und Skriptausführung reichen.

Egal in welchem Stadium sich Ihre Runbooks befinden, es ist wichtig, diese regelmäßig zu aktualisieren. Wenn Sie während der Reaktion feststellen, dass in einem Runbook etwas nicht stimmt, markieren Sie es und kehren Sie später dazu zurück. Runbooks funktionieren nur, wenn sie den aktuellen Status widerspiegeln. Schaffen Sie sich Zeit und Platz, um diese Assets auf dem neuesten Stand zu halten.

Und denken Sie daran, dass Runbooks kein Allheilmittel sind. Sie können nicht für jeden Vorfall Lösungsanweisungen planen und festlegen. Wenn Ihr System wächst, werden Sie auf neue Vorfälle stoßen. Ein Runbook ist ein Werkzeug, kein Allheilmittel.

Woher weiß ich, wie Erfolg aussieht?

Wahrer Erfolg entsteht, wenn die gesamte Organisation Serviceverantwortung übernimmt. Diese Initiative ist nie abgeschlossen, da sich Services und ihre Anforderungen und Abhängigkeiten ständig ändern. Sie können jedoch Metriken verwenden, um die Leistung Ihres Services zu verstehen. Und Sie können mit Ihrem Team sprechen und qualitativ verstehen, wie es diese Änderung empfindet.

Um die Serviceleistung zu verstehen, können Sie sich verschiedene Tools ansehen. Erstens können Sie verwenden Analytik um zu verstehen, wie laut es ist, wie oft Ihr Team angepiept wird und wann diese Unterbrechungen auftreten. Dies kann Ihnen ein Verständnis dafür geben, wie gesund Ihr Dienst in den Augen des Teams ist, das ihn unterstützt.

Wenn Sie wissen möchten, wie Ihr Service in den Augen Ihrer Kunden abschneidet, gibt es auch dafür ein Tool. SLOs oder Service Level Objectives sind eine interne Messgröße, mit der die Zuverlässigkeit eines Dienstes gemessen wird. SLOs legen fest, wie viele Fehler ein Dienst aufweisen kann, bevor ein Kunde unzufrieden ist, und werden aus SLIs (Service Level Indicators) erstellt.

Wenn Sie innerhalb der akzeptablen Fehlergrenze (auch Fehlerbudget genannt) liegen, wird Ihr Service von den Kunden als zuverlässig wahrgenommen. Wenn Sie Ihr SLO nicht einhalten, sind Ihre Kunden wahrscheinlich mit Ihrer Leistung unzufrieden.

SLOs sind großartige Tools, um Zuverlässigkeit zu messen und den Wert von Service Ownership aufzuzeigen. Aber sie sind nicht die einzige Möglichkeit, Erfolg zu messen. Sie müssen auch mit Ihren Teams sprechen, um ihre Gefühle zu verstehen.

Offene Diskussionen mit Teams können das Vertrauen stärken und die psychologische Sicherheit erhöhen. Das ist äußerst wichtig, da Sie auf dem Weg dorthin auch auf Misserfolge stoßen werden. Möglicherweise haben Sie Ihre Teams zu Beginn Ihrer Reise nicht richtig dimensioniert und einige Dienste haben möglicherweise nicht genügend Support. Möglicherweise haben Sie nicht die richtigen SLOs und müssen neu kalibrieren. Ganz gleich, auf welche Herausforderung Sie stoßen, Sie müssen schuldlos bleiben.

Diese Hürden bedeuten, dass Sie lernen und sich verbessern. Wenn Sie ihnen mit einer positiven Einstellung begegnen und den Servicebesitzern zuhören, verbessern Sie die Zuverlässigkeit Ihrer Services, Ihres Systems als Ganzes und die Zufriedenheit Ihrer Teams.

Was ist mein nächster Schritt?

Die Steigerung der Reife Ihrer digitalen Abläufe ist ein langer Weg, aber einer, der sich lohnt. Er ist vorteilhaft für Ihr Team, die von Ihnen betriebenen Dienste und Ihre Kunden. Die Übernahme einer Service Ownership-Denkweise ist nicht die einzige Möglichkeit, diese Verbesserungen zu erzielen, aber sie ist eine Schlüsselkomponente.

Wenn Sie mehr über Service Ownership erfahren möchten, können Sie Lesen Sie unseren Ops Guide oder schau dir das an Webinar auf Abruf Wenn Sie mehr über die Planung der digitalen Betriebsreife erfahren möchten, Schauen Sie sich unser eBook an . Und wenn Sie sehen möchten, wie PagerDuty Ihnen helfen kann, Initiativen wie FSO und operative Reife voranzutreiben, testen Sie uns 14 Tage kostenlos.