Der Blog

Wie Service Ownership Ihnen dabei helfen kann, Ihre betriebliche Reife zu steigern

von Hannah Culver 1. November 2021 | 10 Minuten Lesezeit

Digitales Betriebsmanagement Es geht darum, die Macht der Daten zu nutzen, um im entscheidenden Moment zu handeln. Es geht auch darum, die richtigen Prozesse und Verfahren zu haben, um Teams zu unterstützen, wenn jede Sekunde zählt. Die Weiterentwicklung Ihrer digitalen Abläufe erfordert Zeit, Iteration und Engagement. Der Wandel geschieht nicht über Nacht. Aber wenn Sie sich anstrengen, werden Sie enorme Vorteile ernten. Sie können aus Vorfällen lernen und Ihre Services im Laufe der Zeit proaktiv verbessern.

Eine Möglichkeit zur Verbesserung der Reife Ihres digitalen Betriebs besteht in der Einführung Diensteigentum In diesem Blogbeitrag erklären wir, was Service Ownership ist, wie Sie den Übergang gestalten, sobald Ihr Unternehmen die Neuausrichtung ankündigt, und wie Ihre Teams im Laufe der Zeit an Reife gewinnen.

Was also ist Service Ownership?

Service Ownership bedeutet, dass Mitarbeiter in jeder Phase des Software-/Service-Lebenszyklus die Verantwortung für die von ihnen bereitgestellte Software übernehmen. Dieses Maß an Eigenverantwortung bringt Entwicklungsteams ihren Kunden, dem Unternehmen und dem bereitgestellten Wert deutlich näher.

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

  • Ihre Teams wissen, wer wann Bereitschaftsdienst hat Dies gibt ihnen mehr Sicherheit im Bereitschaftsdienst und stärkt die Verantwortlichkeit für die von ihnen erbrachten Dienste.
  • Verbesserte Servicezuverlässigkeit Wenn sich ein Team auf einen bestimmten Dienst konzentriert, lassen sich Trends leichter erkennen. Probleme mit der Zuverlässigkeit treten schneller zutage und Verbesserungen können priorisiert werden.
  • Kunden erleben weniger Serviceeinbußen 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 nennenswerten Auswirkungen auf den Kunden kommt.

Viele Unternehmen entscheiden sich für Service Ownership, um Innovationen zu beschleunigen und sich einen Wettbewerbsvorteil zu verschaffen. Die Flexibilität von Service Ownership ermöglicht es, neue Wege einzuschlagen und sich schnell an Veränderungen anzupassen. Dies lässt sich jedoch nicht isoliert bewältigen. 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.

Wie kann ich Service Ownership übernehmen?

Wie jeder sinnvolle Kulturwandel lässt sich auch Service Ownership nicht in einem einzigen Sprint umsetzen. Für den Erfolg dieser Initiative ist es notwendig, dass sich die gesamte Organisation in diese Richtung bewegt. Für diesen Blogbeitrag gehen wir davon aus, dass Ihre Organisation bereit für Service Ownership ist und Ihr Team nach dem besten Weg für die Veränderung sucht. Für den Einstieg gibt es einige Möglichkeiten.

  • Erstellen Sie eine Liste der Dienste Wenn Sie noch keine Liste aller Dienste in Ihrem System erstellt haben, arbeiten Sie funktionsübergreifend mit anderen Teams zusammen, um alle relevanten Komponenten zu verstehen. Auch wenn Sie irgendwann auch Geschäftsdienste einbeziehen möchten, sollten Sie schrittweise vorgehen und sich zunächst auf die Dienste konzentrieren, die den Technologieteams gehören. Sobald Sie eine Liste der Dienste haben, können Sie mit dem „Eigentümer“-Teil beginnen.
  • Definieren Sie das Team, das für den Dienst verantwortlich sein wird Überlegen Sie zunächst, wer für den Service verantwortlich ist, den Sie definieren. Ein Service sollte vollständig dem Team gehören, das ihn im Rahmen eines Bereitschaftsdienst-Rotationsplans unterstützt. Teilen sich mehrere Teams die Verantwortung für einen Service, ist es besser, diesen Service (sofern möglich) in separate Services aufzuteilen. Manche Organisationen nennen dies „Service-Mitose“ – die Aufteilung einer Zelle in zwei separate Zellen, die sich jeweils stark ähneln. Es gibt verschiedene Methoden, um die Aufteilung von Services zu bestimmen, z. B. die Aufteilung nach Teamgröße oder Menge des zu verwaltenden Codes. Weitere Informationen dazu 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 rotieren, sowie Richtlinien, die Eskalationskontakte beinhalten.
  • Stellen Sie sicher, dass das Team die richtige Größe hat . Dienste sollten so detailliert eingerichtet werden, dass die Teammitglieder schnell zur Identifizierung der Problemursache beitragen können. Dies gilt beispielsweise für die Erstellung eines Dienstes mit einem so großen Umfang, dass das zu seiner Unterstützung erforderliche Wissen über die Teamressourcen hinausgeht. Es gilt aber auch für die zu kleine Teamgröße. Wenn sich beispielsweise zwei Microservices effektiv wie ein einziger verhalten und die Behebung eines Problems bei einem Dienst auch die Behebung eines anderen Dienstes erfordert, kann es sinnvoll sein, sie zu kombinieren.
  • Fangen Sie klein an Es ist wichtig, diese Änderung schrittweise einzuführen. So können Sie frühzeitig Erfolge vorweisen und andere Teams für diese Denkweise begeistern. So haben die Teams auch Zeit, von anderen zu lernen, bevor sie selbst Service Ownership implementieren. Im Idealfall sollte die Änderung mit jedem Team reibungsloser umgesetzt werden.

