Postavite sigurne granice za self-healing

Oporavite se od poznatog stanja

Self-healing automatski otkriva definiran kvar i pokušava provesti ovlaštenu radnju oporavka. Primjeri mogu biti ponovno pokretanje neuspjelog procesa ili zamjena instance koja ne radi ispravno. Radnja mora odgovarati kvaru i modelu stanja usluge.

Kubernetes može zamijeniti neuspjele instance radnog opterećenja i uskladiti stanje s deklariranim stanjem. To ne ispravlja pogrešnu logiku aplikacije ni svaki kvar pohrane. Oporavak infrastrukture i ispravnost softvera trebaju različite provjere. Kubernetes self-healing.

Odredite cilj prije mehanizma. Obnova izvoza znači da se rad koji ispunjava uvjete ispravno dovršava. Pokrenut kontejner samo je jedan preduvjet.

Odvojite tri vrste promjena

Agent može predložiti ispravak nakon oporavka. Taj prijedlog nova je promjena softvera. Ne smije naslijediti neograničene ovlasti kontrolera oporavka.

Kontroler također ne smije uređivati vlastite kriterije uspjeha kada provjera ne uspije. Inače sustav može prijaviti poboljšanje bez poboljšanja usluge.

Napišite pravilo oporavka prije uključivanja

Sljedeće je pravilo izmišljeno. Brojevi prikazuju odluke o dizajnu; nisu preporučene standardne postavke.

Upotrijebite identitet s najmanjim potrebnim ovlastima. Zabilježite verziju pravila, dokaze okidača, radnju, resurs i rezultat. Osigurajte neovisan način isključivanja kontrolera. Odredite odgovornu osobu koja prima eskalaciju.

Testirajte putove kvara i uspješan oporavak

Ponovni pokušaj može ponoviti nuspojavu. Radni proces može spremiti datoteku i stati prije potvrde zadatka. Provjerite idempotentnost prije dopuštanja novog izvršavanja. Pogledajte primjer cloud native kvara.

Ponovni pokušaji mogu dodatno opteretiti već preopterećenu ovisnost. Upotrijebite ograničene pokušaje, vremenska ograničenja i prikladno povećavanje odgode. Izbjegavajte sinkronizirane ponovne pokušaje kroz cijelu skupinu instanci. AWS objašnjava zašto povećavanje odgode i slučajni pomak pomažu smanjiti to pojačavanje. Smjernice za ponovne pokušaje.

Testirajte izmišljeno pravilo u tri slučaja. Jedan zaustavljeni radni proces trebao bi se oporaviti. Nedostupnost baze podataka trebala bi spriječiti ponovljenu zamjenu. Nejasna pogreška integriteta trebala bi zaustaviti automatizaciju i zatražiti odluku o reakciji.

Provjerite i nedostajuću telemetriju. Izostanak signala aktivnosti može značiti kvar radnog procesa ili puta prikupljanja. Kontroler treba dovoljno dokaza za svoju radnju, a ne povjerenje u AI objašnjenje.

Izmjerite pomaže li pravilo

Zabilježite provjerene oporavke, neuspjele pokušaje, eskalacije, udvostručen rad i vrijeme tijekom kojeg su korisnici bili zahvaćeni. Usporedite to s prethodnim načinom rada u sličnim uvjetima.

Zadržite temeljni nedostatak kao inženjerski zadatak. Ponavljano pokretanje procesa iz kojeg curi memorija može smanjiti neposredni učinak dok se curenje nastavlja. Nastavite sa samopoboljšavanjem kako biste povezali opažanje s trajnim ispravkom.