Sichere Grenzen für Self-Healing festlegen

Beheben Sie einen bekannten Fehlerzustand

Self-Healing erkennt einen definierten Fehler automatisch und versucht eine autorisierte Wiederherstellungsmaßnahme. Beispiele sind der Neustart eines ausgefallenen Prozesses oder der Austausch einer fehlerhaften Instanz. Die Handlung muss zum Fehler und zum Zustandsmodell des Dienstes passen.

Kubernetes kann ausgefallene Workload-Instanzen ersetzen und den deklarierten Zustand herstellen. Das korrigiert weder fehlerhafte Anwendungslogik noch jeden Speicherfehler. Die Wiederherstellung der Infrastruktur und die Korrektheit der Software erfordern unterschiedliche Prüfungen. Self-Healing in Kubernetes.

Definieren Sie das Ziel vor dem Mechanismus. Ein wiederhergestellter Export bedeutet, dass berechtigte Aufträge korrekt abgeschlossen werden. Ein laufender Container ist nur eine Voraussetzung.

Trennen Sie drei Arten von Änderungen

Ein Agent kann nach der Wiederherstellung eine Korrektur vorschlagen. Dieser Vorschlag ist eine neue Softwareänderung. Er darf keine unbegrenzten Befugnisse vom Wiederherstellungscontroller übernehmen.

Der Controller darf auch seine eigenen Erfolgskriterien nicht ändern, wenn eine Prüfung fehlschlägt. Sonst kann das System eine Verbesserung melden, ohne den Dienst zu verbessern.

Schreiben Sie die Wiederherstellungsrichtlinie vor ihrer Aktivierung

Die folgende Richtlinie ist fiktiv. Ihre Zahlen veranschaulichen Entwurfsentscheidungen; sie sind keine empfohlenen Standardwerte.

Nutzen Sie eine Identität mit minimalen Berechtigungen. Protokollieren Sie Richtlinienversion, Auslösernachweise, Handlung, Ressource und Ergebnis. Stellen Sie einen unabhängigen Weg bereit, den Controller zu deaktivieren. Benennen Sie die Person, die eine Eskalation erhält.

Testen Sie Fehlerpfade ebenso wie erfolgreiche Wiederherstellung

Ein erneuter Versuch kann eine Nebenwirkung wiederholen. Ein Worker könnte eine Datei speichern und stoppen, bevor er den Job bestätigt. Prüfen Sie die Idempotenz, bevor Sie eine weitere Ausführung erlauben. Siehe das Cloud-Native-Fehlerbeispiel.

Wiederholungen können eine überlastete Abhängigkeit zusätzlich belasten. Begrenzen Sie Versuche, setzen Sie Timeouts und nutzen Sie geeignete, zunehmende Wartezeiten. Vermeiden Sie gleichzeitige Wiederholungen im gesamten Bestand. AWS erklärt, wie Backoff und zufällige Zeitabweichungen, Jitter, diese Verstärkung verringern. Hinweise zu Wiederholungen.

Testen Sie die fiktive Richtlinie mit drei Fällen. Ein einzelner gestoppter Worker sollte sich wiederherstellen. Ein Datenbankausfall sollte wiederholte Ersetzungen verhindern. Ein ungeklärter Integritätsfehler sollte die Automatisierung stoppen und eine Reaktionsentscheidung anfordern.

Prüfen Sie auch fehlende Telemetrie. Ein ausbleibendes Lebenszeichen kann auf einen ausgefallenen Worker oder einen fehlerhaften Erfassungsweg hinweisen. Der Controller braucht ausreichende Nachweise für seine Handlung. Vertrauen in eine KI-Erklärung reicht nicht.

Messen Sie, ob die Richtlinie hilft

Erfassen Sie nachgewiesene Wiederherstellungen, erfolglose Versuche, Eskalationen, doppelte Arbeit und die Dauer der Nutzerbeeinträchtigung. Vergleichen Sie diese Werte unter ähnlichen Bedingungen mit der bisherigen Betriebsweise.

Behalten Sie den zugrunde liegenden Defekt als Entwicklungsaufgabe bei. Wiederholte Neustarts eines Prozesses mit Speicherleck können die unmittelbaren Auswirkungen verringern, während das Leck fortbesteht. Fahren Sie mit Self-Improvement fort, um die Beobachtung mit einer dauerhaften Korrektur zu verbinden.