Vom Alarm zur Behebung in 8 Minuten: Warum einheitlicher Kontext entscheidend ist

Platform-Engineering-Teams nutzen heute mehr Tools als je zuvor. Das bedeutet jedoch nicht, dass sich Incidents automatisch schneller beheben lassen. An Daten mangelt es nicht, ebenso wenig an technischem Know-how. Aber die Lücke zwischen den Tools verlangsamt den Prozess.

Die Behebung dauert zehn Minuten – die Diagnose fünfzig

Um zwei Uhr nachts wird ein Alarm ausgelöst: Der Zahlungsdienst kämpft mit massiven Verzögerungen und hat einen kritischen Schwellenwert überschritten. Ein Engineer klappt seinen Laptop auf und hat natürlich noch keine Ahnung, was genau schiefgelaufen ist. Alle relevanten Informationen sind über verschiedene Systeme verteilt. Ein Tab für CloudWatch, ein weiterer für GitLab, um die letzten Deployments zu prüfen, ein dritter für Confluence, um ein Runbook zu finden, das möglicherweise längst nicht mehr den aktuellen Systemzustand widerspiegelt. Parallel dazu durchsucht ein anderer Experte Jira nach ähnlichen Vorfällen aus der Vergangenheit. In Slack sammeln sich bereits erste Theorien von Kollegen, die ebenso wenig Klarheit haben. Fünfzig Minuten später steht die Diagnose endlich fest. Die eigentliche Behebung dauert anschließend gerade einmal zehn Minuten. Solch ein Ausfall verursacht unmittelbare Kosten. Der eigentliche Aufwand moderner Plattformbetriebe entsteht jedoch an anderer Stelle: bei der Bewertung des Kontexts, um überhaupt zu verstehen, was passiert ist. Die durchschnittliche Mean Time to Resolution liegt branchenweit bei mehr als vier Stunden für P1-Incidents. 60 bis 70 Prozent dieser Zeit entfallen allein auf die Analyse und Ursachenforschung. Die eingesetzten Tools erfüllen ihre jeweilige Aufgabe hervorragend. Aber keines von ihnen verfügt über das Wissen der anderen.

„Vernetzt“ vs. „vereinheitlicht“

Alles war gut miteinander verbunden. Warum also dauerte es so lange? Hier liegt jedoch die Falle. Observability-Plattformen, AIOps-Tools, ChatOps-Integrationen oder automatisierte Runbooks: Jedes dieser Systeme funktioniert gut in seinem eigenen Bereich. Keines davon kann jedoch gleichzeitig über mehrere Bereiche hinweg Zusammenhänge herstellen. Wenn drei Minuten nach dem Deployment eines neuen Container-Images über eine GitLab-Pipeline ein CloudWatch-Alarm ausgelöst wird und zugleich ein Jira-Ticket von vor sechs Wochen exakt dieselben Symptome beschreibt, stellt kein einzelnes Tool diese Verbindung her. Sie entsteht nur dann, wenn ein erfahrener Engineer einen solchen Vorfall bereits kennt. Diese Lücke sollte man nicht unterschätzen. Fünf Tools an ein KI-Interface anzubinden schließt sie nicht. Benötigt wird vielmehr ein Assistent, der alle fünf Quellen gleichzeitig im Blick behalten und die Informationen im Zusammenhang interpretieren kann.

So sieht ein effizienter Assistent in der Praxis aus

Um die Produktivität spürbar zu steigern, hat das Team von Andersen eine Lösung entwickelt. Der Self-Service DevOps Assistant (SDA) behandelt Alarme, Deployments, Tickets und Runbooks als Teile eines einzigen Gesamtbildes. Dieser Unterschied – zwischen bloß vernetzt und tatsächlich vereinheitlicht – entscheidet darüber, wie stark sich Analysezeiten verkürzen und Incidents schneller beheben lassen. Die Lösung ist cloud-agnostisch. Sie integriert sich in die Tools, die Platform-Teams bereits nutzen. Dazu gehören unter anderem AWS und Azure für die Infrastruktur, GitHub oder GitLab für Repositories, Jira oder ServiceNow für Tickets sowie Confluence für Dokumentation. Zusätzliche Agents in der Produktionsinfrastruktur oder Änderungen an bestehenden Pipelines sind nicht erforderlich. Dieser Assistent fungiert als Ebene über dem bestehenden Stack. Engineers interagieren mit SDA über die CLI oder Microsoft Teams, ähnlich wie mit einem erfahrenen Kollegen. Sie stellen Fragen wie „Welche Änderungen wurden in den letzten zwei Stunden am Payment-Service vorgenommen?“ oder „Warum ist diese Pipeline fehlgeschlagen und gab es bereits einen ähnlichen Vorfall?“ SDA greift dafür auf Live-Datenquellen zu, verknüpft diese mit interner Dokumentation und Ticket-Historien und liefert eine nachvollziehbare Diagnose inklusive Belegen. Die Funktionen gliedern sich in drei Bereiche:

• Infrastructure Troubleshooting: SDA analysiert Live-Zustände von Ressourcen, Logs und Metriken über verschiedene Cloud-Provider hinweg. Seine Antworten basieren auf aktuellen Systemdaten.
• Incident-Untersuchung: Cloud-Events, aktuelle Deployments und historische Tickets werden innerhalb einer einzigen Analyse korreliert.
• CI/CD-Analyse: Pipeline-Logs und Repository-Kontexte werden ausgewertet, um Fehlerursachen zu identifizieren und verständlich einzuordnen.

