Software Architektur Metriken

Kapitel 1. Vier Schlüsselmetriken entfesselt

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Andrew Harmel-Law

Man könnte meinen, dass Dr. Nicole Forsgren, Jez Humble und Gene Kims bahnbrechendes Buch Accelerate (IT Revolution Press, 2018) sowohl das erste als auch das letzte Wort darüber ist, wie du die Leistung deiner Softwareentwicklung verbessern kannst, und zwar anhand von vier einfachen, aber wirkungsvollen Kennzahlen.

Da ich mich bei meiner Transformationsarbeit an vielen Empfehlungen des Buches orientiert habe, habe ich sicherlich keine Probleme mit dem Inhalt. Aber anstatt alles noch detaillierter zu machen, denke ich, dass das Buch weiter diskutiert und analysiert werden sollte, um den Erfahrungsaustausch und das Zusammenkommen einer Gemeinschaft von Menschen zu ermöglichen, die Architektur praktizieren und sich verbessern wollen. Ich hoffe, dass dieses Kapitel zu einer solchen Diskussion beitragen wird.

Ich habe die Erfahrung gemacht, dass die vier Schlüsselkennzahlen - Bereitstellungshäufigkeit, Vorlaufzeit für Änderungen, Fehlerquote bei Änderungen und Zeit bis zur Wiederherstellung des Dienstes - zu einem großen Lerneffekt führen, wenn sie so eingesetzt werden, wie in diesem Kapitel beschrieben: und es den Teams ermöglichen, die Notwendigkeit einer qualitativ hochwertigen, lose gekoppelten, prüfbaren, beobachtbaren und wartbaren Architektur zu verstehen. Wenn du die vier Schlüsselkennzahlen effektiv einsetzt, kannst du als Architekt das Ruder herumreißen. Statt zu diktieren und zu kontrollieren, kannst du die vier Schlüsselkennzahlen nutzen, um Gespräche mit Teammitgliedern anzuregen und den Wunsch zu wecken, die gesamte Softwarearchitektur über dich hinaus zu verbessern. So kannst du schrittweise zu einer besser testbaren, kohärenten und zusammenhängenden, modularen, fehlertoleranten und cloudbasierten, lauffähigen und beobachtbaren Architektur übergehen.

In den folgenden Abschnitten zeige ich dir, wie du deine vier Schlüsselmetriken einrichtest und - was noch wichtiger ist - wie du und deine Softwareteams die Metriken am besten nutzen könnt, um eure Bemühungen um kontinuierliche Verbesserungen zu fokussieren und Fortschritte zu verfolgen. Ich konzentriere mich auf die praktischen Aspekte der Visualisierung des mentalen Modells der vier Schlüsselmetriken, der Beschaffung der erforderlichen drei Rohdatenpunkte und der Berechnung und Darstellung der vier Metriken. Aber keine Sorge: Ich werde auch auf die Vorteile einer Architektur eingehen, die in der Produktion läuft.

Definition und Instrumentierung

Paradigmen sind die Quellen von Systemen. Aus ihnen, aus gemeinsamen gesellschaftlichen Übereinkünften über die Natur der Realität, entstehen Systemziele und Informationsflüsse, Rückkopplungen, Bestände, Ströme und alles andere, was Systeme ausmacht.

Donella Meadows, Das Denken in Systemen: Eine Fibel¹

Das mentale Modell, das Accelerate zugrunde liegt, führt zu den vier Schlüsselmetriken. Ich beginne hier, weil es wichtig ist, sich dieses mentale Modell vor Augen zu halten, während du dieses Kapitel liest. In seiner einfachsten Form ist das Modell eine Pipeline (oder ein "Fluss") von Aktivitäten, die immer dann beginnt, wenn ein Entwickler seine Codeänderungen in die Versionskontrolle einspeist, und die dann endet, wenn diese Änderungen in das laufende System übernommen werden, an dem die Teams arbeiten, und den Nutzern einen laufenden Dienst zur Verfügung stellen. Du kannst dieses mentale Modell in Abbildung 1-1 sehen.

Abbildung 1-1. Das grundlegende mentale Modell hinter den vier Schlüsselmetriken

Zur Verdeutlichung wollen wir uns ansehen, was die vier Schlüsselkennzahlen in diesem Modell messen:

Häufigkeit des Einsatzes

Die Anzahl der einzelnen Änderungen, die im Laufe der Zeit am Ende der Pipe ankommen. Diese Änderungen können aus "Bereitstellungseinheiten" bestehen: Code, Konfiguration oder eine Kombination aus beidem, z. B. eine neue Funktion oder eine Fehlerbehebung.

Vorlaufzeit für Änderungen

Die Zeit, die ein Entwickler benötigt, um seine Code-/Konfigurationsänderungen durch die Pipeline zu schicken und am anderen Ende wieder herauszukommen.

Zusammengenommen misst dieses erste Paar den Entwicklungsdurchsatz. Dies ist nicht zu verwechseln mit der Lean Cycle Time oder der Lead Time, die die Zeit für das Schreiben des Codes umfasst. Manchmal beginnt die Uhr sogar schon, wenn der Produktmanager die Idee für seine neue Funktion hat.

Ausfallrate ändern

Der Anteil der Änderungen, die aus der Pipe kommen und einen Fehler in unserem laufenden Dienst verursachen. (Was genau ein "Fehler" ist, wird in Kürze erläutert. Für den Moment kannst du dir einen Fehler als etwas vorstellen, das die Nutzer deines Dienstes daran hindert, ihre Aufgaben zu erledigen.)

Zeit zur Wiederherstellung des Dienstes

Wie lange es nach einem Ausfall des Dienstes dauert, bis er bemerkt wird und der Dienst wieder zur Verfügung steht.²

Zusammengenommen gibt dieses zweite Paar einen Hinweis auf die Stabilität des Dienstes.

Die Stärke dieser vier Schlüsselindikatoren liegt in ihrer Kombination. Wenn du einen Teil des Entwicklungsdurchsatzes verbesserst, aber gleichzeitig die Stabilität des Dienstes verschlechterst, dann sind deine Verbesserungen unausgewogen und werden dir auf lange Sicht fehlen. Das Wichtigste ist, dass du alle vier Schlüsselkennzahlen im Auge behältst. Veränderungen, die einen vorhersehbaren, langfristigen Nutzen bringen, sind solche, die in allen Bereichen positive Auswirkungen haben.

