Stabiliți limite sigure pentru recuperarea automată

Restabiliți o stare cunoscută

Recuperarea automată detectează o defecțiune definită și încearcă o acțiune autorizată de recuperare. Repornirea unui proces defect sau înlocuirea unei instanțe care nu funcționează corect sunt exemple posibile. Acțiunea trebuie să corespundă defecțiunii și modelului de stare al serviciului.

Kubernetes poate înlocui instanțe de lucru defecte și reconcilia starea declarată. Aceasta nu corectează logica defectuoasă a aplicației sau orice defecțiune de stocare. Recuperarea infrastructurii și corectitudinea software-ului necesită verificări diferite. Recuperarea automată Kubernetes.

Definiți obiectivul înaintea mecanismului. Restabilirea unui export înseamnă că lucrul eligibil se termină corect. Un container care rulează este doar o precondiție.

Separați trei tipuri de modificare

Un agent poate propune o corecție după recuperare. Propunerea este o modificare software nouă. Nu trebuie să moștenească autoritate nelimitată de la controllerul de recuperare.

Controllerul nu trebuie nici să își editeze propriile criterii de reușită când o verificare eșuează. Altfel, sistemul poate raporta o îmbunătățire fără a îmbunătăți serviciul.

Scrieți politica de recuperare înainte de activare

Politica următoare este fictivă. Numerele sale ilustrează alegeri de proiectare; nu sunt valori implicite recomandate.

Folosiți o identitate cu privilegii minime. Consemnați versiunea politicii, dovezile declanșatorului, acțiunea, resursa și rezultatul. Oferiți o metodă independentă de dezactivare a controllerului. Definiți responsabilul uman care primește escaladarea.

Testați căile de eșec și recuperarea reușită

O reîncercare poate repeta un efect secundar. Un worker poate stoca un fișier și se poate opri înainte de confirmarea jobului. Verificați idempotența înainte de a permite altă execuție. Consultați exemplul de defecțiune cloud native.

Reîncercările pot și amplifica supraîncărcarea unei dependențe. Folosiți încercări limitate, timpi maximi de așteptare și întârzieri adecvate. Evitați reîncercările sincronizate în toate instanțele. AWS explică de ce backoff și jitter ajută la reducerea acestei amplificări. Ghidul reîncercărilor.

Testați politica fictivă pe trei cazuri. Un singur worker oprit trebuie recuperat. O întrerupere a bazei de date trebuie să împiedice înlocuirile repetate. O problemă incertă de integritate trebuie să oprească automatizarea și să ceară o decizie de răspuns.

Verificați și telemetria lipsă. Absența unui heartbeat poate însemna un worker defect sau o cale de colectare defectă. Controllerul are nevoie de dovezi suficiente pentru acțiunea sa, nu de încredere într-o explicație AI.

Măsurați dacă politica ajută

Consemnați recuperările verificate, încercările nereușite, escaladările, lucrul duplicat și timpul în care utilizatorii au fost afectați. Comparați-le cu metoda anterioară de operare, în condiții similare.

Păstrați defectul de bază ca lucru de inginerie. Repornirea repetată a unui proces cu pierderi de memorie poate reduce impactul imediat, în timp ce pierderea continuă. Continuați cu îmbunătățirea sistemului prin feedback pentru a lega observația de o corecție durabilă.