Stanovte bezpečné hranice automatické obnovy

Obnovujte známý stav

Self-healing automaticky zjistí definované selhání a pokusí se o povolenou akci obnovy. Příkladem může být restart nefunkčního procesu nebo nahrazení instance ve špatném stavu. Akce musí odpovídat selhání a modelu stavu služby.

Kubernetes může nahrazovat nefunkční instance úloh a uvádět skutečný stav do souladu s deklarovaným. Neopravuje tím chybnou aplikační logiku ani každé selhání úložiště. Obnova infrastruktury a správnost softwaru potřebují různé kontroly. Self-healing v Kubernetes.

Cíl definujte před mechanismem. Obnovení exportu znamená, že oprávněné úlohy správně končí. Běžící kontejner je pouze jedním předpokladem.

Oddělte tři druhy změn

Agent může po obnově navrhnout opravu. Tento návrh je novou softwarovou změnou. Nesmí zdědit neomezené pravomoci řídicí komponenty obnovy.

Řídicí komponenta také nesmí upravovat vlastní kritéria úspěchu, když kontrola selže. Jinak může systém hlásit zlepšení bez zlepšení služby.

Pravidla obnovy napište před jejich zapnutím

Následující pravidla jsou fiktivní. Jejich čísla ilustrují návrhové volby; nejde o doporučená výchozí nastavení.

Použijte identitu s nejmenšími oprávněními. Logujte verzi pravidel, důkazy spouštěcí podmínky, akci, prostředek a výsledek. Zajistěte nezávislý způsob vypnutí řídicí komponenty. Určete lidskou odpovědnou osobu, která přijme eskalaci.

Testujte selhání i úspěšnou obnovu

Opakovaný pokus může zopakovat vedlejší účinek. Worker může uložit soubor a zastavit se před potvrzením úlohy. Než dovolíte další provedení, ověřte idempotenci. Viz příklad cloud native selhání.

Opakování může také zesílit přetížení závislosti. Použijte omezený počet pokusů, časové limity a vhodné prodlužování prodlev. Vyhněte se synchronizovaným opakováním napříč instancemi. AWS vysvětluje, proč backoff a jitter pomáhají toto zesílení omezit. Pokyny k opakování.

Fiktivní pravidla otestujte proti třem případům. Jeden zastavený worker se má obnovit. Výpadek databáze má zabránit opakovanému nahrazování. Nejisté selhání integrity má zastavit automatizaci a vyžádat rozhodnutí o reakci.

Prověřte i chybějící telemetrii. Chybějící heartbeat může znamenat selhání workeru nebo sběrné cesty. Řídicí komponenta potřebuje důkazy dostatečné pro svou akci, nikoli pouhou důvěru ve vysvětlení AI.

Měřte, zda pravidla pomáhají

Zaznamenávejte ověřené obnovy, neúspěšné pokusy, eskalace, duplicitní práci a dobu dopadu na uživatele. Porovnejte je s předchozím způsobem provozu za podobných podmínek.

Základní chybu ponechte jako vývojový úkol. Opakované restarty procesu s únikem paměti mohou omezit okamžitý dopad, zatímco únik pokračuje. Pokračujte lekcí o průběžném zlepšování, která propojuje pozorování s trvalou opravou.