Branchenergebnisse: SRE-Teams sind hervorragend darin, auf Vorfälle zu reagieren. Die Daten, die die Häufigkeit von Vorfällen reduzieren würden, liegen in Protokollen und Metriken, die niemand proaktiv zu untersuchen Zeit hat.
von Madelyn Mullen
ANWENDUNGSFALL
Plattformzuverlässigkeitsintelligenz & Engineering-Metriken
Engineering-Teams nutzen Observabilitätsdaten, um Vorfälle zu verhindern, indem sie kontinuierlich Signale überwachen und diese Daten proaktiv abfragen, um aufbauende Risiken zu identifizieren, bevor sie zu einem benutzerseitigen Ausfall führen. Die Signale können Fehlerraten-Trends, Latenz-Perzentile, Bereitstellungshäufigkeit, SLO-Burn-Rates und andere für Ihren Dienst relevante Metriken umfassen. Der Wandel von reaktiver Vorfallreaktion zu proaktiver Zuverlässigkeitsintelligenz erfordert zwei Dinge: einheitlichen Zugriff auf Telemetriedaten über Dienste hinweg und eine Möglichkeit, diese Daten im Tempo von Engineering-Entscheidungen abzufragen. Wenn Engineering-Leiter fragen können: „Welche Dienste nähern sich bei aktuellen Burn-Rates ihrer Fehlertoleranzschwelle?“ und innerhalb von Sekunden statt Tagen eine Antwort erhalten, können sie Minderungsentscheidungen treffen, bevor der Vorfall eintritt. Proaktive Ansätze schützen sowohl die Betriebszeit als auch die F&E-Kapazität, die sonst für Notfallmaßnahmen aufgewendet würde.
Ihre Engineering-Organisation ist nicht aus freien Stücken reaktiv. Sie ist reaktiv durch ihre Architektur. Sie verfügen über die Observabilitätsdaten: Metriken, Protokolle, Traces, Fehlertoleranzen, SLO-Burn-Rates. Sie haben die Instrumentierung. Was Ihnen fehlt, ist eine Möglichkeit, Fragen zu diesen Daten im Tempo zu stellen, das Engineering-Entscheidungen tatsächlich erfordern. Bis die Frage beantwortet werden kann, ist der Vorfall bereits im Gange.
Das ist kein On-Call-Problem. Es ist ein Datenzugriffsproblem, und es ist die Lücke, die die meisten Engineering-Organisationen noch nicht benannt haben.
Jeder ungeplante Vorfall hat Geschäftskosten: Engineering-Zeit, die von der Roadmap-Arbeit abgezogen wird, schwindendes Kundenvertrauen, SLA-Risiken und nachgelagerte Spitzen im Supportvolumen. Zuverlässigkeit ist kein Problem der Engineering-Hygiene. Es ist ein Problem des Umsatzschutzes und der F&E-Effizienz und verdient die gleiche analytische Strenge wie jede andere Geschäftsfunktion.
Wie Chase Holland, Lead Principal Software Engineer bei The Trade Desk, es ausdrückt: „Der teuerste Teil des Aufbaus eines Produkts ist nicht mehr das Schreiben des Codes ... Es ist die Entscheidung, was zu tun ist. Je bessere Daten Sie darüber erhalten, was Sie tun sollten, desto bessere und schnellere Entscheidungen können Sie treffen.“ Im Zuverlässigkeitskontext bedeutet dies, Daten zu verwenden, um zu entscheiden, welches Risiko am Montag gemindert werden soll, damit Sie am Samstag keine Notfall-Patches schreiben müssen.
Moderne Observabilitätsplattformen sind für die Vorfallreaktion optimiert: Alarm bei Verstößen, Diagnose, Behebung. Sie sind nicht dafür ausgelegt, die vorgelagerte Frage zu beantworten, die ein VP of Engineering tatsächlich beantwortet haben möchte: Welche Teile des Systems sammeln Zuverlässigkeitsrisiken, die sich in den nächsten 30–60 Tagen als Vorfälle manifestieren werden? Die Beantwortung erfordert die Abfrage von Fehlerraten-Trends, Latenz-Perzentil-Trends und Kapazitätsauslastungs-Trends über Dutzende von Diensten hinweg – ohne auf eine Datenanfrage-Warteschlange warten zu müssen. Die Signale existieren. Die Fähigkeit des Engineering-Leiters, sie proaktiv zu lesen, existiert nicht.
Zuverlässigkeitsintelligenz ist die Praxis, Telemetriedaten zu verwenden, um proaktiv Zuverlässigkeitsrisiken zu identifizieren, bevor sie sich als benutzerseitiger Vorfall manifestieren. Dinge wie Metriken, Protokolle, Traces, Fehlertoleranzen und Bereitstellungsprotokolle unterscheiden sich in einem entscheidenden Punkt von der traditionellen Observability: Observability sagt Ihnen, was gerade passiert; Zuverlässigkeitsintelligenz sagt Ihnen, was wahrscheinlich in den nächsten 7–30 Tagen passieren wird, basierend auf Trendanalysen über Ihr Serviceportfolio hinweg. Eine Organisation, die Zuverlässigkeitsintelligenz praktiziert, wartet nicht auf eine SLO-Verletzungsbenachrichtigung. Sie identifiziert, dass das Fehlertoleranzbudget eines Dienstes am Dienstagmorgen doppelt so schnell wie normal verbraucht wird, und entscheidet, wie darauf reagiert werden soll, bevor die On-Call-Rotation am Wochenende davon betroffen ist.
Engineering-Leiter in Systemen mit hoher Skalierung verfolgen die richtigen Metriken: MTTR (Mean Time To Resolve), Vorfallhäufigkeit, SLO-Einhaltung nach Dienst. Diese Metriken sagen Ihnen, wie gut Ihr Team reagiert. Sie sagen Ihnen nicht, was kommt. Was strukturell fehlt, ist die vorgelagerte Frage: Wo sammelt sich Zuverlässigkeitsrisiko, bevor es zu einem Pager-Aufruf wird, und was kostet dieses Risiko das Unternehmen an Entwicklerzeit, Roadmap-Kapazität und Kundenvertrauen?
Die Daten zur Beantwortung dieser Frage existieren in Ihrer Telemetrie. Sie sind nicht in einer Form, die Engineering-Leiter ohne spezialisierte Tools oder Analystenunterstützung abfragen können. Ihr SRE-Team ist hervorragend in der Reaktion. Es ist nicht darauf ausgelegt, wöchentlich proaktiv Trenddaten von Hunderten von Diensten zu analysieren. So sammeln sich die Signale. Der Vorfall passiert. MTTR verbessert sich, weil Ihr Team geübt ist. Die Vorfallhäufigkeit nicht, weil die Analyse, die sie reduzieren würde, nie durchgeführt wurde. Und jeder Vorfall, der hätte vermieden werden können, ist F&E-Kapazität, die für die Brandbekämpfung statt für das Shipping aufgewendet wurde.
Das Thema der Woche ist, dass das Wachstum einer unserer Produktlinien stagniert und wir versuchen herauszufinden, warum. Es ist sehr schwierig, die Erkenntnisse zu gewinnen und zu wissen, ob man ihnen vertrauen kann, wenn man sie erhält. — Ein VP of Product bei einer KI-nativen Plattform
Das Datenzugriffsproblem verschärft sich zu einem Datenvertrauensproblem. Der Rahmen gilt für Engineering-Organisationen jeder Größe: Die reaktive Diagnose ist der Standard, weil die proaktive Abfrage von Zuverlässigkeitsdaten strukturell schwierig ist, da die vorgelagerte Analyse, die sie reduzieren würde, einen Datenzugriff erfordert, den Engineering-Leiter nicht auf Abruf haben. Und selbst wenn Sie eine Antwort erhalten, sind Sie sich nicht immer sicher, ob sie richtig ist. MTTR verbessert sich. Die Vorfallhäufigkeit nicht.
Ohne diesen sofortigen Zugriff verfallen Zuverlässigkeitsbesprechungen oft in das, was Holland „meinungsbasierte Verhandlungen“ nennt. Wenn Teams keine einzige, vertrauenswürdige Quelle für ihre operativen Daten haben, verbringen sie Wochen damit, die Ursache eines Trends zu diskutieren, anstatt ihn zu beheben. Durch die Umstellung auf ein Self-Service-Modell hat ein globaler Werbetechnologie-Marktführer wie The Trade Desk diese wochenlangen Debatten in schnelle, verifizierte Lösungen verwandelt, die es seinen Teams ermöglichen, mit viel höherer Absicht voranzugehen.
Databricks Genie ermöglicht es Engineering-Leitern, ihre operativen Telemetriedaten in natürlicher Sprache abzufragen. Ein VP of Engineering kann fragen: „Welche Dienste haben in den letzten 14 Tagen eine Zunahme der p99-Latenz von mehr als 20 % gezeigt, und welche Abhängigkeiten überschneiden sich mit den Diensten, die im zweiten Quartal Vorfälle hatten?“ Diese Frage wird in Sekunden statt Tagen aus Ihren tatsächlichen Engineering-Daten extrahiert.
Die weiterführenden Fragen ergeben sich natürlich. „Welche Dienste nähern sich bei aktuellen Burn-Rates ihrer Fehlertoleranzschwelle und wann erwarten wir eine Verletzung?“ Oder: „Was ist die Korrelation zwischen Bereitstellungshäufigkeit und Vorfallrate bei meinen meistbesuchten Diensten im dritten Quartal?“ Diese Fähigkeit ist nicht auf einfache Datensätze beschränkt. Um die Sichtbarkeit in einer riesigen Umgebung von über 10.000 Tabellen aufrechtzuerhalten, hat The Trade Desk einen „Genie Router“ entwickelt, der Fragen automatisch an die richtige Datenumgebung weiterleitet. Dies ermöglicht es ihnen, eine einzige Schnittstelle für ihre Teams zu unterhalten und gleichzeitig ein Maß an technischer Komplexität zu bewältigen, das ein Standard-Dashboard überfordern würde. Jede Antwort stammt aus Ihrer tatsächlichen Telemetrie, Ihren Bereitstellungsprotokollen und Ihrer Vorfallhistorie und ist direkt für jeden Engineering-Leiter abfragbar, ohne die Frage zuerst für einen Analysten übersetzen zu müssen.
Für einen Engineering-Leiter, dessen Zuverlässigkeitsverpflichtungen auch Geschäftsverpflichtungen sind – SLA-Risiken, Kundenvertrauen und die durch Vorfälle verbrauchte F&E-Kapazität – ist diese Abfragegeschwindigkeit der Unterschied zwischen proaktivem Risikomanagement und reaktiver Brandbekämpfung. Ihr Fehlertoleranzbudget ist nicht nur eine technische Metrik; es ist eine Geschäftsressource. Genie ermöglicht es Ihnen, es wie eine solche zu verwalten. Das Zuverlässigkeitssignal, das einen Minderungs-Sprint gerechtfertigt hätte, taucht vor dem Vorfall auf, nicht währenddessen.
Schritt 1 – Zentralisieren Sie Ihre Telemetrie. Bringen Sie Metriken, Protokolle, Traces, Bereitstellungsprotokolle und Vorfallhistorie in eine einheitliche Datenumgebung. Fragmentierte Tools sind der Hauptgrund, warum proaktive Analysen nicht stattfinden: Ingenieure können keine dienstübergreifenden Fragen beantworten, wenn die Daten jedes Dienstes in einem anderen System liegen.
Schritt 2 – Definieren Sie führende Indikatoren, nicht nur nachlaufende. MTTR und Vorfallhäufigkeit messen, was bereits geschehen ist. Führende Indikatoren messen, was passieren wird. Teams, die die Trajektorie des SLO-Burn-Rates, den Trend der p99-Latenz, das verbleibende Fehlertoleranzbudget bei aktueller Verbrauchsrate zusammen mit nachlaufenden Indikatoren verfolgen, können eingreifen, bevor der Pager auslöst.
Schritt 3 – Ermöglichen Sie Self-Service-Abfragen für Engineering-Leiter. Die Analyse, die die Vorfallhäufigkeit reduzieren würde, wird selten durchgeführt, da sie Analystenunterstützung und eine Wartezeit von 48 Stunden erfordert. Wenn Engineering-Leiter ihre eigenen Zuverlässigkeitsdaten in natürlicher Sprache abfragen können – und fragen: „Welche Dienste haben in diesem Quartal die höchste Korrelation zwischen Bereitstellungshäufigkeit und Vorfallrate?“ – wird proaktives Risikomanagement zur wöchentlichen Gewohnheit, nicht zu einer vierteljährlichen Übung.
Die Engineering-Organisationen, die in komplexen Systemen mit hoher Skalierung eine hohe Zuverlässigkeit aufrechterhalten, sind diejenigen, die ihre operativen Daten proaktiv abfragen und die Signale aufbauender Risiken finden können, bevor sie sich als benutzerseitige Vorfälle manifestieren. Dies erfordert einen Datenzugriff, der für das Tempo der Engineering-Entscheidungsfindung ausgelegt ist, nicht für das Tempo von Analysten-Abfrage-Warteschlangen.
Der Zyklus von Erkenntnis zu Handlung bei der Plattformzuverlässigkeit wird in Stunden und Tagen gemessen, nicht in Sprintzyklen. Wenn ein Engineering-Team am Montagmorgen einen p99-Latenztendenz erkennen und vor dem Standup einen Lösungsansatz festlegen kann, agiert es auf Basis von Zuverlässigkeitsintelligenz statt auf Vorfallreaktion. Wenn dieselbe Frage eine Datenanfrage und eine 48-stündige Wartezeit erfordert, tritt der Vorfall zuerst ein.
Für Engineering-Teams mit kundenorientierten SLAs hat diese Geschwindigkeit direkte geschäftliche Auswirkungen. Ad-hoc-Analysen laufen mit Genie 5x schneller, was bedeutet, dass die Zuverlässigkeitsfrage, die zwei Tage auf einen Analysten gewartet hätte, vor dem Standup erledigt ist.
DATABRICKS GENIE · KEY DIFFERENTIATORS
Entwickelt für Ihre Daten, gesteuert nach Ihren Regeln, beantwortbar für jeden Engineering-Leiter.
F: Was ist der Unterschied zwischen Observability und Monitoring zur Vorfallprävention?
Antwort: Sollte reaktives Monitoring (Warnungen, wenn etwas ausfällt) von Observability (Systemzustand gut genug verstehen, um Ausfälle vorherzusagen) in 2–3 Sätzen unterscheiden.
F: Welche Observability-Signale sind am vorhersagbarsten für bevorstehende Vorfälle?
Antwort: Sollte SLO-Burn-Rate, p99-Latenztendenz und Deployment-korrelierte Fehlerrate als die drei handlungsfähigsten Frühindikatoren nennen – halten Sie es bei 2–3 Sätzen.
F: Wie hilft Databricks Genie SRE-Teams bei der Vorfallprävention?
Antwort: Sollte die Fähigkeit von Genie zur Abfrage natürlicher Sprache mit dem spezifischen Anwendungsfall der proaktiven Trenduntersuchung verbinden – aus vorhandenem Entwurfstext ziehen.
F: Wie lange dauert es, von reaktiver Vorfallreaktion zu proaktiver Zuverlässigkeitsintelligenz zu wechseln?
Antwort: Sollte ehrlich und praktisch sein: Zentralisierung und Tooling dauern typischerweise Wochen; kultureller Wandel zur proaktiven Abfrage dauert 1–3 Monate mit dem richtigen Self-Service-Zugang.
F: Welche DORA-Metriken sollten Engineering-Teams verfolgen, um die Zuverlässigkeit zu verbessern?
Antwort: Sollte die vier DORA-Metriken (Deployment-Frequenz, Durchlaufzeit, MTTR, Change Failure Rate) nennen und darauf hinweisen, dass Change Failure Rate und MTTR zusammen die stärksten Zuverlässigkeitsprädiktoren sind.
Sehen Sie, was Genie für Ihr Team tun kann
Wenn sich Ihr MTTR weiter verbessert, aber die Vorfallhäufigkeit nicht, liegt die Lücke nicht in der Ausführung – sie liegt im proaktiven Datenzugriff. Zuverlässigkeit ist ein Problem der F&E-Effizienz. Sehen Sie, wie Engineering-Leiter AI/BI Genie nutzen, um es wie ein solches zu managen.
(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag
Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.