Herausforderung für Bereitstellungsmetriken vor DevOps

TL; DR, wie beweisen Sie, dass Entwickler, insbesondere die Bereitstellungsautomatisierung, die Änderungsfehlerraten verbessern?

Wir alle versuchen, Metriken zu "Bereitstellungsfehlern" mit aktuellen (meist manuellen) Mitteln zu erfassen . Leider kommt es selten zu einem "Misserfolg", oder? Denn wenn etwas schief geht, kommt das Team zusammen (normalerweise mit Heldentaten), um das Problem zu beheben (normalerweise Berechtigungen, verpasste Konfigurationen, Sie kennen die Übung). Also ... wenn wir fragen, wie der Einsatz verlaufen ist, lautet die Antwort "es hat funktioniert".

Aber intuitiv wissen wir alle, dass das nicht gut ist. Der Devop-Bericht 2017 besagt, dass es eine " Änderungsfehlerrate " von 31-45% gibt. Während dies intuitiv richtig klingt, werden sie als Vorfälle verfolgt? Nein, nein. Weil sie ziemlich schnell repariert werden, normalerweise während der Validierung. Es ist viel seltener, eine Bereitstellung tatsächlich zurückzusetzen.

Es erfordert also Disziplin, um die Ausfallraten genau zu melden. Wir sind nicht motiviert, so zu berichten, weil wir wollen, dass die Dinge funktionieren, und wir tun, was nötig ist, um dies zu erreichen.

Wie können Sie also nachweisen, dass Entwickler, insbesondere die Bereitstellungsautomatisierung, die Änderungsfehlerraten verbessern?

(PS hat versucht, dies mit "# devops-Capability-Model" zu kennzeichnen)

Eine Technik, die wir in der Vergangenheit in ähnlichen Situationen angewendet haben, besteht darin, ein "Management-Engagement" zu erreichen, das jedem Teammitglied diese Regeln auferlegt:

1. Der Zugriff auf Aktualisierungen der Zielbereitstellungsbereiche (dh der Produktion) ist auf ausgewählte automatisierte Systeme beschränkt, die über geeignete Prüfpfade (= Protokollierung) für alle Arten von Aktualisierungen der von ihnen verwalteten Bereiche verfügen.

2. Manuelle Aktualisierungen der Zielbereitstellungsbereiche, aus welchen Gründen auch immer, sind von den typischen Teammitgliedern (Benutzer-IDs), die diese Aktualisierungen früher ausführen konnten (autorisiert), nicht mehr zulässig. Stattdessen werden NEUE (zusätzliche) Benutzer-IDs erstellt, die über alle erforderlichen Berechtigungen verfügen, um solche manuellen Aktualisierungen bei Bedarf (noch) durchzuführen. Um diese neuen Benutzer-IDs tatsächlich verwenden zu können (= eine Anmeldung mit ihnen durchführen), muss das Teammitglied, das eine Anmeldung mit einer solchen neuen Benutzer-ID durchführen möchte, "einige" zusätzliche Schritte ausführen, um Zugriff auf das Kennwort für zu erhalten solche neue Benutzer-ID. Im Idealfall wird dieser zusätzliche Schritt auch automatisiert (verwenden Sie Ihre eigene Vorstellung davon, wie er aussehen sollte), aber wenn etwas anderes fehlschlägt: Wenden Sie sich einfach an den Gate-Keeper (= E-Mail, Anruf usw.), und geben Sie an, welcher Kennwort erforderlich ist repariert werden "

3. Es ist keine leichte Aufgabe, einen solchen Torhüter in Position zu bringen. Und der größte Widerstand wird von ... den Teammitgliedern kommen (aus allen möglichen Gründen). Eine Variation dieser neuen Benutzer-IDs (wie im vorherigen Schritt) besteht darin, dass jedes Teammitglied eine zusätzliche Benutzer-ID erhält (mit dem Kennwort, das sie selbst festlegen), aber mit einer zusätzlichen Zeichenfolge versehen ist: Sie dürfen nur eine ausführen Melden Sie sich mit dieser (zusätzlichen) Benutzer-ID an, wenn sie tatsächlich einen guten Grund dafür haben. Und jedes Mal, wenn sie eine solche Anmeldung durchführen, müssen sie eine Art Bericht darüber einreichen, "welches Problem sie behoben haben" (ähnlich wie bei Ihrer Frage).

