Habt ihr den DevOps-Kreislauf nach dem Deployment geschlossen?

Können wir den DevOps-Kreislauf mit IT Service Management schließen?

Die „Mauer der Verwirrung“ hat zwei Seiten. Eine ist der Entwicklung zugewandt, die andere dem Betrieb. Wird diese Mauer dargestellt, sehen wir meist einen Fluss von der Entwicklung zum Betrieb – und nur selten in die umgekehrte Richtung.

DevOps wird hingegen ganz anders dargestellt: als Endlosschleife, die die Bereiche beschreibt, die wir abdecken müssen, und die Fähigkeiten, die wir als Produkt- oder Serviceorganisation benötigen. Wie wir alle wissen, geht es bei DevOps darum, die „Mauer der Verwirrung“ einzureißen und die Zusammenarbeit von Dev und Ops zu verändern. Unser Ziel ist eine Kultur, in der Dev und Ops zusammenarbeiten, um häufig hochwertigen, Mehrwert schaffenden Code bereitzustellen – mit einem durchgängigen Fluss von der Entdeckung bis zum kontinuierlichen Feedback.

Aber Hand aufs Herz: Konzentrieren wir uns wirklich ausreichend auf das, was nach dem Deployment passiert? Übersehen wir nicht viele Aspekte der Zusammenarbeit zwischen Ops und Dev?

In diesem Blog geht es darum, den DevOps-Kreislauf zu verbinden, den Fokus auf die Ops-Seite zu richten und zu zeigen, wie sie in die Produktentdeckung einfließen kann. Außerdem möchte ich darauf eingehen, wie wir mit IT Service Management (ITSM) Erkenntnisse darüber gewinnen können, wie wir eine hohe Servicequalität und Mehrwert für Kunden bereitstellen.

Was verstehen wir unter Operations in DevOps?

Wenn ihr zehn Personen diese Frage stelltet, würdet ihr vermutlich zehn verschiedene Antworten erhalten. Ich persönlich würde es als die Praxis und Fähigkeit zusammenfassen, sicherzustellen, dass alles, was deployt wird, mit der richtigen Kapazität und dem passenden Sicherheitsniveau verwaltet wird und verfügbar ist.

Wer macht was im Betrieb?

Wenn Code in der Produktion deployt wurde und nachweislich funktioniert, sind die Betriebsteams dafür verantwortlich, dass alles online bleibt. Wie das geschieht, hängt von der Architektur der bereitgestellten Services ab. Läuft alles On-Premises, oder gibt es für die verschiedenen Teile des Services eine Kombination aus Infrastructure as a Service (IaaS) und Platform as a Service (PaaS)? Arbeitet das Betriebsteam intern, ausgelagert, gemeinsam mit externen Ressourcen oder mit mehreren Dienstleistern?

Das spielt eigentlich keine Rolle. Wichtig ist jedoch, dass wir die Zusammenarbeit und das Erwartungsmanagement zwischen den verschiedenen Stakeholdern berücksichtigen.

Wichtig ist, dass wir die Informationen aller Beteiligten erhalten, um Entscheidungen treffen und die anstehenden Aufgaben priorisieren zu können. So wollen wir beispielsweise Entscheidungen treffen können, die den Aufbau technischer Schulden verhindern, und sicherstellen, dass Änderungen in der Umgebung die bereitgestellten Services nicht beeinträchtigen.

Dabei ist die Zusammenarbeit zwischen Dev und Ops entscheidend, um die richtigen Entscheidungen zu treffen und Erkenntnisse für die Produktentdeckung zu liefern. Auf dem Markt gibt es viele verschiedene Tools für den Betriebsbereich von DevOps. Jedes stellt unterschiedliche Daten und Informationen auf verschiedene Weise und für unterschiedliche Zwecke bereit.

In ITIL4, einem Framework für ITSM, gibt es einige Prinzipien, die mit diesem Thema zusammenhängen:

• Zusammenarbeit fördern und Transparenz schaffen

• Einfach und praktisch halten

Wir müssen sicherstellen, dass die von den Betriebstools bereitgestellten Daten und Informationen für die Stakeholder verfügbar und einfach nutzbar sind – unabhängig davon, ob es sich um einen Produktmanager, Produktdesigner oder leitenden Produktentwickler handelt. Dadurch können sie die Services besser verwalten und weiterentwickeln.

Als Organisation solltet ihr außerdem sicherstellen, dass Entscheidungen auf der richtigen Ebene getroffen werden. Operative Entscheidungen sollten möglichst nah am Betriebsteam getroffen werden, vorzugsweise im Team selbst. Das unterstützt das Team dabei, autonomer und Agile zu arbeiten. Für ein IT Service Management mit hoher Geschwindigkeit müsst ihr Verschwendung wie Übergaben und Wartezeiten so weit wie möglich reduzieren. Vertraut euren Teams – unabhängig davon, ob sie mit Dev, Ops oder DevOps arbeiten.

Wie beobachten wir?

