Definisci limiti sicuri per il self-healing

Recupera una condizione nota

Il self-healing rileva automaticamente un guasto definito e tenta un’azione autorizzata di recupero. Riavviare un processo fallito o sostituire un’istanza non sana sono possibili esempi. L’azione deve essere adatta al guasto e al modello di stato del servizio.

Kubernetes può sostituire istanze fallite dei carichi di lavoro e riallineare lo stato dichiarato. Non corregge la logica applicativa difettosa o ogni guasto dello storage. Recupero infrastrutturale e correttezza del software richiedono verifiche diverse. Self-healing di Kubernetes.

Definisci l’obiettivo prima del meccanismo. Ripristinare un’esportazione significa che il lavoro ammesso termina correttamente. Un container in esecuzione è solo una precondizione.

Separa tre tipi di modifica

Un agente può proporre una correzione dopo il recupero. La proposta è una nuova modifica software. Non deve ereditare autorità illimitata dal controller di recupero.

Il controller non deve neppure modificare i propri criteri di successo quando una verifica fallisce. Altrimenti il sistema può dichiarare un miglioramento senza migliorare il servizio.

Scrivi la policy di recupero prima di abilitarla

La policy seguente è fittizia. I numeri illustrano scelte progettuali; non sono valori predefiniti consigliati.

Usa un’identità con privilegi minimi. Registra versione della policy, prove della condizione di avvio, azione, risorsa e risultato. Prevedi un modo indipendente per disabilitare il controller. Definisci il responsabile umano che riceve l’escalation.

Verifica i percorsi di guasto oltre al recupero riuscito

Un nuovo tentativo può ripetere un effetto collaterale. Un worker potrebbe salvare un file e fermarsi prima di confermare il job. Verifica l’idempotenza prima di consentire un’altra esecuzione. Vedi l’esempio di guasto cloud native.

I nuovi tentativi possono anche aggravare il sovraccarico di una dipendenza. Usa tentativi limitati, timeout e backoff adeguato. Evita tentativi sincronizzati tra le istanze. AWS spiega perché backoff e jitter aiutano a ridurre questa amplificazione. Indicazioni sui nuovi tentativi.

Prova la policy fittizia in tre casi. Un solo worker fermo deve recuperare. Un’indisponibilità del database deve impedire sostituzioni ripetute. Un guasto incerto dell’integrità deve fermare l’automazione e richiedere una decisione di risposta.

Controlla anche la telemetria mancante. L’assenza di heartbeat può indicare un worker guasto o un percorso di raccolta guasto. Il controller ha bisogno di prove sufficienti per la sua azione, non di fiducia in una spiegazione AI.

Misura se la policy aiuta

Registra recuperi verificati, tentativi falliti, escalation, lavoro duplicato e durata dell’impatto sugli utenti. Confrontali con il metodo operativo precedente in condizioni simili.

Mantieni il difetto sottostante come lavoro ingegneristico. Riavviare ripetutamente un processo con una perdita di memoria può ridurre l’impatto immediato mentre la perdita continua. Prosegui con il miglioramento automatico per collegare l’osservazione a una correzione duratura.