Es gibt eine implizite Überzeugung, die den Betrieb fast aller Technologieunternehmen bestimmt: Wenn etwas kaputt geht, muss ein Mensch es reparieren. Dieser Glaube hat jahrzehntelange Bereitschaftskultur, Runbooks, NOCs und frühmorgendliche Alarme geprägt. Das Problem ist, dass es anfängt, falsch zu sein. Nicht weil die Menschen schneller wurden, sondern weil die Systeme anfingen, sich selbst zu reparieren.
Autonomes Computing oder Selbstheilung ist weder Science-Fiction noch ein Verkäuferversprechen. Dabei handelt es sich um eine Kategorie von Praktiken und Technologien, die in Unternehmen mit relevantem Umfang bereits umgesetzt werden und sich schnell im Mainstream durchsetzen. Die Frage für technische Führungskräfte ist nicht, ob dies passieren wird, sondern was es bedeutet, wenn Ihr Stack niemanden mehr aufwecken muss.
Was bedeutet ein System, das sich selbst repariert?
Bei der Selbstheilung geht es nicht nur darum, einen ausgestorbenen Pod neu zu starten. Es ist ein vollständiger Zyklus: Erkennen, dass etwas nicht stimmt, Diagnostizieren der Grundursache, Entscheiden über die richtige Maßnahme und Ergreifen dieser Maßnahmen – und das alles, bevor der Benutzer die Verschlechterung bemerkt.
Dieser Zyklus manifestiert sich auf verschiedene Weise. Ein Kubernetes-Cluster, der einen beeinträchtigten Knoten erkennt, die Arbeitslasten entlastet und die Instanz automatisch ersetzt. Ein Dienst, der einen ungewöhnlichen Anstieg der Latenz bemerkt, die problematische Partition isoliert und den Datenverkehr umleitet, während er das Team alarmiert, ohne den Vorgang anzuhalten. Eine Datenpipeline, die Aufnahmeanomalien identifiziert, die Transformation rückgängig macht und eine erneute Verarbeitung ohne manuellen Eingriff auslöst.
Gemeinsam ist diesen Szenarien die Umkehrung der Reihenfolge: Das System handelt zuerst, der Mensch überprüft später. Das scheint klein zu sein, bis man erkennt, dass die meisten nächtlichen Vorfälle hätten gelöst werden können – oder gar nicht erst zu Vorfällen geworden sein –, wenn das System die richtigen Reflexe gehabt hätte.
AIOps: Wenn Beobachtbarkeit zu operativer Intelligenz wird
Die Verbindung, die Selbstheilung in großem Maßstab ermöglicht, ist AIOps – die Anwendung von maschinellem Lernen auf [Beobachtbarkeitsdaten], um Muster zu erkennen, Ereignisse zu korrelieren und automatisch Maßnahmen zu empfehlen oder zu ergreifen.
Herkömmliche Überwachung sagt Ihnen „CPU ist bei 95 %“. AIOps sagt Ihnen: „Dieser CPU-Spitzenwert tritt jeden Dienstag um 14 Uhr nach einer bestimmten Bereitstellung auf, es handelt sich nicht um einen Vorfall, sondern um ein erwartetes Verhalten, und hier sind die drei anderen Anzeichen, die dies bestätigen.“ Der erste ist ermüdend; der zweite erzieht.
Tools wie Dynatrace, Datadog AIOps, Google Cloud Operations und kleinere Plattformen integrieren diese Art von Überlegungen zu Zeitreihen und Service-Topologie. Das Ergebnis ist kein allwissendes System, sondern ein System, das Fehler gemacht und aus denselben Vorfällen gelernt hat, die Ihr Team bereits erlebt hat – und das beim nächsten Mal niemanden mehr aufwecken muss, um die Probleme zu beheben.
Chaos Engineering und die Disziplin des absichtlichen Scheiterns
Dem autonomen Computing liegt eine Ironie zugrunde: Um Systeme aufzubauen, die sich nach Ausfällen erholen, muss man Systeme absichtlich und auf kontrollierte Weise ausfallen lassen, bevor der tatsächliche Fehler auftritt.
Das ist Chaos Engineering. Die von Netflix mit Chaos Monkey populär gemachte Idee ist einfach: Wenn Sie nicht wissen, wie sich Ihr System bei einem Ausfall verhält, wissen Sie nicht, ob es belastbar ist. Du denkst, dass es so ist. Um zu beweisen, dass dies der Fall ist, muss das Problem injiziert und beobachtet werden, was passiert.
In der modernen Praxis hat sich Chaos Engineering von der „Beseitigung zufälliger Instanzen“ zu chirurgischen Experimenten entwickelt: künstliche Latenz bei Anrufen zwischen Diensten, Erschöpfung der Speicherressourcen in bestimmten Pods, simulierter Ausfall externer Abhängigkeiten, Netzwerkaufteilung zwischen Zonen. Jedes Experiment offenbart eine Annahme, die das Team über die Belastbarkeit hatte – und die ohne den Test eine Illusion bleiben würde, bis es zu einem Vorfall kam.
Die Disziplin des Chaos Engineering ist im Wesentlichen die Disziplin, zuzugeben, dass das System ausfallen wird, und zu entscheiden, dass man es wissen möchte, bevor der Benutzer es tut.
Wie eine Führungskraft das sehen sollte
Die Kosten für die Implementierung der Selbstheilung sind sichtbar und spezifisch. Die Kosten dafür, dass es nicht funktioniert, sind verstreut und chronisch: stundenlanger Bereitschaftsdienst, Vorfälle, die sich wiederholen, leitende Ingenieure, die mit Aufgaben beschäftigt sind, die durch Automatisierung gelöst werden könnten. Diese zweite Zahl erscheint selten im Budget – wohl aber beim Umsatz.
Selbstheilung verändert die Zusammensetzung und den Rhythmus des Einsatzteams. Teams, die die Hälfte ihrer Zeit mit der reaktiven Reaktion auf Vorfälle verbracht haben, haben diese Zeit nun für höherwertige Arbeiten frei: Verbesserung der Erkennungssysteme selbst, Aufbau von Chaos-Experimenten, Überprüfung der autonomen Aktionen des Systems und Entscheidung, ob sie richtig waren. Die menschliche Arbeit erhebt sich auf die nächste Ebene; verschwindet nicht.
Dies hat direkte Auswirkungen auf die Bereitschaftskultur. Eine Schicht, die mit der Ausführung eines manuellen Runbooks beginnt, ist eine Schicht, die Ingenieure erschöpft und Fluktuation generiert. Ein Wandel, der erst dann einsetzt, wenn die Automatisierung keine Lösung finden konnte – und bereits mit einem vollständigen Kontext dessen, was versucht wurde, angekommen ist – ist ein nachhaltiges Modell. Das Ziel besteht nicht darin, den Menschen aus dem Kreislauf auszuschließen, sondern sicherzustellen, dass der Mensch zum richtigen Zeitpunkt in den Kreislauf eintritt und über genügend Informationen verfügt, um qualitativ hochwertige Entscheidungen zu treffen.
Für Führungskräfte, die überlegen, wo sie anfangen sollen: Der günstigste Einstiegspunkt ist nicht die Einstellung eines AIOps-Teams oder die Einführung einer neuen Plattform. Es geht darum, die fünf häufigsten Vorfälle der letzten sechs Monate zu erfassen und für jeden einzelnen zu fragen: Was hätte wahr sein müssen, damit das System das Problem von selbst gelöst hätte? Die Antworten zeigen genau, wo investiert werden sollte.
Lesen Sie auch
- Kubernetes in der Produktion: Was Ihnen niemand vor der Migration sagt
- Edge Computing in Fabriken: Wenn lokale Verarbeitung sinnvoller ist
- Edge Computing: Warum Computing die Cloud verlässt und sich den Daten annähert
- Elektrifizierung: Was ändert sich, wenn sich alles an der Steckdose dreht
- Energie: Der Engpass, den niemand auf die Computing-Roadmap gesetzt hat
- Quantensensoren und Netzwerke: Die Anwendungen, die an erster Stelle stehen