Aktionen mit direktem Einfluss auf die Infrastruktur (Neustart eines Services, Änderungen über Terraform, Erstellen neuer Tickets) erfordern jedoch weiterhin eine explizite Freigabe durch Engineers. Die Architektur lässt sich über MCP-Integrationen erweitern. Man kann zusätzliche Tools problemlos einbinden, wenn sich der Stack weiterentwickelt.

Warum Live-Kontext zählt

Die meisten intelligenten Assistenzsysteme im DevOps-Umfeld arbeiten mit Dokumenten wie Runbooks oder Architekturdiagrammen. Das ist zweifellos nützlich, doch Infrastruktur weicht fast unmittelbar von ihrer Dokumentation ab. Runbooks veralten, und Architekturdiagramme spiegeln Entscheidungen wider, die oft lange zurückliegen. Das System, das heute betrieben wird, unterscheidet sich immer ein Stück weit von dem, was auf dem Papier steht. Wenn ein Assistent dagegen in der Lage ist, den aktuellen Zustand der Infrastruktur direkt über Live-Logs, Echtzeit-Metriken und die aktuelle Konfiguration abzurufen, wird die Dokumentation zu einer hilfreichen Ergänzung. Die Antwort basiert dann auf dem, was tatsächlich jetzt gerade gilt. Am Beispiel des Zahlungsdienstes von oben wird dieser Unterschied greifbar. Ein rein dokumentenbasierter Assistent würde vielleicht ein Runbook zu RDS-Connection-Pool-Problemen hervorbringen. Ein Assistent mit Live-Kontext hingegen findet die konkrete Terraform-Änderung, die vor vier Stunden eingespielt wurde, und erkennt, dass sie die Connection-Pool-Parameter verändert hat. Zusätzlich verknüpft er den Fund mit einem Jira-Ticket von vor drei Monaten, das dasselbe Latenzmuster im nachgelagerten System beschrieb und die damals erfolgreichen Lösungsschritte dokumentierte.

Mit Read-only-Betrieb fängt Vertrauen an

Doch wenn der Assistent bei der Diagnose so beeindruckende Fähigkeiten zeigt, warum lässt man ihn das Problem nicht einfach auch beheben? Die Antwort hat weniger mit technischer Machbarkeit zu tun als mit Vertrauen. Ein smarter Assistent, der eigenständig Entscheidungen trifft, bevor sie von Engineers überprüft wurden, schafft ein völlig anderes Risikoprofil. Er mag neun von zehn Fällen korrekt diagnostizieren. Im zehnten Fall kann jedoch ein automatisierter Rollback aufgrund einer Fehlinterpretation einer Latenzspitze einen echten Ausfall auslösen. Der Read-only-Betrieb liefert dabei den Großteil des Mehrwerts: deutlich schnellere Diagnosen, relevanter historischer Kontext und konkrete Lösungsvorschläge. Gleichzeitig bleiben Menschen im Entscheidungsprozess eingebunden, sobald es um Veränderungen am Systemzustand geht. Engineers validieren die Empfehlung und führen die eigentliche Änderung selbst aus. So wächst das Vertrauen mit der Zeit, und Teams können den Handlungsspielraum des Assistenten schrittweise und mit gutem Gewissen erweitern. Teams, die diese Phase überspringen und direkt auf vollständige Automatisierung setzen, sehen sich häufig gezwungen, Automatisierungen nach dem ersten schwerwiegenden Fehler wieder zurückzunehmen.

Wie sich Prozesse beschleunigen lassen

Wer die Diagnosezeiten deutlich verkürzen möchte, braucht einen konsequenten, strukturierten Ansatz:

• Mit zwei bis drei Quellen starten. Alles auf einmal anzubinden macht es unmöglich zu erkennen, was echten Mehrwert liefert. Daher zunächst den primären Cloud-Anbieter, die Git-Repositories und den Issue-Tracker verbinden und eine Ausgangsbasis schaffen. So kann man beurteilen, was der intelligente Assistent leisten kann.
• Die Wissensbasis vor dem Go-live prüfen. Bei frühen Implementierungen gibt es gewiss fehlende Inhalte. Dazu gehören nicht dokumentierte Runbooks oder Architekturentscheidungen, die nur noch einzelnen Personen bekannt sind. Diese Lücken sollten als eigentliche Erkenntnisse verstanden und parallel zur Einführung geschlossen werden.
• Von Anfang an in den On-Call-Workflow integrieren. Ein Assistent, der nur zur Hintergrundrecherche genutzt wird, aber im echten Incident-Fall keine Rolle spielt, löst das eigentliche Problem nicht.
• Die erste Phase bewusst read-only halten. Auch wenn das System bereits viel leisten kann, müssen Engineers zunächst die Qualität der Ergebnisse bewerten, bevor Vertrauen entsteht. Nach einigen Wochen stabiler und korrekter Diagnosen kann der Handlungsspielraum des Assistenten schrittweise erweitert werden.
• Vorher und nachher messen. Zeit bis zur Diagnose, Anzahl der in Incidents eingebundenen Engineers sowie MTTR nach Incident-Typen. Ohne eine klare Ausgangsbasis bleibt der Effekt unsichtbar und lässt sich im Zweifel nicht gegenüber dem Budget rechtfertigen.

Fazit

Die Lücke zwischen Alarm und Behebung war nie ein Problem fehlender Technologie. Vielmehr hat es bislang eine Ebene gefehlt, die unterschiedliche Datenquellen zu einem konsistenten Gesamtbild zusammenführt. Die Diagnosezeit von fünfzig auf acht Minuten zu senken erfordert keinen Austausch des bestehenden Stacks. Es genügt, ihn so zu verknüpfen, dass der Engineer eine Frage stellt und eine Antwort bekommt, die auf allem gründet, was gerade jetzt passiert.