Establiu límits segurs per a l'autorecuperació

Recupereu una condició coneguda

L’autorecuperació detecta automàticament una fallada definida i intenta una acció de recuperació autoritzada. Reiniciar un procés que ha fallat o substituir una instància que no funciona correctament en poden ser exemples. L’acció ha de ser adequada per a la fallada i per al model d’estat del servei.

Kubernetes pot substituir instàncies fallides de càrregues de treball i reconciliar l’estat declarat. Això no corregeix una lògica d’aplicació defectuosa ni totes les fallades d’emmagatzematge. La recuperació de la infraestructura i el funcionament correcte del programari necessiten comprovacions diferents. Autorecuperació de Kubernetes.

Definiu l’objectiu abans del mecanisme. Restablir una exportació vol dir que la feina que compleix els criteris acaba correctament. Un contenidor en execució només és una de les condicions prèvies.

Separeu tres tipus de canvi

Un agent pot proposar una correcció després de la recuperació. Aquesta proposta és un nou canvi de programari. No ha d’heretar facultats il·limitades del controlador de recuperació.

El controlador tampoc no ha d’editar els seus propis criteris d’èxit quan falla una comprovació. Si ho fes, el sistema podria informar d’una millora sense millorar el servei.

Escriviu la política de recuperació abans d’activar-la

La política següent és fictícia. Les xifres il·lustren decisions de disseny; no són valors predeterminats recomanats.

Feu servir una identitat amb els privilegis mínims. Registreu la versió de la política, les evidències del desencadenant, l’acció, el recurs i el resultat. Proporcioneu una via independent per desactivar el controlador. Definiu el responsable humà que rep l’escalat.

Proveu les vies de fallada i la recuperació reeixida

Un reintent pot repetir un efecte secundari. Un procés de treball podria desar un fitxer i aturar-se abans de confirmar la tasca. Verifiqueu la idempotència abans de permetre una altra execució. Vegeu l’exemple de fallada cloud native.

Els reintents també poden amplificar la sobrecàrrega d’una dependència. Feu servir intents limitats, temps d’espera màxims i pauses progressives adequades. Eviteu els reintents sincronitzats a tot el conjunt de processos. AWS explica per què les pauses progressives i la variació aleatòria ajuden a reduir aquesta amplificació. Directrius sobre reintents.

Proveu la política fictícia amb tres casos. Un únic procés de treball aturat s’hauria de recuperar. Una caiguda de la base de dades hauria d’impedir la substitució repetida. Una fallada d’integritat incerta hauria d’aturar l’automatització i sol·licitar una decisió de resposta.

Comproveu també la telemetria absent. L’absència d’un senyal de vida pot significar una fallada del procés de treball o de la via de recollida. El controlador necessita evidències suficients per a la seva acció, no confiança en una explicació d’IA.

Mesureu si la política ajuda

Registreu les recuperacions verificades, els intents sense èxit, els escalats, la feina duplicada i el temps amb impacte sobre els usuaris. Compareu-los amb el mètode operatiu anterior en condicions similars.

Manteniu el defecte subjacent com a feina d’enginyeria pendent. Reiniciar repetidament un procés amb una fuita pot reduir l’impacte immediat mentre la fuita continua. Continueu amb l’automillora per connectar l’observació amb una correcció duradora.