Jetzt, wo wir wissen, woher unsere Kennzahlen kommen, können wir die Sache verkomplizieren, indem wir das allgemeine mentale Modell auf deinen tatsächlichen Lieferprozess abbilden. Im nächsten Abschnitt werde ich dir zeigen, wie du dieses "mentale Refactoring" durchführen kannst.

Dein mentales Modell umgestalten

Es ist wichtig, dass du jede Metrik für deine Situation definierst. Wie du wahrscheinlich schon vermutet hast, sind die ersten beiden Metriken davon abhängig, was in deinen CI-Pipelines passiert, und die zweiten beiden erfordern die Verfolgung von Serviceausfällen und Wiederherstellung.

Überlege dir den Umfang sorgfältig, wenn du dieses mentale Refactoring durchführst. Betrachtest du alle Änderungen für alle Teile der Software in deinem Unternehmen? Oder betrachtest du nur die Änderungen in deinem Arbeitsprogramm? Beziehst du Änderungen an der Infrastruktur mit ein oder betrachtest du nur die Änderungen an der Software und den Diensten? All diese Möglichkeiten sind in Ordnung, aber erinnere dich: Der Umfang, den du betrachtest, muss für jede der vier Kennzahlen derselbe sein. Wenn du Änderungen an der Infrastruktur in die Vorlaufzeit und die Einsatzhäufigkeit einbeziehst, musst du auch die durch die Änderungen an der Infrastruktur verursachten Ausfälle berücksichtigen.

Pipelines als erste Anlaufstelle

Welche Pipelines solltest du in Betracht ziehen? Die Pipelines, die du brauchst, sind diejenigen, die auf Code- und Konfigurationsänderungen in einem Quellcode-Repository innerhalb deines Zielbereichs achten, daraufhin verschiedene Aktionen durchführen (z. B. Kompilierung, automatisierte Tests und Paketierung) und die Ergebnisse in deine Produktionsumgebung einbringen. Du willst keine CI-implementierten Aufgaben für Dinge wie Datenbank-Backups einbeziehen.

Wenn du nur ein Code-Repository hast, das von einer End-to-End-Pipeline bedient wird (z. B. ein Monolith, der in einer Monorepo gespeichert ist und direkt und in einem einzigen Satz von Aktivitäten in die Produktion deployt wird), dann ist deine Aufgabe hier einfach. Das Modell dafür ist in Abbildung 1-2 dargestellt.

Abbildung 1-2. Das einfachste Source-Control/Pipeline/Deployment-Modell, das du finden kannst

Obwohl dies genau unserem grundlegenden mentalen Modell entspricht, habe ich das in der Realität leider selten gesehen. Höchstwahrscheinlich müssen wir das mentale Modell viel umfassender umgestalten, um zu einem Modell zu gelangen, das deinen Umständen entspricht.

Die nächste einfach zu messende und unsere erste bedeutende mentale Umstellung ist eine Sammlung dieser End-to-End-Pipelines, eine pro Artefakt oder Repository (z. B. eine pro Microservice), von denen jede ihre eigene Arbeit erledigt und wiederum in der Produktion endet(Abbildung 1-3). Wenn du zum Beispiel Azure DevOps verwendest, ist es ganz einfach, diese zu erstellen.³

Abbildung 1-3. Das Modell der "multiplen End-to-End-Pipelines" ist ideal für Microservices

Diese ersten beiden Pipelineformen ähneln höchstwahrscheinlich dem, was du hast, aber ich gehe davon aus, dass deine Version dieses Bildes etwas komplizierter ist und einen weiteren Refactor erfordert, um in eine Reihe von Subpipelines aufgeteilt zu werden(Abbildung 1-4). Betrachten wir ein Beispiel, das drei dieser Subpipelines zeigt, die durchgängig zusammenpassen, um eine Änderung in die Produktion zu bringen.

Vielleicht wartet die erste Subpipeline auf Pushs zum Repository und führt Kompilierung, Paketierung sowie Unit- und Komponententests durch und veröffentlicht sie dann in einem Repository für binäre Artefakte. Vielleicht folgt darauf eine zweite, unabhängige Subpipeline, die das neu veröffentlichte Artefakt in einer oder mehreren Umgebungen zum Testen bereitstellt. Möglicherweise folgt eine dritte Subpipeline, die durch einen CAB-Prozess ausgelöst wird,⁴ wird die Änderung schließlich in die Produktion übertragen.

Abbildung 1-4. Das Modell "Pipeline aus mehreren Subpipelines", das mir häufig begegnet

Hoffentlich hast du deine Situation erkannt. Falls nicht, gibt es noch eine vierte große Pipeline-Variante, die wir in unserem letzten Schritt des mentalen Refactorings kennenlernen werden: das mehrstufige Fan-in, wie in Abbildung 1-5 dargestellt. Hier gibt es in der Regel einzelne Subpipelines für die erste Stufe, eine pro Repository, die dann in eine gemeinsame Subpipeline oder eine Reihe von Subpipelines übergehen, die die Änderung den Rest des Weges bis zur Produktion übernehmen.

Abbildung 1-5. Das mehrstufige "Fan-in-Pipeline"-Modell

Lokalisierung deiner Messpunkte

Auf findest du nicht nur vier Messgrößen, sondern auch vier Messpunkte. Jetzt wollen wir sie in unserem mentalen Modell verorten, wie auch immer deines aussehen mag. Wir haben uns bisher auf Pipelines konzentriert, weil sie in der Regel zwei dieser Punkte liefern: einen Commit-Zeitstempel und einen Deployment-Zeitstempel. Der dritte und vierte Instrumentierungspunkt sind die Zeitstempel, die erstellt werden, wenn eine Serviceverschlechterung erkannt und als "behoben" markiert wird. Wir können nun jeden dieser Punkte im Detail besprechen.

Zeitstempel der Übermittlung

