Teams sprechen oft über Produktionsfehler, als ob die Kosten im Fehler enthalten wären. Der Versand erfolgte in einem schlechten Zustand. Bei einer Migration ist ein Randfall übersehen worden. Ein Warteschlangenkonsument hat es zu aggressiv erneut versucht. Korrigieren Sie den Code und die Kosten enden.
Diese Ansicht ist zu klein.
Die Kosten eines Produktionsfehlers hängen nicht nur von der Codezeile ab, die ihn verursacht hat. Es ist die Zeit, die die Organisation damit verbringt, in ihrer Umgebung zu leben.
Das Warten verändert die Form des Ereignisses
Ein Fehler, der innerhalb von fünf Minuten behoben wird, ist normalerweise ein Codeproblem. Ein Fehler, der eine Stunde wartet, wird zu einem Koordinationsproblem. Ein Fehler, der einen Tag wartet, wird zu einem Vertrauensproblem.
Derselbe zugrunde liegende Defekt kann je nach Lebensdauer sehr unterschiedliche Schäden verursachen:
- Kunden geraten immer wieder auf denselben kaputten Weg.
- Support-Teams sammeln Tickets ein, ohne eine sichere Antwort zu erhalten.
- Vertriebs- oder Erfolgsteams beginnen, vorläufige Erklärungen zu verfassen.
- Ingenieure unterbrechen Einsätze in der Nähe, weil sie nicht sicher sind, was sicher ist.
- Mehr Daten gelangen in einem fehlerhaften oder teilweise verarbeiteten Zustand in das System.
- Der ursprüngliche Bereitstellungskontext verschwindet für die Personen, die ihn hatten.
Keine dieser Kosten ist exotisch. Sie sind normale Produktionswiderstandswerte.
MTTR verpasst einige teure Minuten
Die mittlere Zeit bis zur Genesung ist nützlich, kann aber die Momente verbergen, die die meiste Verschwendung verursachen.
Die Uhr startet normalerweise, wenn ein Problem erkannt wird, und stoppt, wenn der Dienst als wiederhergestellt gilt. Das sagt etwas Wichtiges über Zuverlässigkeit aus. Es sagt Ihnen nicht, wie viel Zeit des Vorfalls damit verbracht wurde, den Fehler zu verstehen, den Eigentümer zu finden, Beweise zusammenzustellen oder auf eine überprüfbare Änderung zu warten.
Bei Behebungsabläufen sieht die teure Lücke oft so aus:
alert -> evidence -> code path -> owner -> patch -> review -> deployWenn das Team die ersten vier Schritte komprimieren kann, beginnt die Codeüberprüfung früher und der endgültige Fix lässt sich leichter bewerten.
Der Kontextverfall ist ein echter Kostenfaktor
Über aktuellen Code lässt sich leichter nachdenken. Der Autor erinnert sich, warum die Änderung stattfand. Rezensenten erinnern sich an die Diskussion. Das Feature-Flag, der Rollout-Plan und die Testannahmen sind noch aktuell.
Mit der Zeit werden die Ermittlungen immer schwieriger. Ingenieure überdenken Entscheidungen, die sie vor Stunden getroffen haben. Sie rekonstruieren das Bereitstellungsfenster. Sie öffnen Dashboards erneut. Sie fragen, ob das Problem mit einem anderen Vorfall zusammenhängt. Der Fix mag zwar immer noch klein sein, aber das für die Zusammenführung erforderliche Vertrauen wird immer schwieriger aufzubauen.
Bei einer schnellen Sanierung geht es nicht nur um Geschwindigkeit. Es geht darum, den Kontext zu bewahren, solange das Team ihn noch hat.
Die Kosten sind in technischen Dashboards nicht immer sichtbar
Einige Produktionsprobleme scheinen in der Telemetrie bescheiden zu sein und schaden dennoch dem Geschäft.
Ein Berechtigungsfehler kann sich auf eine kleine Anzahl hochwertiger Konten auswirken. Ein Fehler im Abrechnungsstatus kann beim Erstellen manueller Finanzarbeiten als Randfall mit geringem Volumen auftreten. Ein Checkout-Problem betrifft möglicherweise nur eine Zahlungsmethode in einer Region, die Auswirkungen auf den Support können jedoch unmittelbar spürbar sein.
Technische Dashboards sind notwendig, aber sie erfassen selten die gesamte Wiederherstellungslast. Die richtige Vorfallbeschreibung sollte den Kundenpfad, die Auswirkungen auf das Konto oder den Mandanten, sofern verfügbar, das Supportsignal und den Codebesitz sowie Spuren und Protokolle umfassen.
Was die Wartekosten reduziert
Teams reduzieren die Wartekosten, wenn sie Untersuchungen und Überprüfungen in derselben Schleife durchführen.
Das bedeutet:
- Die Warnung ist mit den relevanten Traces und Protokollen verknüpft
- Das Fehlerfenster wird mit Bereitstellungen verglichen
- der vermutete Codepfad wird benannt
- Der Besitz wird automatisch aufgelöst
- Der vorgeschlagene Patch ist klein genug, um ihn zu überprüfen
- Unsicherheit ist sichtbar, anstatt sich hinter selbstbewussten Formulierungen zu verstecken
Hier ist eine KI-gestützte Sanierung sinnvoll. Es sollte keine geheime Produktionsänderung vorgenommen werden. Es sollte die Beweise vorbereiten, die kleinste plausible Lösung entwerfen und dem Eigentümer einen Pull-Request übergeben, der akzeptiert, bearbeitet oder abgelehnt werden kann.
Der eigentliche Maßstab ist die Zeit für eine gute Entscheidung
Ein Team gewinnt nicht, weil ein Bot schnell einen Diff produziert. Es gewinnt, wenn der richtige Prüfer früher eine gute Entscheidung treffen kann.
Manchmal lautet diese Entscheidung „Merge the Fix“. Manchmal heißt es „Rollback“. Manchmal heißt es: „Dies ist ein Upstream-Vorfall.“ Manchmal heißt es: „Wir brauchen eine menschliche Untersuchung, keinen Patch.“
Warten ist teuer, weil es all diese Entscheidungen verzögert. Das Ziel ist keine hektische Automatisierung. Das Ziel ist ein kürzerer Weg vom Produktionssignal zur evidenzgestützten Aktion.
