Mit welchen Methoden kann der ROI für DevOps gemessen werden?

DevOps ist komplex und beinhaltet viele nicht deterministische Aspekte wie Kultur und Prozess.
Was sind einige Möglichkeiten, um DevOps-Initiativen für den Erfolg zu messen?
Wie beweisen Sie einem Unternehmen, dass die Investition, die es getätigt hat, echte Dollars zurückbringt (oder spart)?

Gute Frage! Die meisten von uns wissen, dass die Investition in DevOps-Praktiken aus unzähligen Gründen sehr lohnenswert ist. Wir begründen DevOps jedoch nicht oft nur mit dem Einfluss auf das Endergebnis.

Hinweis : Dies ist so etwas wie eine mit einer Meinung versehene Frage, und meine Antwort ist ebenfalls mit einer Meinung versehen.

Tensibai schlug mit Bedacht vor, die richtigen Metriken zu finden, und verwendete Time-to-Market als Beispiel. Dies ist ein großartiger Ansatz.

Als Alternative habe ich mit Bohnenzählern die Erfahrung gemacht, dass sie nicht unbedingt das Gesamtbild kennen müssen oder wollen, sondern nur den Nachweis der steuerlichen Verantwortung. Sie wollen einen Trend in die richtige Richtung sehen.

Hier sind nur ein paar steuerliche Gewinne:

• Berechnen Sie die Server-Kosten, die durch die Nutzung der automatischen Skalierung in der Cloud eingespart werden
• Extrapolieren Sie für einkommensgenerierende Standorte die Ausfallkosten pro Minute und zeigen Sie dann Verbesserungen bei MTTI und MTTR auf
• Schätzen Sie für einkommensschaffende Standorte die Kosten pro Minute, die durch die Nutzung hochverfügbarer Architekturen auf der Grundlage früherer Vorfälle eingespart werden
• Wenn Sie Ihre Build- und Bereitstellungs-Pipeline verbessert haben, zeigen Sie, dass Sie Regressionen und Fehler in der Produktion, die durch bereits nachverfolgte Fehler verursacht werden, verringert haben
• Wenn Sie Verbesserungen an den Entwicklertestumgebungen oder sogar an den Tools und der Konfiguration auf Entwickler-Laptops vorgenommen haben, überprüfen Sie die Commit-Historien, um festzustellen, ob neue Entwickler ihre ersten Beiträge eher nach dem Beitritt leisten
• Führen Sie einen vollständigen Kostenvergleich zwischen Cloud und On-Premem durch, ähnlich wie kürzlich bei Gitlab , um Ihre Infrastrukturausgaben zu rechtfertigen (auch bekannt als Einsparungen!).

Oft reicht es aus, zu zeigen, dass Sie geldbewusst sind und ein paar klare Siege haben. Ich habe sicherlich einige offensichtliche Beispiele übersehen. Fühlen Sie sich frei, Kommentare unten hinzuzufügen.

Die Schlüsselmetrik für eine DevOps-Pipeline ist die Zykluszeit (auch als Vorlaufzeit bezeichnet ). Dies ist die Zeit, die für eine Änderung benötigt wird (oder eine Änderungsanforderung, die den gesamten Weg bis zum Beginn der Idee verfolgt). Die beste Illustration dieses mir bekannten Konzepts stammt aus dem Buch "The Goal", in dem es um die Herstellung geht.

Die Bereitstellungshäufigkeit ist ebenfalls hilfreich. Wir möchten, dass Bereitstellungen in einer DevOps-Pipeline häufig sind. Es gibt keine magische Messung "1 Tag ist gut, 2 Tage sind schlecht". Dies erfordert einen historischen Kontext zu Ihrem Projekt, um aussagekräftig zu sein.

Bereitstellungsgröße : Gemessen daran, wie Ihre Entwickler die Arbeit messen - User Stories, Story Points, Quatloos, was auch immer. Auch hier möchten Sie Trends im Zeitverlauf sehen, nicht den absoluten Wert.

Zwischen Frequenz und Größe gibt es eine Geschichte zu erzählen. Werden unsere Veröffentlichungen seltener und umfangreicher? Warum? Werden sie kleiner und häufiger? Nochmals, warum?

Wenn wir erklären, ob der Frequenz- / Größentrend gut ist, benötigen wir auch den Prozentsatz der fehlgeschlagenen Bereitstellungen . Wenn Sie das "Warum" in diesen drei Metriken aufdecken, erfahren Sie viel über den Zustand des Projekts.

Mein persönlicher Favorit ist Time for a Trivial Deploy , obwohl es sich um eine Eitelkeitsmetrik handelt . Wenn Sie die kleinstmögliche Sache gefunden haben, die es wert ist, die gesamte Site über ... vielleicht einen Tippfehler im Namen des CEO ... erneut bereitzustellen, wie schnell könnten Sie von einem Paniktelefonanruf zu einer bereitgestellten Site wechseln? Ich sage "Eitelkeit", weil es wirklich nicht so aussagekräftig ist, wie in den anderen oben genannten Metriken beschrieben, aber ich fühle mich gut, wenn mir der Wert gefällt.