Hier ergeben sich unweigerlich Feinheiten, wenn man die Arbeitsweise der Teams betrachtet. Verzweigen sie nach Merkmalen? Arbeiten sie mit Pull Requests? Haben sie eine Mischung aus verschiedenen Praktiken? Im Idealfall (wie es die Autoren von Accelerate vorschlagen) beginnt die Uhr zu ticken, sobald ein Änderungssatz eines Entwicklers als abgeschlossen gilt und committed wird, wo auch immer das sein mag. Wenn die Teams so verfahren, sei vorsichtig: Das Festhalten von Änderungen auf Zweigen verlängert nicht nur die Feedback-Zyklen, sondern erhöht auch den Aufwand und die Anforderungen an die Infrastruktur. (Auf diese Punkte gehe ich im nächsten Abschnitt ein.)

Aufgrund dieser Komplexität entscheiden sich einige dafür, das Auslösen einer Pipeline von einem Merge zu Main als stellvertretenden Triggerpunkt oder Commit-Zeitstempel zu verwenden. Ich verstehe, dass das wie ein Eingeständnis der Niederlage angesichts einer suboptimalen Praxis klingt,⁵ aber wenn du dich für einen Proxy-Trigger entscheidest, wirst du ein schlechtes Gewissen haben (weil du weißt, dass du dich nicht an die bewährte Methode hältst). Unabhängig davon, ob wir die zusätzliche Wartezeit mit einbeziehen oder nicht, werden die Messwerte zu vielen anderen Vorteilen für dich führen, selbst wenn du dir eine Pause gönnst und mit dem frühen Sampling beginnst, wenn der Code auf Main trifft. Sollten sich diese Proxies als Ursache für eine erhebliche Suboptimierung der Auslieferung herausstellen, hat Accelerate Empfehlungen für dich (z. B. trunkbasierte Entwicklung und Pair Programming),⁶ die sich auf deinen Commit-Zeitstempel auswirken, indem du den Zeitpunkt, an dem eine Änderung durchgeführt wird, als Startzeitpunkt für den Timer festlegst. Bis dahin wirst du die Vorteile der Metriken erkannt haben und sie besser erfassen wollen.

Zeitstempel des Einsatzes

Nachdem wir die Commit-Zeit aus dem Weg geräumt haben, wird es dich freuen zu hören, dass der "Stopp" der Uhr viel einfacher ist: Es ist der Zeitpunkt, an dem die Pipeline, die die endgültige Bereitstellung für die Produktion vornimmt, abgeschlossen ist. Gibt das denjenigen, die nachträglich manuelle Smoke-Tests durchführen, nicht eine Pause? Ja, aber auch das überlasse ich deinem Gewissen. Und wenn du diese letzte Aktivität wirklich einbeziehen willst, kannst du am Ende deiner Pipelines immer einen manuellen Prüfpunkt setzen, den die QA (oder wer auch immer die Verteilungen prüft) drückt, wenn sie sich davon überzeugt hat, dass die Verteilung erfolgreich war.

Komplexität durch mehrstufige und Fan-in-Pipelines

Mit diesen beiden Datenquellen kannst du die Informationen berechnen, die wir von unseren Pipelines benötigen, nämlich die Gesamtlaufzeit: die verstrichene Zeit zwischen dem Start und dem Stopp des Taktes. Wenn du eines der einfacheren Pipeline-Szenarien hast, die wir vorhin besprochen haben, also die, die sich nicht auffächern, dann ist das relativ einfach. Diejenigen mit einer oder mehreren End-to-End-Pipelines haben es am leichtesten von allen.⁷

Wenn du Pech hast und mehrere Subpipelines hast (wie wir in Abbildung 1-4 gesehen haben), musst du zusätzliche Daten für die Änderungssätze sammeln, die in einem "Start"-Zeitstempel und im "Deploy" zur Produktion enthalten waren. Mit diesen Daten kannst du die Gesamtzeit für jede einzelne Änderung berechnen.

Wenn du einen Fan-in-Entwurf verwendest (siehe Abbildung 1-5), ist diese Verarbeitung wahrscheinlich aufwendiger. Warum? Wie du in Abbildung 1-6 siehst, musst du wissen, woher die Änderungsnummer 264 stammt (Repo A, Repo B oder Repo C), damit du den "Start"-Zeitstempel für die Änderung ermitteln kannst. Wenn dein Deployment mehrere Änderungen zusammenfasst, musst du jede einzelne zurückverfolgen, um den "Startzeitpunkt" zu ermitteln.

Abbildung 1-6. Lokalisierung deiner Datenerfassungspunkte in der "Fan-in-Pipeline"-Modellvariante

Egal wie kompliziert deine Pipelines sind, du solltest immer nur die Builds zählen, die Service-Updates für die Nutzer bereitstellen. Stelle sicher, dass du nur diese misst.⁸

Bevor wir fortfahren, gibt es noch einen letzten Punkt zur Datenerfassung aus Pipelines: Welche Pipeline-Läufe sollen gezählt werden? Auch in diesem Punkt macht Accelerate keine genauen Angaben, aber es zählen nur die erfolgreichen Läufe. Wenn ein Build startet, aber bei der Kompilierung fehlschlägt, werden deine Vorlaufzeiten künstlich in eine positive Richtung verzerrt, weil du gerade einen wirklich schnellen Build in den Mix eingebaut hast. Wenn du die Dinge manipulieren willst (und der größte Vorteil der vier Kennzahlen ist, dass sie nicht manipulierbar sind, zumindest nicht meines Wissens nach), dann reiche einfach viele Builds ein, von denen du weißt, dass sie im Idealfall sehr schnell scheitern werden.

Überwachung von Dienstausfällen

Während es relativ einfach ist , die Messungen rund um unsere Pipelines genau zu bestimmen, ist die dritte und letzte Quelle von Rohdaten viel offener für Interpretationen.