Passen Sie Services, Teams und Bereitschaftspläne entsprechend an, wenn Ihr System wächst und sich verändert. Das ist keine „Einstellen und dann vergessen“-Aktion. Stellen Sie sich stattdessen auf Veränderungen ein, die sich mit Ihrem Unternehmen ändern. Planen Sie in der Quartalsplanung Zeit ein, um zu verstehen, wie es Ihrem Team geht. Wenn Sie sich überfordert fühlen, sprechen Sie den Bedarf an mehr Unterstützung an. Die Teams müssen sicherstellen, dass dieses Feedback an die Manager weitergegeben wird, und die Manager sind für die entsprechende Eskalation verantwortlich.

Brauchen wir dafür nicht eine Dokumentation?

Jeder Dienst benötigt eine Dokumentation, egal wie klein er ist. Dokumentation hilft allen, besser zu verstehen, was der Dienst ist und tut, wie er mit anderen Diensten interagiert und was bei Problemen zu tun ist. Vor diesem Hintergrund sind dies die wichtigsten Punkte, die bei der Erstellung der Dokumentation berücksichtigt werden sollten.

Benennen und Beschreiben : Die besten Dienste sind nicht die mit den cleversten Namen. Überlegen Sie sich bei der Benennung eines Dienstes, wie er am einfachsten und aussagekräftigsten beschreiben soll, was er tut. So vermeiden Sie spätere Verwirrungen, wenn Ihr Unternehmen wächst und skaliert. Achten Sie darauf, dass Ihre Beschreibung ebenso aussagekräftig 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 luftleeren Raum. 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 Microservices bewegen. Sie müssen wissen, von welchen Diensten Ihre Dienste abhängen und welche Dienste von Ihren.

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

Neben der Abbildung dieser Abhängigkeiten sollten Sie auch Kommunikationspläne dafür haben. Wie benachrichtigen Sie abhängige Dienste im Falle eines Vorfalls? Wie kommunizieren Sie technische Probleme an andere Geschäftsbereichsbeteiligte? Wenn Sie diese Pläne im Voraus erstellen, können Sie Vorfälle im Hinblick auf Folgendes betrachten: Geschäftsreaktion .

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 sich mit Ihrem Service besser auskennen, können Sie sogar Integrieren Sie Automatisierung in Ihre Runbooks Diese Automatisierung kann von erweiterten automatischen Korrektursequenzen, die bei manchen Vorfällen die Notwendigkeit menschlicher Beteiligung überflüssig machen, bis hin zur einfachen Kontexterfassung und Skriptausführung reichen.

Unabhängig vom aktuellen Stand Ihrer Runbooks ist es wichtig, diese regelmäßig zu aktualisieren. Sollten Sie während der Bearbeitung einen Fehler in einem Runbook feststellen, markieren Sie ihn und greifen Sie später darauf zurück. Runbooks funktionieren nur, wenn sie den aktuellen Stand widerspiegeln. Nehmen Sie sich Zeit und Raum, um diese Assets auf dem neuesten Stand zu halten.

Und denken Sie daran: Runbooks sind kein Allheilmittel. Sie können nicht für jeden Vorfall eine Lösung planen und festlegen. Mit dem Wachstum Ihres Systems 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. Mithilfe von Kennzahlen können Sie jedoch die Leistung Ihres Services nachvollziehen. Und Sie können mit Ihrem Team sprechen und die Meinung zu dieser Änderung qualitativ erfassen.

Um die Service-Performance 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. So können Sie nachvollziehen, wie gut Ihr Service 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 Metrik zur Messung der Zuverlässigkeit eines Dienstes. SLOs bestimmen die Anzahl der Fehler, die ein Dienst aufweisen kann, bevor ein Kunde unzufrieden ist, und werden aus SLIs (Service Level Indicators) erstellt.

Wenn Sie innerhalb der akzeptablen Fehlergrenze (auch als Fehlerbudget bezeichnet) 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 hervorragende Tools, um Zuverlässigkeit zu messen und den Wert von Service Ownership zu demonstrieren. Sie sind jedoch 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 nicht richtig dimensioniert, und einige Dienste sind möglicherweise nicht ausreichend unterstützt. Möglicherweise verfügen Sie nicht über die richtigen SLOs und müssen neu kalibrieren. Welche Herausforderungen auch immer auf Sie zukommen, Sie müssen sich keine Vorwürfe machen.

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

Was ist mein nächster Schritt?

Die Steigerung der digitalen Betriebsreife ist ein langer Weg, der sich aber lohnt. Er ist vorteilhaft für Ihr Team, Ihre Services und Ihre Kunden. Die Übernahme einer Service-Ownership-Mentalität ist nicht der einzige Weg, diese Verbesserungen zu erzielen, aber ein wichtiger Bestandteil.

Wenn Sie mehr über Service Ownership erfahren möchten, können Sie Lesen Sie unseren Ops Guide oder schau dir das an On-Demand-Webinar 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 dabei helfen kann, Initiativen wie FSO und Betriebsreife voranzutreiben, Testen Sie uns 14 Tage lang kostenlos .