Wenn wir uns der Überwachung widmen, gibt es eine Reihe verschiedener Dinge, die wir nachverfolgen können ... von allumfassenden Dingen wie " Uptime " bis hin zu wirklich einfachen Dingen wie der Zeit, die für die Wiederherstellung von benutzerdefiniertem HTML in einem Anforderungs-Antwort-Zyklus aufgewendet wurde ... Diese sind jedoch nicht spezifisch für die Einrichtung einer DevOps-Kultur.

Diese sind nicht direkt an Dollars gebunden. Dazu ist mehr Wissen über Ihre Organisation erforderlich, als ich in einem Forum wie diesem anbieten kann. Aber sie sind der Schlüssel zu BEGINN, um diese Frage zu beantworten. Sobald Sie wissen, dass Sie Ihre Arbeit regelmäßig als Nicht-Ereignis in die Produktion freigeben können, können Sie feststellen, wie viel Aufwand Sie zuvor verschwendet haben. Wie das Buch "The Goal" lehrt (über die Herstellung von Pipelines - es ist relevant), kann die Optimierung vor Ort so aussehen, als ob Sie Geld sparen, aber letztendlich schafft es nur einen Wert, der im Inventar gebunden ist (nicht implementierte Funktionen).

Abgesehen von diesen Ratschlägen sollten Sie sich den State Of DevOps-Bericht der letzten Jahre ansehen . Dies ist voll von Messungen an realen Projekten, die Sie emulieren könnten.

Kapitän offensichtlich: durch Verkürzung der Time-to-Market und Mängel bei Releases.

Um auf diesen einen Liner zu verweisen, ist die übliche Falle ein Organisationswechsel ohne Bezug.

Das Eingehen einer Kultur- oder Organisationsänderung ist mit einigen Kosten für die Schulung und Einführung der Mitarbeiter in diese neue Methode verbunden. Dies ist mit Schulungskosten verbunden, bedeutet jedoch auch einen Produktivitätsverlust, da die Mitarbeiter in einer Schulungssitzung nichts produzieren. Dies ist der Investitionsteil des kulturellen Wandels.

Um einen ROI zu messen, müssen Sie zuerst einige relevante Metriken finden, die verbessert werden sollten (verstehen Sie teure, entweder teure oder Quelle des Gewinnverlusts). Dies kann eine kürzere Markteinführungszeit, weniger Patches nach jeder Veröffentlichung und eine bessere Kundenbindung in Ihrem Produkt sein. Relevante Metriken hängen stark von Ihren Produkten ab.

Das Messen eines ROI (wie schnell Sie die Schulungskosten gedeckt haben) bedeutet, dass Sie eine tatsächliche Entwicklung dieser Metriken darstellen können. Bevor Sie Änderungen vornehmen, müssen Sie diese Metriken definiert und objektiv gemessen haben.
Sobald Sie eine echte Entwicklung vor sich haben, können Sie feststellen, ob Sie etwas auf eine Weise verbessert haben, die die Schulungskosten gedeckt und rentabler geworden ist als zuvor.

Die übliche Gefahr besteht darin, die Änderung in Angriff zu nehmen, bevor Sie Metriken definiert haben, und somit den ROI anhand eines Gefühls und nicht anhand von Fakten zu bewerten.

Produktivität kann eine Metrik sein, aber ihre Messung ist in der Regel sehr schwierig und sollte für diese Art von Studie keine erstklassige Metrik sein.

Spät zum Spiel hier, aber ich dachte, ich würde mitmachen.

Sie können nicht verwalten, was Sie nicht messen. Für den Anfang sind hier die wichtigsten Kennzahlen, die Entwickler-Teams für die Reaktion auf Vorfälle verfolgen sollten:

• Uptime% : Insgesamt% der verfügbaren Zeit = [Gesamtzeit - Ausfallzeit] / [Gesamtzeit]
• MTTR : mittlere Zeit bis zur Lösung = [Ausfallzeit] / [# Vorfälle]
• MTTA : mittlere Bestätigungszeit = [Gesamtbestätigungszeit] / [Anzahl der Vorfälle]
• MTBF : mittlere Zeit zwischen Ausfällen = [Gesamtzeit - Ausfallzeit] / [Anzahl der Vorfälle]

Mit diesen Metriken können Sie den Zustand Ihrer Vorgänge auf höchster Ebene überprüfen und herausfinden, wo Sie sich weiter vertiefen müssen.

Schauen Sie sich hier die Whiteboard-Animation an, um einen genaueren Einblick in das Thema zu erhalten.

Sobald Sie Ihre Messdaten kennen, können Sie sie mit den Kosten für Ausfallzeiten vergleichen . Von dort aus können Sie den ROI Ihres Teams ausbauen und einige quantitative Kennzahlen für eine kontinuierliche Verbesserung festlegen.