Beginnen wir mit einer Frage: Warum beobachten wir? Wenn die Antwort lediglich lautet: „Wir möchten die Performance unserer Anwendung überwachen“, hilft uns das aus Sicht von ITSM oder DevOps nicht weiter. Wir müssen klar definieren, was wir mit den Erkenntnissen aus unseren Beobachtungen tun wollen und wer sie nutzen kann und wird.

Wir müssen auch beantworten können, ob das Ergebnis gut, schlecht oder erwartet war. Der Hauptgrund für Beobachtung und Monitoring besteht darin, das Beobachtete zu verbessern – einschließlich der Behebung von Fehlern.

Kontinuierliche Verbesserung ist eine zentrale Fähigkeit in Lean, DevOps und ITSM. Deshalb müssen wir sicherstellen, dass die Tools, die wir zur Beobachtung einsetzen, relevante Informationen liefern, mit denen wir Verbesserungspotenziale erkennen können. Diese Informationen sind entscheidend für Produktmanager, Produktdesigner oder leitende Produktentwickler, die dafür verantwortlich sind, unsere Services kontinuierlich zu verbessern.

Wir möchten sie dazu befähigen, auf durch Beobachtung erkannte Abweichungen zu reagieren, damit wir Verbesserungen der Technologie, notwendige Änderungen in der Arbeitsweise, bei Tools oder in der Zusammenarbeit mit Partnern nicht verpassen.

Was beobachten wir also in einer DevOps-Umgebung? Wenn wir uns die Metriken in einem DORA-Bericht ansehen, umfasst dieser:

• Deployment-Häufigkeit (Wie oft ein Softwareteam Änderungen in die Produktion überträgt)

• Change Lead Time (Die Zeit, die benötigt wird, damit übergebener Code in der Produktion ausgeführt wird)

• Change Failure Rate (Der Anteil von Incidents, Rollbacks und Fehlern an allen Deployments)

• Zeit bis zur Wiederherstellung des Services (Die Zeit, die benötigt wird, um den Service in der Produktion nach einem Incident wiederherzustellen)

Die letzten beiden Punkte sind eng mit ITSM verbunden: Der erste bezieht sich auf die ITIL-Praktiken Change Control und Incident Management, der letzte auf Incident Management. Das bedeutet, dass wir Incidents und Changes in der Produktumgebung überwachen und miteinander in Beziehung setzen müssen, um den ITIL-Qualitäts-KPI für durch Changes verursachte Incidents zu ermitteln. Ein Teil davon lässt sich automatisieren, indem die CI/CD-Pipeline beispielsweise in Jira Service Management in die Change Control integriert wird.

Was müssen wir außerdem beobachten, um die Services für unsere Kunden zu verbessern? Die Liste könnte sehr lang sein. Wie wäre es aber mit Interaktionen im User Support, der Nutzung verfügbarer Servicefunktionen und der User Experience des Produkts?

Für Produktorganisationen ist es entscheidend, die Nutzung verschiedener Features und die Häufigkeit zu messen, mit der Menschen den Standardservice verwenden, um neue Möglichkeiten für die Weiterentwicklung zu erkennen. Produktmanager, Produktdesigner und leitende Entwickler benötigen Möglichkeiten, um zu erkennen, was für Endnutzer Mehrwert schafft. So können sie alle Backlog-Aktivitäten eliminieren, die keinen Kundenmehrwert schaffen.

Einige Studien zeigen, dass es nicht ungewöhnlich ist, wenn ein Drittel des Backlogs keinen Mehrwert für Endnutzer schafft. Diese Einträge sind lediglich Verschwendung und nehmen den wirklich wertvollen Aufgaben Platz weg.

Ein häufiger Fehler bei Monitoring und Beobachtung besteht darin, unterschiedliche Dimensionen der Ursache von Abweichungen nicht zu berücksichtigen. In ITIL gibt es die Praxis Problem Management, die eng mit kontinuierlicher Verbesserung verbunden ist. Ihr Ziel ist es, wiederkehrende Qualitätsprobleme wie Incidents zu managen. Bei der Ursachenanalyse von Problemen ist es dabei entscheidend, diese in vier Dimensionen zu betrachten:

• Organisationen und Menschen

• Informationen und Technologie

• Partner und Lieferanten

• Wertströme und Prozesse

In Technologie- und Produktorganisationen wird bei Ursachenanalysen häufig nur die Dimension Informationen und Technologie berücksichtigt. Das schränkt die Fähigkeit erheblich ein, die tatsächliche Ursache zu finden, sie zu beseitigen und die Servicequalität zu verbessern. Wenn ihr nicht alle Dimensionen analysiert, treten Abweichungen derselben Art in der Technologie wahrscheinlich immer wieder auf.

Wie können wir mit kontinuierlichem Feedback arbeiten?

