Postavite sigurne granice samostalnog oporavka
ZavršenoAutomatizujte poznate radnje oporavka uz izričita ovlaštenja, provjeru i uslove zaustavljanja. Odvojite oporavak tokom rada od promjene softvera.
Objavljuje TaigaKako pišemo
Provjerite razumijevanjeKontroler je dvaput ponovo pokrenuo radni proces. Red nastavlja rasti, a baza podataka nije dostupna. Šta politika treba uraditi?Uradite vježbu
Šta ćete naučiti
- Razlikujte samostalni oporavak od trajne ispravke softvera.
- Odredite ograničenu politiku oporavka i nezavisne provjere uspjeha.
- Prepoznajte kada automatizacija mora stati i eskalirati problem.
Oporavite poznato stanje
Samostalni oporavak automatski otkriva određeni neuspjeh i pokušava ovlaštenu radnju oporavka. Primjeri mogu biti ponovno pokretanje procesa koji je otkazao ili zamjena neispravne instance. Radnja mora odgovarati neuspjehu i modelu stanja usluge.
Kubernetes može zamijeniti neuspjele instance radnog opterećenja i uskladiti deklarisano stanje. To ne ispravlja pogrešnu aplikacijsku logiku ni svaki neuspjeh pohrane. Oporavak infrastrukture i tačnost softvera trebaju različite provjere. Kubernetes samostalni oporavak.
Odredite cilj prije mehanizma. Oporavak izvoza znači da se rad koji ispunjava uslove ispravno završava. Kontejner koji radi samo je jedan preduslov.
Odvojite tri vrste promjena
| Promjena | Primjer | Potrebna odluka |
|---|---|---|
| Oporavak tokom rada | Zamjena jednog neuspjelog radnog procesa bez stanja | Unaprijed odobrena politika oporavka može to ovlastiti |
| Ispravka softvera | Ispravka curenja memorije koje zaustavlja radni proces | Pregled, testovi, kontrole izdavanja i produkcijska provjera |
| Promjena politike | Povećanje dozvoljene stope ponovnog pokretanja ili opsega pristupa | Izričito odobrenje osobe odgovorne za politiku |
Agent može predložiti ispravku nakon oporavka. Taj prijedlog je nova promjena softvera. Ne smije naslijediti neograničena ovlaštenja od kontrolera oporavka.
Kontroler također ne smije uređivati vlastite kriterije uspjeha kada provjera ne uspije. Inače sistem može prijaviti poboljšanje bez poboljšanja usluge.
Napišite politiku oporavka prije uključivanja
Sljedeća politika je izmišljena. Njeni brojevi ilustruju dizajnerske izbore; nisu preporučene podrazumijevane vrijednosti.
| Polje politike | Izmišljeno pravilo za radni proces izvoza |
|---|---|
| Povod | Signal rada radnog procesa izostaje 90 sekundi i postoji rad u redu čekanja |
| Preduslovi | Drugi radni proces je ispravan; provjere zavisnosti prolaze; nema sumnje na kompromitovanje ili problem integriteta |
| Dozvoljena radnja | Zamjena jednog radnog procesa trenutno odobrenim artefaktom |
| Zaštita stanja | Zadaci koriste trajnu pohranu i provjeren ključ idempotentnosti |
| Ograničenje | Najviše dvije zamjene u 15 minuta; nikada više od jedne istovremeno |
| Period čekanja | Čekajte pet minuta nakon zamjene prije drugog pokušaja |
| Uspjeh | Sintetički zadatak ispravno završava i zahvaćeni red počinje se prazniti |
| Zaustavljanje i eskalacija | Bilo koji preduslov nije ispunjen, dostignuto je ograničenje ili se uspjeh ne može provjeriti |
Koristite identitet s najmanjim potrebnim privilegijama. Bilježite verziju politike, dokaze povoda, radnju, resurs i rezultat. Omogućite nezavisan način isključivanja kontrolera. Odredite osobu koja prima eskalaciju.
Testirajte neuspjehe kao i uspješan oporavak
Ponovni pokušaj može ponoviti sporedni učinak. Radni proces može pohraniti fajl i stati prije potvrde zadatka. Provjerite idempotentnost prije dozvole za drugo izvršavanje. Pogledajte primjer cloud native neuspjeha.
Ponovni pokušaji mogu dodatno opteretiti preopterećenu zavisnost. Koristite ograničene pokušaje, vremenska ograničenja i odgovarajuće odgađanje. Izbjegavajte istovremene ponovne pokušaje kroz sve instance. AWS objašnjava zašto odgađanje i nasumična odstupanja pomažu smanjiti ovaj učinak. Smjernice za ponovne pokušaje.
Testirajte izmišljenu politiku na tri slučaja. Jedan zaustavljeni radni proces treba se oporaviti. Nedostupnost baze podataka treba spriječiti ponovljenu zamjenu. Neizvjestan problem integriteta treba zaustaviti automatizaciju i zatražiti odluku o odgovoru.
Provjerite i telemetriju koja nedostaje. Izostanak signala rada može značiti neuspjeli radni proces ili neispravan put prikupljanja. Kontroler treba dokaze dovoljne za svoju radnju, a ne povjerenje u AI objašnjenje.
Mjerite pomaže li politika
Bilježite provjerene oporavke, neuspješne pokušaje, eskalacije, duplirani rad i vrijeme tokom kojeg su korisnici zahvaćeni. Uporedite ih s prethodnom metodom rada u sličnim uslovima.
Zadržite osnovnu grešku kao inženjerski zadatak. Ponovljeno pokretanje procesa s curenjem memorije može smanjiti neposredni utjecaj dok curenje traje. Nastavite sa samopoboljšavanjem da povežete zapažanje s trajnom ispravkom.
Uradite vježbu
Osmislite politiku oporavka za izmišljeni radni proces izvoza iz ove lekcije. Navedite povod, izuzetke, dozvoljenu radnju, ograničenje ponovnih pokušaja, period čekanja, provjeru uspjeha i osobu kojoj se problem eskalira. Testirajte je pri nedostupnoj bazi podataka i nepoznatom problemu integriteta podataka.
Preuzmite radni list (Markdown)Isključivanjem ove opcije briše se sav napredak sačuvan u ovom pregledniku.
Napredak ostaje u ovom pregledniku. Bez računa i praćenja.
Izvori i dodatno čitanje
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