Določite varne meje samodejne obnove
DokončanoAvtomatizirajte znana obnovitvena dejanja z izrecnimi pooblastili, preverjanjem in pogoji za ustavitev. Obnovo med delovanjem ločite od spreminjanja programske opreme.
Izdajatelj TaigaKako pišemo
Preverite razumevanjeKrmilnik je delovni proces znova zagnal dvakrat. Čakalna vrsta še naprej raste, podatkovna zbirka pa ni dosegljiva. Kaj naj določajo pravila?Opravite vajo
Kaj se boste naučili
- Ločite samodejno obnovo od trajnega popravka programske opreme.
- Določite omejena pravila obnove in neodvisna preverjanja uspeha.
- Prepoznajte, kdaj se mora avtomatizacija ustaviti in eskalirati.
Obnovite znano stanje
Samodejna obnova oziroma self-healing samodejno zazna določeno odpoved in poskusi izvesti odobreno obnovitveno dejanje. Primer je ponovni zagon odpovedanega procesa ali zamenjava nepravilno delujočega primerka. Dejanje mora ustrezati odpovedi in modelu stanja storitve.
Kubernetes lahko zamenja odpovedane primerke delovne obremenitve in uskladi deklarirano stanje. To ne popravi napačne aplikacijske logike ali vsake napake shrambe. Obnova infrastrukture in pravilnost programske opreme potrebujeta različna preverjanja. Samodejna obnova Kubernetes.
Cilj določite pred mehanizmom. Obnova izvoza pomeni, da se upravičeno delo pravilno dokonča. Delujoč vsebnik je samo en predpogoj.
Ločite tri vrste sprememb
| Sprememba | Primer | Potrebna odločitev |
|---|---|---|
| Obnova med delovanjem | Zamenjava enega odpovedanega delovnega procesa brez stanja | To lahko dovolijo vnaprej odobrena pravila obnove |
| Popravek programske opreme | Odprava uhajanja pomnilnika, ki ustavlja delovni proces | Pregled, testi, nadzor izdaje in preverjanje v produkciji |
| Sprememba pravil | Povečanje dovoljene pogostosti ponovnega zagona ali obsega dostopa | Izrecna odobritev odgovornega za pravila |
Agent lahko po obnovi predlaga popravek. Ta predlog je nova sprememba programske opreme. Od obnovitvenega krmilnika ne sme podedovati neomejenih pooblastil.
Krmilnik ob neuspelem preverjanju tudi ne sme urejati lastnih meril uspeha. Sicer lahko sistem poroča o izboljšanju, ne da bi izboljšal storitev.
Pravila obnove napišite pred vklopom
Naslednja pravila so izmišljena. Njihove številke ponazarjajo odločitve o zasnovi; niso priporočene privzete vrednosti.
| Polje pravil | Izmišljeno pravilo za delovni proces izvoza |
|---|---|
| Sprožilec | Signal aktivnosti delovnega procesa manjka 90 sekund in v čakalni vrsti je delo |
| Predpogoji | Drug delovni proces je zdrav; preverjanja odvisnosti uspejo; ni suma vdora ali napake celovitosti |
| Dovoljeno dejanje | Zamenjava enega delovnega procesa s trenutno odobrenim artefaktom |
| Zaščita stanja | Opravila uporabljajo trajno shrambo in preverjen ključ idempotentnosti |
| Omejitev | Največ dve zamenjavi v 15 minutah; nikoli več kot ena hkrati |
| Premor | Po zamenjavi počakajte pet minut pred novim poskusom |
| Uspeh | Sintetično opravilo se pravilno dokonča in prizadeta čakalna vrsta se začne prazniti |
| Ustavitev in eskalacija | Katerikoli predpogoj ni izpolnjen, omejitev je dosežena ali uspeha ni mogoče preveriti |
Uporabite identiteto z najmanjšimi potrebnimi privilegiji. Zabeležite različico pravil, dokaze za sprožilec, dejanje, vir in rezultat. Zagotovite neodvisen način za izklop krmilnika. Določite človeka, odgovornega za prejem eskalacije.
Poleg uspešne obnove preizkusite poti napak
Ponovni poskus lahko ponovi stranski učinek. Delovni proces lahko shrani datoteko in se ustavi pred potrditvijo opravila. Pred dovoljenjem za novo izvedbo preverite idempotentnost. Glejte primer napake cloud native.
Ponovni poskusi lahko povečajo obremenitev že preobremenjene odvisnosti. Uporabite omejeno število poskusov, časovne omejitve in primeren zamik. Izognite se usklajenim sočasnim ponovnim poskusom vseh primerkov. AWS pojasnjuje, zakaj postopno povečevanje zamika in naključni odmik zmanjšata to ojačanje obremenitve. Smernice za ponovne poskuse.
Izmišljena pravila preizkusite v treh primerih. En ustavljen delovni proces naj se obnovi. Izpad podatkovne zbirke naj prepreči ponavljanje zamenjav. Negotova napaka celovitosti naj ustavi avtomatizacijo in zahteva odločitev o odzivu.
Preverite tudi manjkajočo telemetrijo. Odsoten signal aktivnosti lahko pomeni odpoved delovnega procesa ali poti zbiranja. Krmilnik potrebuje dovolj dokazov za svoje dejanje in ne zaupanja v pojasnilo AI.
Izmerite, ali pravila pomagajo
Beležite preverjene obnove, neuspele poskuse, eskalacije, podvojeno delo in čas vpliva na uporabnike. Primerjajte jih s prejšnjim načinom delovanja v podobnih pogojih.
Osnovno napako ohranite kot inženirsko delo. Ponavljanje ponovnega zagona procesa z uhajanjem pomnilnika lahko zmanjša neposredni vpliv, uhajanje pa se nadaljuje. Nadaljujte s samodejnim izboljševanjem, da opažanje povežete s trajnim popravkom.
Opravite vajo
Zasnujte pravila obnove za izmišljeni delovni proces izvoza iz te lekcije. Določite sprožilec, izključitve, dovoljeno dejanje, omejitev ponovnih poskusov, premor, preverjanje uspeha in odgovornega za eskalacijo. Preizkusite jih ob izpadu podatkovne zbirke in neznani napaki celovitosti podatkov.
Prenesi delovni list (Markdown)Če počistite to izbiro, izbrišete ves napredek, shranjen v tem brskalniku.
Napredek ostane v tem brskalniku. Brez računa in sledenja.
Viri in nadaljnje branje
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