Stel veilige grenzen aan self-healing

Herstel een bekende toestand

Self-healing detecteert automatisch een gedefinieerde storing en probeert een geautoriseerde herstelactie uit te voeren. Voorbeelden zijn een gestopt proces herstarten of een ongezonde instantie vervangen. De actie moet passen bij de storing en het toestandsmodel van de service.

Kubernetes kan uitgevallen workloadinstanties vervangen en de gedeclareerde toestand herstellen. Dat corrigeert geen foutieve applicatielogica of elke opslagstoring. Infrastructuurherstel en correcte softwarewerking vereisen verschillende controles. Self-healing in Kubernetes.

Definieer het doel vóór het mechanisme. Een export herstellen betekent dat geldig werk correct wordt voltooid. Een draaiende container is slechts één voorwaarde.

Onderscheid drie soorten wijzigingen

Een agent kan na herstel een correctie voorstellen. Dat voorstel is een nieuwe softwarewijziging. Het mag geen onbeperkte bevoegdheid erven van de herstelcontroller.

De controller mag ook niet zijn eigen succescriteria aanpassen als een controle mislukt. Anders kan het systeem verbetering melden zonder de service te verbeteren.

Schrijf het herstelbeleid voordat u het activeert

Het volgende beleid is fictief. De getallen illustreren ontwerpkeuzes; het zijn geen aanbevolen standaardwaarden.

Gebruik een identiteit met minimale rechten. Log de beleidsversie, het triggerbewijs, de actie, de resource en het resultaat. Bied een onafhankelijke manier om de controller uit te schakelen. Benoem de menselijke verantwoordelijke die een escalatie ontvangt.

Test foutpaden en geslaagd herstel

Een herhaalde poging kan een neveneffect herhalen. Een worker kan een bestand opslaan en stoppen voordat die de job bevestigt. Controleer idempotentie voordat u een nieuwe uitvoering toestaat. Zie het cloud-nativefoutvoorbeeld.

Nieuwe pogingen kunnen een overbelaste dependency ook zwaarder belasten. Gebruik begrensde pogingen, time-outs en passende backoff. Vermijd gelijktijdige herhaalpogingen over alle instanties. AWS legt uit waarom backoff en jitter deze versterking helpen verminderen. Richtlijnen voor herhaalpogingen.

Test het fictieve beleid tegen drie gevallen. Eén gestopte worker moet herstellen. Een database-uitval moet herhaalde vervanging voorkomen. Een onzeker integriteitsprobleem moet automatisering stoppen en om een responsbeslissing vragen.

Controleer ook ontbrekende telemetrie. Een ontbrekende heartbeat kan een uitgevallen worker of een defect verzamelpad betekenen. De controller heeft voldoende bewijs voor zijn actie nodig, geen vertrouwen in een AI-verklaring.

Meet of het beleid helpt

Leg geverifieerd herstel, mislukte pogingen, escalaties, dubbel werk en de duur van gebruikersimpact vast. Vergelijk dit met de vorige beheermethode onder vergelijkbare omstandigheden.

Houd het onderliggende defect als engineeringwerk open. Een proces met een geheugenlek herhaaldelijk herstarten kan de directe impact beperken terwijl het lek blijft bestaan. Ga verder met self-improvement om de waarneming te verbinden met een blijvende correctie.