Sett trygge grenser for self-healing

Gjenopprett en kjent tilstand

Self-healing oppdager automatisk en definert feil og forsøker en autorisert gjenopprettingshandling. Eksempler kan være å starte en mislykket prosess på nytt eller erstatte en instans som ikke fungerer som den skal. Handlingen må passe til feilen og tjenestens tilstandsmodell.

Kubernetes kan erstatte arbeidslastinstanser som har feilet, og avstemme deklarert tilstand. Dette retter ikke feil applikasjonslogikk eller alle lagringsfeil. Gjenoppretting av infrastruktur og korrekt programvare trenger ulike kontroller. Kubernetes self-healing.

Definer målet før mekanismen. Å gjenopprette en eksport betyr at gyldig arbeid fullføres riktig. En kjørende container er bare én forutsetning.

Skill mellom tre typer endring

En agent kan foreslå en retting etter gjenoppretting. Forslaget er en ny programvareendring. Det må ikke arve ubegrensede fullmakter fra gjenopprettingskontrolleren.

Kontrolleren må heller ikke redigere sine egne suksesskriterier når en kontroll feiler. Ellers kan systemet rapportere forbedring uten å forbedre tjenesten.

Skriv gjenopprettingspolicyen før den aktiveres

Policyen nedenfor er fiktiv. Tallene illustrerer designvalg; de er ikke anbefalte standardverdier.

Bruk en identitet med minst mulige rettigheter. Logg policyversjon, bevis for utløseren, handling, ressurs og resultat. Tilby en uavhengig måte å deaktivere kontrolleren på. Definer den menneskelige eieren som mottar en eskalering.

Test feilveier i tillegg til vellykket gjenoppretting

Et nytt forsøk kan gjenta en sideeffekt. En arbeider kan lagre en fil og stoppe før den kvitterer for jobben. Verifiser idempotens før dere tillater en ny kjøring. Se cloud native-eksemplet på feil.

Nye forsøk kan også forsterke belastningen på en overbelastet avhengighet. Bruk et avgrenset antall forsøk, tidsavbrudd og passende økning i ventetid. Unngå synkroniserte nye forsøk på tvers av alle instanser. AWS forklarer hvorfor backoff og jitter bidrar til å redusere denne forsterkningen. Veiledning om nye forsøk.

Test den fiktive policyen mot tre tilfeller. Én stoppet arbeider bør gjenopprettes. Et databaseavbrudd bør hindre gjentatt utskifting. En usikker integritetsfeil bør stoppe automatiseringen og be om en responsbeslutning.

Kontroller også manglende telemetri. Fravær av livstegn kan bety en mislykket arbeider eller en mislykket innsamlingsvei. Kontrolleren trenger tilstrekkelige bevis for handlingen, ikke tillit til en AI-forklaring.

Mål om policyen hjelper

Registrer verifiserte gjenopprettinger, mislykkede forsøk, eskaleringer, duplisert arbeid og tid med brukerinnvirkning. Sammenlign dette med den tidligere driftsmåten under lignende forhold.

Behold den underliggende feilen som utviklingsarbeid. Gjentatte omstarter av en prosess med minnelekkasje kan redusere den umiddelbare innvirkningen mens lekkasjen fortsetter. Fortsett med self-improvement for å knytte observasjonen til en varig retting.