Die Schwierigkeit besteht darin, einen "Fehler in der Produktion" zu definieren. Wenn es einen Fehler gibt, aber niemand ihn bemerkt, war er dann überhaupt vorhanden? Wann immer ich die vier Schlüsselkennzahlen verwendet habe, habe ich diese Frage verneint. Ich definiere "Produktionsfehler" als alles, was dazu führt, dass ein Kunde nicht in der Lage oder sogar nicht gewillt ist, die Arbeit, die er erledigen wollte, fortzusetzen. Kosmetische Defekte zählen nicht als Servicefehler, aber ein "funktionierendes System", das so langsam ist, dass es zu untypischen Benutzerabbrüchen führt, ist eindeutig ein Servicefehler. Das ist ein gewisses Maß an Urteilsvermögen, und das ist auch gut so: Wähle eine Definition, mit der du dich wohlfühlst, und sei ehrlich zu dir selbst, wenn du sie befolgst.

Jetzt musst du Serviceausfälle aufzeichnen, die unser dritter und letzter Instrumentierungspunkt sind, und zwar in der Regel mit einem "Änderungsausfall"-Ticket. Wenn du dieses Ticket öffnest, erhältst du einen Startzeitpunkt für eine andere Uhr; wenn du es schließt, erhältst du den entsprechenden Endzeitpunkt. Diese Start- und Endzeit sowie die Anzahl der Tickets sind alle weiteren Datenpunkte, die du brauchst. Ein Ticket sollte geschlossen werden, wenn der Dienst wiederhergestellt ist. Das muss nicht unbedingt mit der Behebung der Fehlerursache übereinstimmen; das ist in Ordnung. Wir reden hier über die Stabilität des Dienstes. Ein Rollback, damit du wieder online bist und deine Kunden bedienen kannst, ist hier akzeptabel.⁹

Aber was ist, wenn du nicht in der Produktion bist? Erstens: Hast du noch nicht versucht, auf kontinuierliche Bereitstellung umzustellen? Das solltest du wirklich tun. Aber zweitens ist diese Option nicht für jeden verfügbar. Sie ist suboptimal, aber du kannst die vier Schlüsselkennzahlen auch unter diesen Umständen nutzen. Dazu musst du deine "höchste Umgebung" definieren: die gemeinsame Umgebung, die der Produktion am nächsten ist und in die alle Teams liefern. Sie wird wahrscheinlich SIT (für Systemintegration), Pre-Prod oder Staging genannt. Das Wichtigste ist, dass du bei der Abnahme deiner Änderungen davon ausgehst, dass keine weitere Arbeit nötig ist, um deine Änderungen in die Produktion zu bringen.

Angesichts all dieser Überlegungen musst du diese "höchste Umgebung" genauso behandeln wie die Produktionsumgebung. Behandle die Tester und die kollaborierenden Teams als deine "Nutzer". Sie dürfen Fehler im Service definieren. Behandle die Testausfälle genauso ernst wie echte Ausfälle. Es ist zwar nicht perfekt, so zu tun, als wäre diese Umgebung die Produktionsumgebung, aber besser als nichts.

Erfassen und Berechnen

Systemmodellierer sagen, dass wir Paradigmen ändern, indem wir ein Modell des Systems erstellen, das uns außerhalb des Systems bringt und uns zwingt, das Ganze zu sehen.

Donella Meadows, Denken in Systemen¹⁰

Jetzt, wo du deine Definitionen hast,, kannst du mit der Erfassung und Berechnung beginnen. Es ist zwar wünschenswert, diesen Erfassungsprozess zu automatisieren, aber es ist auch völlig in Ordnung, ihn manuell durchzuführen.¹¹ Jedes Mal, wenn ich die vier Schlüsselkennzahlen eingeführt habe, habe ich damit begonnen, und zwar häufig nicht nur für die erste Basislinie. In ein paar Absätzen wirst du verstehen, warum es in Ordnung ist, die Daten manuell zu erfassen und zu berechnen.

Die Erfassung von Kennzahlen kann einfach oder komplex sein, je nachdem, wie deine Pipelines beschaffen sind. Unabhängig davon werden die vier wichtigsten Kennzahlen anhand von vier Datensätzen berechnet, die sich aus den vier Instrumentierungspunkten ergeben: Anzahl der erfolgreichen Änderungsimplementierungen, Gesamtzeit für die Ausführung der Pipeline(s) für jede Änderung, Anzahl der Änderungsfehlertickets und Dauer der offenen Änderungsfehlertickets. Diese erfassten Datensätze allein reichen nicht aus, um deine Kennzahlen zu erhalten; du musst sie noch berechnen:

Häufigkeit des Einsatzes

Es handelt sich um eine Häufigkeit, nicht um eine Anzahl, und deshalb brauchst du die Gesamtzahl der erfolgreichen Einsätze innerhalb eines bestimmten Zeitraums (ich habe festgestellt, dass ein Tag gut funktioniert). Wenn du mehrere Pipelines hast, egal ob du sie auffächerst oder nicht, musst du die Anzahl der Einsätze aller Pipelines zusammenzählen.

Mit diesen Daten, die täglich aufgezeichnet und summiert werden (erinnere dich an die "Nullsummen" für Tage, an denen keine Einsätze stattfinden), ist es ganz einfach, zu deiner ersten Hauptkennzahl zu gelangen. Wenn du mit der letzten Tageszahl oder der Zahl der letzten 24 Stunden arbeitest, gibt es (meiner Erfahrung nach) zu viele Schwankungen. Am besten funktioniert es, wenn du den Mittelwert über einen längeren Zeitraum anzeigst, z. B. über die letzten 31 Tage.

Vorlaufzeit für Änderungen

Dies ist die verstrichene Zeit für jede einzelne Änderung, die den Start auslöst. Sie kann schwanken, also gib nicht einfach die letzte Zahl vom letzten Einsatz an. Wenn du mehrere Pipelines hast (einschließlich Fan-in-Pipelines), ist diese Schwankung noch viel größer, weil manche Builds aufgrund von Blockierungen viel schneller laufen als andere. Du willst etwas Stabileres, das den allgemeinen Stand der Dinge widerspiegelt, und nicht den letzten Ausreißer. Deshalb nehme ich normalerweise jede einzelne Vorlaufzeitmessung und berechne den Mittelwert aller Messungen im Laufe eines Tages. Die zu meldende Zahl ist der Mittelwert aller Vorlaufzeitmessungen der letzten 31 Tage.¹²

Ausfallrate ändern

