Template per Runbook Incident e On-Call in Word
Dai a chi è di turno un runbook che funziona alle 3 di notte: sintomi, diagnosi passo-passo, comandi pronti, soglie di escalation e procedura di rollback, in un documento Word ordinato.
Esempio di output
# Runbook — [Servizio]: latenza elevata sull'API ## Metadati | Campo | Valore | |---|---| | Severità tipica | SEV-2 | | Owner | [team] | | Ultimo aggiornamento | [data] | ## 1. Sintomi - Alert: p95 > [soglia] per >5 min - Utenti segnalano timeout sul checkout ## 2. Diagnosi rapida (in ordine) 1. Verifica lo stato del servizio ``` kubectl get pods -n [namespace] | grep [servizio] ``` 2. Controlla la latenza a valle (DB, cache) ``` [comando metriche] ``` Attendi: latenza DB < [soglia]. Se superiore → vai a sez. 3b. ## 3. Azioni di mitigazione ### 3a. Restart pod degradati ``` kubectl rollout restart deploy/[servizio] -n [namespace] ``` ### 3b. Connessioni DB sature - Aumenta temporaneamente il pool: [come] ## 4. Criteri di escalation | Condizione | Azione | Chi | |---|---|---| | Nessun miglioramento in 15 min | Escalation a SEV-1 | On-call lead | | Perdita dati sospetta | Coinvolgi DBA | [contatto] | ## 5. Rollback ``` kubectl rollout undo deploy/[servizio] -n [namespace] ``` Verifica: p95 torna < [soglia] entro 5 min. ## 6. Comunicazione Template stato: "Stiamo indagando su rallentamenti su [servizio]. Prossimo update tra 30 min." ## 7. Checklist post-incident - [ ] Timeline ricostruita - [ ] Root cause identificata - [ ] Action item con owner e scadenza - [ ] Runbook aggiornato
Domande frequenti
È la procedura operativa che chi è di turno segue durante un incidente specifico, senza dover ragionare da zero sotto stress. Questo prompt lo struttura per un singolo scenario (es. 'database lento', 'coda intasata') con diagnosi, azioni e criteri di decisione espliciti.
Sì, in blocchi di codice con il contesto (dove eseguirli, cosa aspettarsi come output). Dove un comando dipende dal tuo ambiente, usa placeholder espliciti tipo [host] o [nome-servizio] invece di inventare valori che potrebbero essere distruttivi.
Sì. Include criteri chiari di quando e a chi fare escalation, un modello di comunicazione per gli stakeholder durante l'incidente e una checklist post-incident per il follow-up. Sono spesso le parti che mancano e che fanno la differenza nella gestione reale.
Vuoi un template su misura?
Costruiscine uno in poche domande — con la struttura corretta per il tuo standard.