Welche Beziehung besteht zwischen Rollback / Rollforward- und MTTR-Metriken?

Ich versuche zu verstehen, wie Daten am besten erfasst werden können, um mit der Messung der MTTR-Metriken (Mean Time To Repair) zu beginnen, und ich muss mich darum kümmern, wie sich "Rollback" positiv oder negativ auf die MTTR auswirkt.

Szenario 1

Unter der Annahme, dass eine solide Überwachung vorhanden ist, wird Code bereitgestellt, der einen Vorfall verursacht, der ziemlich schnell erkannt wird (niedriger MTTI). Zum Zeitpunkt der Identifizierung gibt es zwei mögliche Hauptpfade (ja, ich vereinfache dies zu Diskussionszwecken zu stark):

1. Setzen Sie die Bereitstellung zurück und geben Sie schnell Stabilität zurück, jedoch ohne die beabsichtigten Funktionen in der Produktion.

2. Roll-Forward mit zusätzlichen Änderungen, die den Vorfall beheben und die beabsichtigten Funktionen am Leben erhalten.

In diesem Szenario ist die MTTR verdammt niedrig, da die Stabilität der Website ziemlich schnell wiederhergestellt werden kann. Das beabsichtigte Ergebnis der Änderung ist jedoch nicht live, und daher bleibt der Code / die Funktion / die Änderung noch in Bearbeitung. Wenn ein Ziel eine niedrige MTTR ist, scheint dies einen Anreiz für das Rollback als Wiederherstellungsmechanismus zu sein.

Szenario 2

In diesem Szenario wird MTTR streng daran gemessen, wie lange es dauert, bis der erwartete Code / die erwartete Funktion / Änderung in der Produktion ordnungsgemäß funktioniert. Selbst wenn ich ein Rollback durchführe, läuft der MTTR-Timer weiter, bis meine "feste" Codeänderung in das Produkt übergeht. In diesem Fall scheint MTTR an die Stabilität der Geschäftsergebnisse gebunden zu sein, anstatt nur "Hey, die Dinge sind stabil".

Die Antwort mag jetzt so einfach sein, dass MTTR nicht als Metrik in einem Vakuum verwendet wird, sondern in Verbindung mit der Änderungsfehlerrate - eine extrem niedrige MTTR, die durch häufige Rollbacks verursacht wird, könnte auf eine himmelhohe Änderungsfehlerrate hinweisen. Die Idee, die MTTR-Messung vom Geschäftsergebnis zu trennen, scheint mir jedoch nicht richtig zu sein.

Ich überdenke das vielleicht viel, aber ich bin gespannt, wie andere die MTTR messen und wie der Endzeitpunkt für die "Wiederherstellung" ist. Verwenden Sie es einfach als Stabilität oder bestimmen andere Faktoren, was "wiederhergestellt" bedeutet?

Ja, MTTR ist / sollte immer an das Geschäftsergebnis gebunden sein: Wenn die Dinge nicht stabil sind, ist das Geschäft gefährdet.

Die Tatsache, dass der erwartete Code / das erwartete Feature / die erwartete Änderung in Szenario 1 noch in Bearbeitung ist, spielt keine Rolle: Das Feature ist nicht stabil, bringt also kein neues Geschäft. Das Zurücksetzen ist das Beste, was Sie zu diesem Zeitpunkt aus dem Geschäft heraus tun können prospektiv.

Der Rollforward ist ein Glücksspiel: Er hält das Risiko aufrecht, auf eine mögliche Lösung zu warten , die tatsächlich statistisch geringere Erfolgsänderungen aufweist (aufgrund der Instabilität wird sie im Vergleich zu der Änderung, die die Instabilität überhaupt verursacht hat, immer beschleunigt, ohne sie überhaupt zu haben solchen Druck darauf). Der Rollforward ist eine weitere Version des Codes, die zuvor noch nicht überprüft wurde.

Wenn Sie die MTTR niedrig halten möchten, rollen Sie sofort und ohne Debatte zurück. Dadurch wird das Geschäftsrisiko beseitigt und Sie können überprüfen, ob das Update tatsächlich funktioniert, bevor Sie versuchen, es bereitzustellen. Ich würde dringend empfehlen, es zu einer Richtlinie zu machen, da es fast immer jemanden gibt, der nach einer Lösung anstelle des Rollbacks fragt und ein Meeting einberuft, um darüber zu verhandeln / zu entscheiden - während das Geschäft weiterhin gefährdet ist.

Randnotiz: Wenn Sie mit einer hohen Änderungsfehlerrate befasst sind, würde ich empfehlen, die tatsächliche Rollback-Rate zu überprüfen, anstatt sie von einer niedrigen MTRR abzuleiten. Vielleicht möchten Sie vor der Bereitstellung eine Gate-Überprüfung für die häufigsten Fehler hinzufügen. Wenn Sie eine solche Prüfung bereits automatisiert haben - warum nicht in die CI-Überprüfung einbeziehen? Wenn Sie keine haben - vielleicht ist es Zeit, darüber nachzudenken? :) :)

Die mittlere Zeit zur Genesung hat ein implizites Thema - die mittlere Zeit zur Genesung was ? Dies zu definieren ist der Schlüssel zur effektiven Verwendung der Metrik.

Stellen Sie die allgemeine Verfügbarkeit Ihrer Produktionswebsite wieder her? Stellen Sie die Funktionalität einer bestimmten Funktion wieder her, die einen Fehler enthält? Sobald Sie wissen, was Sie tatsächlich messen möchten, ist es viel einfacher, es zu messen!

Der allgemeine Schwerpunkt Ihrer Frage scheint darin zu liegen, die konkurrierenden Ziele der Versandfunktionen und der Aufrechterhaltung der Zuverlässigkeit zu verfolgen, was ein jahrhundertealter Kampf ist. Traditionell sind es die Aufgaben der Entwickler, neue Dinge zu implementieren, und die Aufgaben der Systemadministratoren, um zu verhindern, dass Dinge kaputt gehen. Dies führt zu Konflikten zwischen den Abteilungen, da Änderungen dazu neigen, zu brechen. Eine der häufig mit DevOps verbundenen Philosophien ist die Idee, dass Entwickler und Ops-Ingenieure eng zusammenarbeiten sollten, um diese Spannungen abzubauen.

Möglicherweise interessiert Sie auch der Ansatz von Google für dieses Problem, nämlich "Fehlerbudgets" für Entwicklungsteams bereitzustellen. Sobald sie die Stabilität zu sehr bestraft haben, müssen sie den Rest des Quartals nur noch an der Stabilität arbeiten. Zusammen mit diesem haben die Website Zuverlässigkeit Ingenieure verfügbar Ziele, und wenn sie über zu schießen, werden ermutigt , sie mehr Änderungen durchzulassen; Die Idee dabei ist, dass ihr Ziel nicht einfach darin bestehen muss, die Zuverlässigkeit so hoch wie möglich zu halten, da sie dann motiviert wären, Veränderungen in jeder Situation zu bekämpfen.