Dies ist der Anteil der gelösten Änderungsfehlertickets, d.h. die Anzahl der Einsätze, bei denen es zu Fehlern kam, im Verhältnis zur Gesamtzahl der Einsätze im selben Zeitraum. Wenn du zum Beispiel an einem Tag 36 Einsätze hattest und innerhalb desselben Tages 2 Änderungsfehler behoben hast, bedeutet das, dass deine Fehlerquote für diesen Tag 2/36 oder 5,55555556% betrug.

Um deine gemeldete Kennzahl zu erhalten, betrachte diese Rate über denselben Zeitraum: die letzten 31 Tage. Das heißt, du addierst die Anzahl der wiederhergestellten Ausfälle in den letzten 31 Tagen und teilst sie dann durch die Gesamtzahl der Einsätze im selben Zeitraum.

Du wirst feststellen, dass hier ein Vertrauensvorschuss gegeben ist. Wir gehen davon aus, dass es sich um unterschiedliche Ausfälle handelt und dass ein einzelner Ausfall durch einen einzelnen Einsatz verursacht wird. Und warum? Weil es meiner Erfahrung nach zu schwierig ist, Fehler auf einzelne Builds zurückzuführen, und weil diese beiden Annahmen in den allermeisten Fällen zutreffen, zumindest so sehr, dass sie den Verlust an Zuverlässigkeit wert sind. Wenn du in der Lage bist, in dieser Hinsicht schlauer zu sein, gratuliere ich dir!

Aufmerksame Beobachter werden auch feststellen, dass wir nur über gelöste Fehler sprechen. Warum berücksichtigen wir keine noch offenen Ausfälle? Weil wir bei allen vier Kennzahlen einheitlich vorgehen wollen und weil die Zeit bis zur Wiederherstellung des Dienstes nur behobene Ausfälle berücksichtigen kann.¹³ Wenn wir ungelöste Ausfälle für eine Sache nicht zählen können, wollen wir sie auch nicht für die andere zählen. Aber keine Sorge: Wir haben immer noch die Daten über offene Ausfälle und wir verstecken sie nicht, wie du in den folgenden Abschnitten sehen wirst.

Zeit zur Wiederherstellung des Dienstes

Das ist die Zeit, die ein Change-Failure-Ticket braucht, um von der Erstellung bis zur Schließung zu gelangen. Die Autoren von Accelerate nennen dies die mittlere Zeit bis zur Wiederherstellung des Dienstes, obwohl es in früheren State of DevOps-Berichten nur die Zeit bis zur Wiederherstellung war, und in der METRICS.md-Datei für das Four Keys-Projekt von Google ist es die mittlere Zeit bis zur Wiederherstellung. Ich habe sowohl den Mittelwert als auch den Median verwendet. Ersterer ist empfindlich gegenüber Ausreißern, und manchmal ist es genau das, was du sehen willst, wenn du lernst.

Sowohl der Mittelwert als auch der Median lassen sich leicht aus den Daten deiner Änderungsfehlertickets berechnen. In jedem Fall musst du deine Eingaben über einen Datenbereich auswählen. Ich verwende normalerweise die letzten 120 Tage. Nimm alle Fehlerbehebungszeiten, die in diesen Zeitraum fallen, berechne ihren Mittelwert und gib ihn für diese Kennzahl an.

Das birgt das Potenzial für einen weiteren Vertrauensvorschuss: Wenn du Änderungsfehler manuell meldest, ist es möglich, diese Zahlen zu verfälschen, indem du die Ticketöffnung über den unmittelbaren Zeitpunkt der Entdeckung hinauszögerst. Ehrlich gesagt, selbst wenn die Leute die besten Absichten haben, wird es zu Verzerrungen kommen. Dennoch erhältst du genügend Daten, um die Dinge im Auge zu behalten und Verbesserungen vorzunehmen.

Wie auch immer du deine Daten erhebst, die in diese Berechnungen einfließen, stelle sicher, dass alles in aller Öffentlichkeit geschieht. Ermutige deine Entwicklungsteams, sich über die vier Schlüsselkennzahlen zu informieren. Es sollte kein Geheimnis sein, dass ihr euch bemüht.

Zweitens: Stelle alle deine Rohdaten und Berechnungen sowie die berechneten Kopfzahlen zur Verfügung. Das wird später wichtig sein.

Drittens solltest du sicherstellen, dass die Definitionen, die du auf jede Kennzahl anwendest, und die Art und Weise, wie du mit diesen Definitionen umgehst, neben den Daten selbst verfügbar sind. Diese Transparenz sorgt für ein besseres Verständnis und erhöht das Engagement.¹⁴

Achte auf die Frage des Zugangs (Zugang zu Daten, Berechnungen und Visualisierungen), denn wenn deine vier Schlüsselkennzahlen nicht für alle zugänglich sind, verpasst du ihre größte Stärke.

Anzeigen und Verstehen

