Nosakiet drošas automātiskās atjaunošanas robežas
PabeigtsAutomatizējiet zināmas atjaunošanas darbības ar skaidrām pilnvarām, pārbaudi un apstāšanās nosacījumiem. Atdaliet izpildlaika atjaunošanu no programmatūras maiņas.
Publicē TaigaKā mēs rakstām
Pārbaudiet savu izpratniKontrolieris ir divreiz pārstartējis izpildprocesu. Rinda turpina augt, un datubāze nav sasniedzama. Kas politikai jādara?Izpildiet uzdevumu
Ko apgūsiet
- Atšķiriet automātisku atjaunošanos no pastāvīga programmatūras labojuma.
- Definējiet ierobežotu atjaunošanas politiku un neatkarīgas panākuma pārbaudes.
- Atpazīstiet, kad automatizācijai jāapstājas un jāeskalē.
Atjaunojiet zināmu darbības stāvokli
Automātiska atjaunošanās jeb self-healing atklāj definētu kļūmi un mēģina veikt atļautu atjaunošanas darbību. Piemēri var būt apstājuša procesa pārstartēšana vai bojātas instances aizstāšana. Darbībai jāatbilst kļūmei un pakalpojuma stāvokļa modelim.
Kubernetes var aizstāt bojātas darba slodzes instances un atjaunot atbilstību deklarētajam stāvoklim. Tas neizlabo kļūdainu lietotnes loģiku vai katru glabātuves kļūmi. Infrastruktūras atjaunošanai un programmatūras pareizībai vajag atšķirīgas pārbaudes. Kubernetes automātiska atjaunošanās.
Definējiet mērķi pirms mehānisma. Eksporta atjaunošana nozīmē, ka atbilstošais darbs tiek pareizi pabeigts. Darbojošs konteiners ir tikai viens priekšnosacījums.
Atdaliet trīs izmaiņu veidus
| Izmaiņa | Piemērs | Vajadzīgais lēmums |
|---|---|---|
| Izpildlaika atjaunošana | Aizstāt vienu bojātu bezstāvokļa izpildprocesu | To var atļaut iepriekš apstiprināta atjaunošanas politika |
| Programmatūras labojums | Izlabot atmiņas noplūdi, kas aptur izpildprocesu | Pārskatīšana, testi, laidiena kontroles un pārbaude produkcijas vidē |
| Politikas izmaiņa | Palielināt atļauto pārstartēšanas biežumu vai piekļuves tvērumu | Skaidrs apstiprinājums no par politiku atbildīgā |
Aģents pēc atjaunošanas var piedāvāt labojumu. Šis piedāvājums ir jauna programmatūras izmaiņa. Tas nedrīkst mantot neierobežotas pilnvaras no atjaunošanas kontroliera.
Kontrolieris arī nedrīkst mainīt savus panākuma kritērijus, kad pārbaude neizdodas. Citādi sistēma var ziņot par uzlabojumu, neuzlabojot pakalpojumu.
Uzrakstiet atjaunošanas politiku pirms tās aktivizēšanas
Tālākā politika ir izdomāta. Tās skaitļi ilustrē projektēšanas izvēles; tie nav ieteicami noklusējuma iestatījumi.
| Politikas lauks | Izdomāts eksporta izpildprocesa noteikums |
|---|---|
| Ierosinātājs | Izpildprocesa darbības signāla nav 90 sekundes, un rindā ir darbs |
| Priekšnosacījumi | Cits izpildprocess ir darbspējīgs; atkarību pārbaudes sekmīgas; nav aizdomu par kompromitēšanu vai integritātes kļūmi |
| Atļautā darbība | Aizstāt vienu izpildprocesu ar pašlaik apstiprināto artefaktu |
| Stāvokļa aizsardzība | Uzdevumi izmanto noturīgu glabātuvi un pārbaudītu idempotences atslēgu |
| Limits | Ne vairāk kā divas aizstāšanas 15 minūtēs; nekad vairāk par vienu vienlaikus |
| Nogaidīšanas periods | Pēc aizstāšanas gaidīt piecas minūtes pirms nākamā mēģinājuma |
| Panākums | Sintētisks uzdevums tiek pareizi pabeigts, un ietekmētā rinda sāk sarukt |
| Apstāties un eskalēt | Nav izpildīts jebkurš priekšnosacījums, sasniegts limits vai panākumu nevar pārbaudīt |
Izmantojiet identitāti ar minimālām vajadzīgajām tiesībām. Reģistrējiet politikas versiju, ierosinātāja pierādījumus, darbību, resursu un rezultātu. Nodrošiniet neatkarīgu veidu kontroliera izslēgšanai. Nosakiet cilvēku, kurš saņem eskalāciju.
Pārbaudiet kļūmju ceļus līdzās sekmīgai atjaunošanai
Atkārtots mēģinājums var atkārtot blakusefektu. Izpildprocess var saglabāt failu un apstāties pirms uzdevuma apstiprināšanas. Pārbaudiet idempotenci, pirms atļaujat citu izpildi. Skatiet cloud native kļūmes piemēru.
Atkārtoti mēģinājumi var arī pastiprināt atkarības pārslodzi. Izmantojiet ierobežotu mēģinājumu skaitu, noildzi un atbilstošu aizkavi. Izvairieties no sinhroniem atkārtotiem mēģinājumiem visā sistēmā. AWS skaidro, kā aizkave un tās nejaušās svārstības palīdz mazināt šo pastiprinājumu. Atkārtotu mēģinājumu vadlīnijas.
Pārbaudiet izdomāto politiku trīs gadījumos. Vienam apturētam izpildprocesam jāatjaunojas. Datubāzes pārtraukumam jānovērš atkārtota aizstāšana. Neskaidrai integritātes kļūmei jāaptur automatizācija un jāpieprasa reaģēšanas lēmums.
Pārbaudiet arī trūkstošu telemetriju. Darbības signāla neesība var nozīmēt izpildprocesa kļūmi vai vākšanas ceļa kļūmi. Kontrolierim vajag savai darbībai pietiekamus pierādījumus, nevis pārliecību par MI skaidrojumu.
Mēriet, vai politika palīdz
Reģistrējiet pārbaudītas atjaunošanas, neveiksmīgus mēģinājumus, eskalācijas, dublētu darbu un laiku, kurā lietotāji bija ietekmēti. Salīdziniet tos ar iepriekšējo ekspluatācijas metodi līdzīgos apstākļos.
Saglabājiet pamatā esošo defektu kā izstrādes darbu. Atkārtota procesa ar atmiņas noplūdi pārstartēšana var mazināt tūlītējo ietekmi, kamēr noplūde turpinās. Turpiniet ar automātisku uzlabošanu, lai saistītu novērojumu ar noturīgu labojumu.
Izpildiet uzdevumu
Izstrādājiet atjaunošanas politiku šīs nodarbības izdomātajam eksporta izpildprocesam. Norādiet ierosinātāju, izslēgšanas nosacījumus, atļauto darbību, atkārtojumu limitu, nogaidīšanas periodu, panākuma pārbaudi un par eskalāciju atbildīgo. Pārbaudiet to datubāzes pārtraukuma un nezināmas datu integritātes kļūmes gadījumā.
Lejupielādēt darblapu (Markdown)Noņemot šo atzīmi, tiek dzēsts viss šajā pārlūkā saglabātais progress.
Progress paliek šajā pārlūkā. Bez konta un izsekošanas.
Avoti un papildu lasāmviela
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