Affidabilità e auto-riparazione

Sonde

La maggior parte delle sonde deve fallire due volte di seguito prima che si apra un incidente; un container fermo o un database corrotto agiscono al primo fallimento. Una sonda superata azzera il contatore per ogni tipo di incidente che può sollevare.

Il playbook

• Servizio o ascoltatore fermo: riavviare il container e attendere la salute; se i log mostrano un token di chat non valido, passare di livello con lo stralcio invece di riscrivere un token in silenzio.
• Ascoltatore obsoleto due volte in un'ora: passare di livello, perché sembra una regressione più che un intoppo.
• Flusso di eventi o API fermi: ricaricare la configurazione del proxy se valida, riavviare il container e, se un deploy è avvenuto nelle ultime 24 ore, segnalarlo come candidato al rollback.
• Pressione sul disco: compattare il journal, ruotare i log, ripulire lo stato del guardiano.
• Certificato in scadenza: rinnovare e ricaricare il proxy.
• Anti-oscillazione: lo stesso incidente che si ripete più del numero configurato di volte in 24 ore ferma l'auto-riparazione e passa di livello.

Oltre i riavvii

• Un riepilogo giornaliero riassume incidenti e azioni.
• Un test sintetico end-to-end settimanale esercita i flussi reali sullo staging.
• Una sorveglianza logica esegue la suite di test del prodotto stesso sul codice distribuito in un container di sola lettura e la confronta con la baseline verde: un test che era verde ed è ora rosso è una regressione; un test rosso non presente nella baseline è una notifica, non un'azione.
• Una pipeline di correzione autonoma può portare una regressione confermata attraverso una patch circoscritta, test locali, un branch, la CI, lo staging, il test sintetico, il merge e la produzione con un varco di salute e rollback automatico. I segreti sensibili vengono rimossi dal suo ambiente e i percorsi vietati vengono rifiutati.
• Il guardiano gira sotto un supervisore di servizio con un watchdog, così un ciclo in stallo viene riavviato, non solo uno andato in crash.

Dentro il prodotto

• Un outbox durevole del bot: i messaggi di approvazione, gli avvisi in stanza e le loro rimozioni vengono scritti nel database e svuotati dal ciclo, così una decisione presa mentre il bot è fermo viene comunque consegnata.
• I webhook ritentano con backoff e un circuito per endpoint.
• Una scansione notturna riconcilia l'elenco eventi dell'homeserver con il registro dei messaggi del bot e registra ogni messaggio che non è mai entrato; un vuoto si chiude quando il messaggio compare in seguito, e una scansione parziale viene registrata come incompleta anziché pulita.
• Un watchdog della materializzazione avvisa gli admin quando il punteggio in cache più recente ha più di 26 ore o la finestra è coperta in modo insufficiente.
• Il job di sicurezza dell'IA cambia provider quando quello attivo smette di rispondere.
• Ogni job che calcola punteggi gira fuori dall'event loop, così un passaggio lungo non può mai congelare il bot; questo è protetto da un test.