[Wie also wechselt man Paradigmen? ... Man weist immer wieder auf die Anomalien und Fehler des alten Paradigmas hin. Du sprichst und handelst laut und selbstbewusst nach dem neuen Paradigma.

Donella Meadows, Denken in Systemen¹⁵

Wann immer ich die vier Schlüsselkennzahlen eingesetzt habe, habe ich in der Regel mit einem Minimal Viable Dashboard (MVD) begonnen,¹⁶ was ein schöner Name für eine Wikiseite ist, die folgendes enthält:

• Die aktuell berechneten Werte für jede der vier Schlüsselmetriken

• Die Definitionen der einzelnen Kennzahlen und die Zeiträume, über die wir sie berechnen

• Die historischen Werte der Daten

Ich kennzeichne auch die Datenquellen, damit sich jeder mit ihnen beschäftigen kann.

Zielpublikum

Kennzahlen erzählen, wie alle Statistiken, eine Geschichte, und Geschichten haben ein Publikum. Wer ist die Zielgruppe für die vier Schlüsselkennzahlen? In erster Linie die Teams, die die Software bereitstellen, also die Leute, die die Änderungen vornehmen, wenn sie eine Verbesserung der Kennzahlen erreichen wollen.

Deshalb solltest du sicherstellen, dass du die Dinge, egal wo und wie du sie ausstellst, an einem Ort platzierst, der für diese Personen und Gruppen leicht zugänglich ist. Das "leicht" ist wichtig. Es muss ganz einfach sein, die Kennzahlen zu sehen und sie aufzuschlüsseln, um mehr herauszufinden, in der Regel die Datenpunkte, die sich auf die eigenen Dienste beziehen.

Es gibt noch andere Zielgruppen für die vier Schlüsselkennzahlen, aber diese sind zweitrangig. Eine sekundäre Zielgruppe könnte das Senior Management oder die Geschäftsleitung sein. Für sie ist es in Ordnung, die Kennzahlen zu sehen, aber die Kennzahlen müssen aufgerollt und schreibgeschützt sein. Wenn die Geschäftsleitung mehr Details wissen will, wird sie sich an die Teams wenden, um sie zu erfahren, und das ist genau das, was du erreichen willst.

Im Idealfall kannst du, sobald du deine MVD eingerichtet hast, mit der Automatisierung der Erfassung und Berechnung beginnen. Während ich dies schreibe, gibt es verschiedene Möglichkeiten. Vielleicht verwendest du Four Keys von Google, Metrik von Thoughtworks oder verschiedene Erweiterungen für Plattformen, wie Azure DevOps. Ich habe keine von ihnen benutzt, und obwohl ich sicher bin, dass sie alle für unseren Zweck geeignet sind, werde ich die Vorteile meiner Erfahrung mit der manuellen Erstellung eines solchen Systems mit dir teilen, in der Hoffnung, dass es dir bei der Entscheidung hilft, ob du etwas von der Stange benutzen oder die Zeit und den Aufwand investieren willst, um etwas Individuelles zu entwickeln.

Visualisierung

Ein hausgemachter Versuch führte zum umfangreichsten Dashboard, mit dem ich je gearbeitet habe. Es wurde mit Microsoft PowerBI erstellt (weil der Kunde mit Azure DevOps arbeitet). Nachdem wir uns mit Daten und Zeiten herumgeschlagen hatten, erfassten wir unsere Rohdaten, führten unsere Berechnungen durch und machten uns daran, unsere Diagramme und andere visuelle Anzeigeelemente zu erstellen.

Häufigkeit des Einsatzes

Für diese Daten wählten wir ein Balkendiagramm (Abbildung 1-7) mit den Daten auf der x-Achse und der Anzahl der Einsätze auf der y-Achse. Jeder Balken steht für die Gesamtzahl des jeweiligen Tages, und wir haben die wichtigsten Statistiken in einer Zusammenfassung zusammengefasst.

Abbildung 1-7. Einsatzhäufigkeit; das untere rechte Kästchen zeigt eine "DORA Elite" (DevOps Research and Assessment) Stufe der Softwarebereitstellungsleistung an

Die durchschnittlichen Einsätze pro Tag zeigen die Schlüsselkennzahl für die Einsatzhäufigkeit, und wir haben unsere Schlüsselkennzahlen grün hervorgehoben, um "Elite" auf der Leistungsskala von Accelerate Elite-Low Software Delivery zu kennzeichnen.¹⁷ Für zusätzliche Transparenz haben wir die Einsätze für den aktuellen Tag und die Gesamtzahl der Einsätze über den dargestellten Zeitraum (31 Tage) angezeigt. Schließlich haben wir den Mittelwert, den 95. und den Gesamttrend der Daten als gepunktete Linien in das Diagramm eingezeichnet.

Vorlaufzeit für Änderungen

Das Balkendiagramm in Abbildung 1-8 zeigt unsere Vorlaufzeit für Änderungen, wieder mit Daten auf der x-Achse und jetzt mit dem Mittelwert der Vorlaufzeit für den jeweiligen Tag in den Balken auf der y-Achse.

Abbildung 1-8. Vorlaufzeit für Änderungen; das untere rechte Kästchen zeigt ein "DORA High"-Niveau der Software-Lieferleistung auf der Bewertungsskala Accelerate an

Wie zuvor haben wir die Schlüsselkennzahl für den Bildschirm hervorgehoben, die hier ein Mittelwert der Durchlaufzeit über den angezeigten Zeitraum war, und unsere Schlüsselkennzahlen hervorgehoben, um "Niedrig" auf der Leistungsskala Elite-Niedrig anzuzeigen. Wir fanden es auch nützlich, unsere längste individuelle Vorlaufzeit zu markieren (siehe Kasten unten links).¹⁸

Wir stellten fest, dass wir uns immer wieder fragten: "Haben wir an diesem Tag viele Einsätze gemacht?" Anstatt weitere Trendlinien hinzuzufügen, haben wir die Anzahl der Einsätze (in hellgrau) zusammen mit den Vorlaufzeiten schattenhaft aufgezeichnet.

Ausfallrate ändern

Abbildung 1-9 zeigt ein weiteres Balkendiagramm für die Ausfallrate von Änderungen, aber diese Kennzahl sieht ganz anders aus. Wie du auf der Y-Achse sehen kannst, hatten wir in der Regel entweder keine Ausfälle oder einen einzigen Ausfall innerhalb eines bestimmten 24-Stunden-Zeitraums.¹⁹ Es war also ganz klar, wann wir Probleme hatten.

Abbildung 1-9. Änderungsfehlerquote; das untere rechte Kästchen zeigt eine "DORA Elite"-Stufe der Softwarelieferleistung auf der Accelerate-Bewertungsskala an

Alles, was darüber hinausgeht, ist Kontext. Durch das Kopieren der Anzahl der Einsätze können wir schnell die Frage beantworten: "War dies vielleicht auf eine hohe Einsatzaktivität an diesem Tag zurückzuführen?"

Zum Schluss siehst du wie üblich unten unsere wichtigste Kennzahl: die Anzahl der Ausfälle als Prozentsatz der Gesamteinsätze in diesem Zeitraum. Daneben gibt es noch einige andere wichtige Statistiken: die Anzahl der aktiven Ausfälle und die Gesamtzahl der Einsätze in dem angegebenen Zeitraum.

Zeit zur Wiederherstellung des Dienstes

Für die Darstellung der letzten Kennzahl, Zeit bis zur Wiederherstellung des Dienstes, benötigten wir die meiste Zeit, um uns mit ihr vertraut zu machen - aber sobald wir unsere Einsatzhäufigkeit und Vorlaufzeiten verstanden und stabilisiert hatten, wurde diese Kennzahl unser Hauptaugenmerk.²⁰ Auch hier haben wir ein Zeitreihen-Balkendiagramm(Abbildung 1-10), aber jetzt mit Werten, die über einen längeren Zeitraum als die anderen aufgetragen wurden (120 Tage, um einen besseren Kontext zu schaffen), damit wir unsere Verbesserungen mit einer Kennzahl vergleichen können, die eigentlich viel weniger Datenpunkte haben sollte. Auch hier haben wir die Vorlaufzeit für Änderungen mit aufgetragen, um einen Kontext zu schaffen.

Abbildung 1-10. Zeit bis zur Wiederherstellung des Dienstes; das untere linke Kästchen zeigt an, dass es keine offenen Änderungsfehler gibt - keine DORA-Kennzahl, aber wichtig zu wissen - und das untere rechte Kästchen zeigt ein "DORA High"-Niveau der Softwarelieferleistung an

Unten rechts siehst du wie üblich unsere wichtigste Kennzahl: den Median aller Wiederherstellungszeiten für wiederhergestellte Ausfälle innerhalb des angegebenen Zeitraums. Daneben gibt es noch weitere wichtige Statistiken: die Anzahl der aktiven Ausfälle und die Gesamtzahl der wiederhergestellten Ausfälle in dem angegebenen Zeitraum.

Titelseite

Damit waren wir noch nicht fertig. Unser PowerBI-Bericht enthielt auch eine Titelseite mit den "Vier Schlüsselkennzahlen", die die wichtigsten Kennzahlen jeder einzelnen Statistikseite sowie die Diagramme zur Einsatzhäufigkeit und Vorlaufzeit enthielten. Das Ziel war es, den Leuten einen schnellen und genauen Überblick über die Statistiken in Echtzeit zu geben. Wenn sich unser Schwerpunkt änderte, hätten wir auch andere Diagramme zeigen können.

Wie ich bereits angedeutet habe, sind wir jetzt in der Lage, das wahre Potenzial der vier Schlüsselkennzahlen zu erschließen. Es ist von größter Bedeutung, dass die Teams Zugang zu diesen Kennzahlen sowie zu dem Modell und dem System, das ihnen zugrunde liegt, haben und diese auch verstehen, wenn du ihre Vorteile nutzen willst. Nur so können sie die Software, die du bereitstellst, diskutieren, verstehen, besitzen und verbessern.

Diskussionen und Verständigung

Der Prozess des Paradigmenwechsels ist weder physisch noch teuer oder gar langsam. Bei einer einzelnen Person kann er in einer Millisekunde stattfinden. Alles, was es braucht, ist ein Klick im Kopf, ein Fallen der Schuppen von den Augen, eine neue Art zu sehen.

Donella Meadows, Denken in Systemen²¹

Wie sind wir zu diesen Visualisierungen, zusätzlichen Details und bestimmten Zeiträumen gekommen? Wir haben sie immer wieder ergänzt und verbessert, je nach Bedarf.

Jede Woche besprachen wir gemeinsam anstehende Spikes und architektonische Entscheidungssätze (ADRs)²² und sahen uns die vier Schlüsselkennzahlen an. Anfangs ging es in den Gesprächen darum, was die einzelnen Kennzahlen bedeuten. In den darauffolgenden Wochen ging es darum, warum die Zahlen so waren, wie sie waren (z. B. ob die Zahlen zu hoch oder zu niedrig waren, ob Daten fehlten usw.), und dann darum, wie sie verbessert werden konnten. Langsam aber sicher gewöhnten sich die Teammitglieder an das mentale Modell der vier Schlüsselkennzahlen. Die Möglichkeit für die Teams, ihre Daten in Echtzeit selbst zu verwalten und nur die Daten ihrer Pipelines einzusehen (beides wurde durch die PowerBI-Dashboards erleichtert), war eine große Hilfe. Das Gleiche gilt für das Hinzufügen von Trendlinien, die wir kurz darauf durch die Möglichkeit ergänzt haben, längere Zeiträume als die standardmäßigen 31 Tage anzuzeigen.

Ich war erstaunt über den Wert dieser konzentrierten, aufgeklärten und funktionsübergreifenden Diskussionen. Als Architekt hätte ich diese Probleme und Fragen früher allein erkennen, verstehen, analysieren und beheben müssen. Jetzt waren es die Teams, die die Lösungen selbst initiierten und vorantrieben.

Eigentümerschaft und Verbesserung

Wenn Teams anfangen, Verantwortung zu übernehmen,, erlebe ich immer wieder Folgendes. Zuerst kommen die einfachsten Anfragen, die zur Modernisierung von Prozessen und Arbeitsweisen: "Können wir den Rhythmus der Veröffentlichungen ändern?" Als nächstes beginnen die Teams, sich mehr um die Qualität zu kümmern: "Lasst uns Tests nach links ziehen" und "Lasst uns mehr Automatisierung einbauen".²³ Dann kommen die Forderungen nach einer Änderung der Teamzusammensetzung: "Können wir zu funktionsübergreifenden Teams (oder zu Teams, die sich an den Arbeitsabläufen orientieren) wechseln?"

Es gibt immer Kompromisse, Misserfolge und Lektionen zu lernen, aber der Wandel wird sich von selbst vollziehen. Du wirst feststellen, dass du deinen Fokus und deine Lösungen änderst und anpasst, wenn du dich mehr auf die Vorteile einer ganzheitlichen Sichtweise konzentrierst und diese besser verstehst.

All diese Änderungen landen schnell an einem Ort: Sie offenbaren architektonische Probleme. Vielleicht sind diese Probleme schon in den Entwürfen auf dem Whiteboard enthalten. Vielleicht war das Whiteboard in Ordnung, aber die Umsetzung, die in der Produktion gelandet ist, war es nicht. In jedem Fall gibt es Dinge, die du lösen musst. Dazu gehören z. B. eine Kopplung, die nicht so locker ist, wie du dachtest; Domänengrenzen, die nicht so klar sind, wie sie anfangs schienen; Frameworks, die den Teams im Weg stehen, anstatt ihnen zu helfen; Module und Infrastruktur, die vielleicht nicht so einfach zu testen sind, wie du gehofft hattest; oder Microservices, die bei echtem Verkehr nicht zu beobachten sind. Das sind Probleme, mit denen du als verantwortlicher Architekt normalerweise umgehen musst.

Fazit

Jetzt stehst du vor einer Wahl. Du könntest weiterhin einen Alleingang wagen, die Hände an der Pinne lassen und das architektonische Schiff nach bestem Wissen und Gewissen allein steuern. Oder du kannst das Aufblühen deines Teams nutzen. Du könntest deine Hände von der Pinne nehmen, vielleicht zunächst schrittweise, und die Gespräche und die Motivation nutzen, die die vier Schlüsselkennzahlen freisetzen, um euch langsam auf euer gemeinsames Ziel zuzubewegen: eine besser testbare, entkoppelte, fehlertolerante, cloud-native, lauffähige und beobachtbare Architektur.

Das macht die vier Schlüsselmetriken zu den wertvollsten Architekturmetriken, die es gibt. Ich hoffe, dass du sie zusammen mit deinen Partnern nutzen wirst, um die beste Architektur zu entwickeln, die du je gesehen hast.

¹ Donella Meadows, Thinking in Systems: A Primer, Hrsg. Diana Wright (Chelsea Green Publishing, 2008), S. 162.

² Das muss nicht unbedingt ein Code-Fix sein. Wir denken hier an die Wiederherstellung des Dienstes, also ist so etwas wie ein automatischer Failover völlig in Ordnung, um das Ticken der Uhr zu stoppen.

³ Genau genommen ist es das Modell, von dem Microsoft möchte, dass du es übernimmst.

⁴ CAB steht für "Change-Advisory Board". Das berühmteste Beispiel ist die Gruppe, die sich regelmäßig trifft, um die Freigabe von Code und Konfiguration im Buchklassiker The Phoenix Project (IT Revolution Press, 2018) von Gene Kim, Kevin Behr und George Spafford zu genehmigen.

⁵ Vor allem, wenn du langlebige Zweige oder nicht enden wollende Pull-Requests hast, aber ich wette, du kennst das sowieso, und es ist auch nicht schwer, sie isoliert zu quantifizieren.

⁶ In der Dokumentation findest du alles, was du über trunk-basierte Entwicklung wissen willst. Unter Extreme Programming findest du die ursprüngliche Definition von Pair Programming.

⁷ Wenn du jetzt denkst, dass mehrere unabhängige Pipelines - eine pro Artefakt - eine gute Idee sind, dann gratuliere ich dir: Du hast dich an einen der wichtigsten Grundsätze von Microservices erinnert - die unabhängige Bereitstellungsfähigkeit. Wenn du dich jetzt nach einem Monolithen sehnst, dann erinnere dich an die anderen Vorteile von Microservices, von denen wir einige am Ende dieses Kapitels erläutern werden.

⁸ Manchmal stellt sich die Frage: "Was ist mit den Infra-Bauten?" Ich habe gesehen, dass diese in den Berechnungen der "vier wichtigsten Kennzahlen" enthalten sind, aber ich würde mich nicht aufregen, wenn sie nicht enthalten wären. Und was ist mit Pipelines, die durch die Zeit und nicht durch Veränderungen ausgelöst werden? Zähle sie nicht. Sie führen nicht zu einem Einsatz, weil sich nichts geändert hat.

⁹ Wiederum werden einige darauf hinweisen, dass die Öffnungszeit eines Tickets nicht mit dem Zeitpunkt übereinstimmt, an dem die Störung zum ersten Mal auftritt. Das ist richtig. Vielleicht möchtest du deine Überwachung an die Erstellung dieser Tickets koppeln, um dies zu umgehen. Wenn du die Mittel dazu hast, herzlichen Glückwunsch: Du befindest dich wahrscheinlich in der "Feinabstimmung" der Einführung von vier Schlüsselkennzahlen. Die meisten können, zumindest am Anfang, von dieser Genauigkeit nur träumen, und deshalb reicht es aus, wenn du mit manuellen Tickets beginnst.

¹⁰ Meadows, S. 163.

¹¹ Sei ehrlich zu dir selbst: Sammle alle Builds, die du brauchst, und wähle keine aus. Versuche auch bei deinen Zahlen so genau wie möglich zu sein, und wenn du rätst, schätze den Grad deiner Genauigkeit.

¹² Erinnere dich! Wenn du einen Durchschnitt ermittelst, kann das zu Problemen führen, also vermeide es am besten. Wir bilden tägliche Gesamtwerte, damit wir eine schöne Grafik hinter unseren Kennzahlen haben, zu der wir später noch kommen.

¹³ Denn ungelöste Fehler haben leider keine "gelösten" Zeitstempel.

¹⁴ Vielleicht bekommst du sogar ein paar Fehlerberichte zu deinen Berechnungen, wenn du sie falsch gemacht hast - einige meiner besten Erkenntnisse zu den vier Schlüsselmetriken habe ich auf diese Weise gewonnen.

¹⁵ Meadows, S. 163.

¹⁶ Ein Lob an Matthew Skelton und Manuel Pais für ihre Idee der "Minimal Viable Platform", die uns zu diesem Artikel inspiriert hat.

¹⁷ Siehe die Abbildungen 2-2 und 2-3 in Accelerate sowie aktuellere Tabellen im aktuellen DORA State of DevOps Report.

¹⁸ Wir hatten einen blockierten Bau. Das ist nicht schwer zu erkennen. Wir haben auch das Wort "durchschnittlich" statt "mittelmäßig" verwendet, um es verständlicher zu machen.

¹⁹ Manchmal sahen wir mehrere Ausfälle, aber das war sehr ungewöhnlich.

²⁰ Aus Erfahrung kann ich wetten, dass dies auch dein Fokus sein wird.

²¹ Meadows, S. 163.

²² Der Begriff ADR wurde erstmals von Michael Nygard geprägt.

²³ Sehr zur Freude der QAs und des Betriebs. Ich habe häufig erlebt, dass QAs die vier Schlüsselkennzahlen nutzen, um Veränderungen voranzutreiben, genauso wie ich es als Architekt getan habe.