Wenn diese Verfahren vorhanden sind, müssen Sie nur noch regelmäßig jeden dieser Berichte / Gründe überprüfen, warum eine solche spezielle Benutzer-ID verwendet werden musste, und die Frage stellen: " Gibt es etwas, das getan werden kann, um dies weiter zu automatisieren?" die Notwendigkeit eines solchen speziellen Logins weiter reduzieren? ".

Update :

Zitat aus Ihrem zusätzlichen Kommentar unter dieser Antwort:

Ich denke, das Hinzufügen künstlicher Barrieren zur Behebung eines Bereitstellungsproblems ist kontraproduktiv.

Es stimmt, es fügt eine zusätzliche Barriere hinzu, aber ich bin nicht überzeugt, dass es "künstlich" ist. Denn dies ist meines Wissens die einzige Möglichkeit, sich der Dinge bewusst zu werden, die diese Teammitglieder Ihnen sonst aus folgenden Gründen niemals sagen werden:

• Berufssicherheit.
• schlechte Dinge / Praktiken, die sie lieber versteckt halten.
• Macht wollen sie nicht verlieren.

Der Devop-Bericht 2017 besagt, dass es eine "Änderungsfehlerrate" von 31-45% gibt. Während das intuitiv richtig klingt, werden sie als Vorfälle verfolgt? Nein, nein. Weil sie ziemlich schnell repariert werden, normalerweise während der Validierung.

Ein Problem, das schnell behoben wird, ist immer noch ein Problem. Wenn Sie diese nicht als solche melden, ist dies ein Problem.

Es erfordert also Disziplin, um die Ausfallraten genau zu melden. Wir sind nicht motiviert, so zu berichten, weil wir wollen, dass die Dinge funktionieren, und wir tun, was nötig ist, um dies zu erreichen.

Wenn Ihr Ziel tatsächlich darin besteht, dass Dinge funktionieren, müssen Sie ehrlich zu Fehlern sein, damit Sie sie in Zukunft verhindern können. Es hört sich so an, als würde das Team hier (vielleicht sich selbst, sicherlich das Management) über Fehler lügen, weil das Ziel darin besteht, dass die Dinge scheinbar funktionieren.

Das sind verschiedene Dinge. Nehmen Sie zum Beispiel den alten Witz, dass QA Fehler erzeugt - "Mein Code war in Ordnung, bis QA davon erfahren hat, und dann haben sie all diese Fehler gemacht!". Die Fehler waren die ganze Zeit da, aber der Entwickler wusste nichts davon. Das Ziel eines Betriebsteams sollte die tatsächliche Zuverlässigkeit sein , und sie müssen von ihrem Management als solche motiviert werden. Das heißt, wenn sie mehr Überwachung einrichten, die zur Entdeckung neuer Probleme führt, sollten sie belohnt und nicht für den nachfolgenden Rückgang der Zuverlässigkeitsmetriken bestraft werden.

TL; DR, wie beweisen Sie, dass Entwickler, insbesondere die Bereitstellungsautomatisierung, die Änderungsfehlerraten verbessern?

Wenn Sie versuchen, Veränderungen in Ihrer Organisation zu motivieren, sollten Sie nicht versuchen, etwas zu beweisen, sondern nachweisen, was andere Organisationen über ihre eigenen Übergänge sagen. Wenn Sie versuchen, die bereits vorhandenen Prozesse zu messen und deren Fortbestand zu rechtfertigen, sollten Sie die Standard-Zuverlässigkeitsmetriken wie die mittlere Reparaturzeit (MTTR) verfolgen.

Bei den Devops-Prinzipien geht es jedoch nicht nur darum, die Zuverlässigkeit zu erhöhen. Auch beim Site Reliability Engineering geht es nicht nur darum, die Zuverlässigkeit zu erhöhen. Sie möchten vielmehr ein angemessenes Maß an Zuverlässigkeit erreichen - etwas, das dem Unternehmen zugute kommt, aber die Entwicklung nicht behindert. Und das bringt den wahren Motivator in Devops hervor, nämlich Veränderungen zu befähigen . Sie möchten dem Unternehmen ermöglichen, schneller auf Marktreize zu reagieren. Dies geschieht durch Verringern der Entwicklerreibung, Erhöhen der Bereitstellungsrate, Automatisieren manueller Prozesse usw., während eine akzeptable Zuverlässigkeitsgrenze eingehalten wird. Dies bedeutet, dass Sie die Zuverlässigkeit messen müssen, aber auch die Geschwindigkeit messen müssen, da Ihr Ziel darin besteht, die letztere zu erhöhen und die erstere relativ statisch zu halten.