Viele der Informationen und Daten, die wir in Ops sammeln, können wir in Berichten und Dashboards aufbereiten, um datenbasiert zu arbeiten, oder von AI analysieren lassen. Darüber hinaus brauchen wir aber auch Räume für Zusammenarbeit und Dialog, um voneinander zu lernen. Ein guter Weg dafür sind regelmäßige Treffen zwischen Customer-Support-Teams sowie Dev- und Ops-Teams, um Erkenntnisse auszutauschen und gute funktionsübergreifende Beziehungen aufzubauen. Dadurch entsteht eine Kultur der Zusammenarbeit und Transparenz – grundlegende Prinzipien von ITSM, Agile, Lean und DevOps.

Damit unsere Feedbackschleifen für Product Discovery davon profitieren, müssen wir die Erkenntnisse aus Betrieb und Beobachtung bewerten, evaluieren, priorisieren und dokumentieren. Wir müssen Daten zu Informationen strukturieren und Kontext hinzufügen, um Wissen als Grundlage für Entscheidungen zu schaffen. Chancen müssen präsentiert, Mehrwert identifiziert und Risiken gemanagt werden. Außerdem muss alles so aufbereitet sein, dass Product Discovery es evaluieren, priorisieren und darüber entscheiden kann.

Den Kreislauf schließen

In dieser letzten Phase haben wir aus meiner Sicht große Fortschritte dabei gemacht, den DevOps-Unendlichkeitskreislauf von Deploy bis Product Discovery zu schließen. Natürlich gibt es keine Patentrezepte oder magischen Lösungen, die für jede Organisation passen. Doch jede Organisation kann ihre Stärken und Schwächen erkennen und Schritte hin zu einer vollständigen DevOps-Arbeitsweise unternehmen, die eng mit ITSM-Praktiken und der Arbeit von Ops integriert ist.

Der erste Schritt besteht darin, eure Stärken und Schwächen in Arbeitsweise, Tooling und Kultur zu bewerten und zu identifizieren.

Zusammenfassung der empfohlenen Maßnahmen

Zusammenarbeit und Dialog

Bringt verschiedene Teams – Customer Support, Development und Operations – zusammen, damit sie Erkenntnisse austauschen und funktionsübergreifende Beziehungen aufbauen können. Schafft eine Kultur der Zusammenarbeit und Transparenz auf Basis grundlegender Prinzipien aus ITSM, Agile, Lean und DevOps.

Strukturierte Datentransformation

Wandelt operative Rohdaten in strukturierte und aussagekräftige Informationen um. Setzt diese Informationen in Kontext, um Wissen zu schaffen, das als Grundlage für Entscheidungen dient.

Priorisierung und Bewertung

Bewertet, evaluiert und priorisiert Erkenntnisse aus dem Betrieb. So stellt ihr sicher, dass nur das wichtigste Feedback in die Product-Discovery-Phase einfließt.

Feedback in die Produktfindung integrieren

Schafft Möglichkeiten, Informationen aus Observe und kontinuierlichem Feedback während der Produktfindungsphase zu nutzen, um zu bewerten, zu priorisieren und Entscheidungen zu treffen. So stellt ihr sicher, dass Erkenntnisse aus den Betriebsphasen bei der Bewertung neuer Features oder Verbesserungen genutzt werden.

Kontinuierliche Beobachtung und Überwachung

Nutzt Observability-Tools, die allen Beteiligten im DevOps-Infinity-Loop relevante Informationen liefern – insbesondere Betriebsingenieuren, Produktmanagern, Produktdesignern und leitenden Produktentwicklern. Befähigt eure Teams, auf Abweichungen und Verbesserungsmöglichkeiten zu reagieren, die durch die Beobachtung erkannt wurden.

Ursachenanalyse

Stellt sicher, dass ihr eine umfassende Ursachenanalyse durchführt und dabei alle vier in ITIL4 aufgeführten Dimensionen berücksichtigt:

• Organisationen und Menschen

• Informationen und Technologie

• Partner und Lieferanten

• Wertströme und Prozesse

Beschränkt euch nicht nur auf die technologische Dimension. Indem ihr alle Dimensionen berücksichtigt, können Teams sämtliche zugrunde liegenden Probleme ganzheitlich verstehen und angehen.

Verankert kontinuierliche Verbesserung in eurer DNA

Der Hauptgrund für Beobachtung und Überwachung besteht darin, das Beobachtete kontinuierlich zu verbessern. Stellt sicher, dass diese Denkweise in der DNA eurer Organisation verankert ist, und ermutigt eure Teams, Feedback proaktiv zu nutzen, um kontinuierliche Produktverbesserungen voranzutreiben und zu ermöglichen.

Analysefunktionen integrieren und aufbauen

Stellt sicher, dass eure Tools integriert sind, um die Automatisierung von Messgrößen und Kennzahlen zu ermöglichen. Ein Beispiel ist die Integration eurer CI/CD-Pipeline mit eurem ITSM-Tool, um die ITIL-Practice Change Control zu nutzen.

Den Feedback-Loop schließen

Kommuniziert, kommuniziert, kommuniziert. Stellt sicher, dass eure Betriebsinformationen nicht in Silos stecken bleiben, sondern von Operate zur Produktfindung fließen, um den DevOps-Infinity-Loop zu schließen.