Sviluppo & Tech Word Avanzato

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.

#sviluppo #runbook #incident #on-call #operations

Usa nel Playbox Personalizza nel wizard

Claude · Anthropic

<role>
Agisci come un SRE/On-call Engineer senior che scrive runbook eseguibili sotto pressione, pensati per essere seguiti alle 3 di notte da chi non conosce a fondo il sistema.
</role>

<task>
Scrivi un runbook operativo completo per lo scenario di incidente indicato, con sezioni: metadati (severità, owner), sintomi e segnali, diagnosi passo-passo in ordine di probabilità, azioni di mitigazione con comandi, criteri di escalation, procedura di rollback, comunicazione agli stakeholder e checklist post-incident. La diagnosi deve essere un albero decisionale ordinato.
</task>

<context>
Servizio/sistema: [nome e stack]. Scenario di incidente: [es. latenza elevata, coda intasata, errori 5xx]. Infrastruttura: [es. Kubernetes, VM, serverless]. Strumenti di osservabilità: [es. Grafana, Datadog]. Severità tipica: [SEV-N]. Catena di escalation: [ruoli/contatti]. Dipendenze a valle: [DB, cache, code, terze parti].
</context>

<output_format>
Documento Word: H1 titolo, tabella metadati, H2 per ogni sezione numerata, H3 per i rami di diagnosi/mitigazione. Comandi in blocchi di codice, ciascuno preceduto dal contesto e seguito dall'output atteso. Tabella per i criteri di escalation. Checklist post-incident con caselle di spunta.
</output_format>

<constraints>
Ordina la diagnosi dalla causa più probabile/meno rischiosa alla più rara/rischiosa. Usa placeholder espliciti ([host], [namespace], [soglia]) per ogni valore specifico dell'ambiente: non inventare nomi di host, comandi distruttivi o soglie. Ogni passo di diagnosi deve indicare cosa aspettarsi e dove andare a seconda dell'esito. Includi sempre escalation, rollback e checklist post-incident. Massimo 1.800 parole.
</constraints>

<tone>
Operativo, imperativo, inequivocabile. Frasi brevi, istruzioni numerate, zero ambiguità.
</tone>

DeepSeek · DeepSeek

Ruolo: Agisci come un SRE/On-call Engineer senior che scrive runbook eseguibili sotto pressione, pensati per essere seguiti alle 3 di notte da chi non conosce a fondo il sistema.

Obiettivo: Scrivi un runbook operativo completo per lo scenario di incidente indicato, con sezioni: metadati (severità, owner), sintomi e segnali, diagnosi passo-passo in ordine di probabilità, azioni di mitigazione con comandi, criteri di escalation, procedura di rollback, comunicazione agli stakeholder e checklist post-incident. La diagnosi deve essere un albero decisionale ordinato.

Contesto: Servizio/sistema: [nome e stack]. Scenario di incidente: [es. latenza elevata, coda intasata, errori 5xx]. Infrastruttura: [es. Kubernetes, VM, serverless]. Strumenti di osservabilità: [es. Grafana, Datadog]. Severità tipica: [SEV-N]. Catena di escalation: [ruoli/contatti]. Dipendenze a valle: [DB, cache, code, terze parti].

Formato output: Documento Word: H1 titolo, tabella metadati, H2 per ogni sezione numerata, H3 per i rami di diagnosi/mitigazione. Comandi in blocchi di codice, ciascuno preceduto dal contesto e seguito dall'output atteso. Tabella per i criteri di escalation. Checklist post-incident con caselle di spunta.

Vincoli & regole: Ordina la diagnosi dalla causa più probabile/meno rischiosa alla più rara/rischiosa. Usa placeholder espliciti ([host], [namespace], [soglia]) per ogni valore specifico dell'ambiente: non inventare nomi di host, comandi distruttivi o soglie. Ogni passo di diagnosi deve indicare cosa aspettarsi e dove andare a seconda dell'esito. Includi sempre escalation, rollback e checklist post-incident. Massimo 1.800 parole.

Tono & stile: Operativo, imperativo, inequivocabile. Frasi brevi, istruzioni numerate, zero ambiguità.

Gemini · Google

## Ruolo
Agisci come un SRE/On-call Engineer senior che scrive runbook eseguibili sotto pressione, pensati per essere seguiti alle 3 di notte da chi non conosce a fondo il sistema.

## Contesto
Servizio/sistema: [nome e stack]. Scenario di incidente: [es. latenza elevata, coda intasata, errori 5xx]. Infrastruttura: [es. Kubernetes, VM, serverless]. Strumenti di osservabilità: [es. Grafana, Datadog]. Severità tipica: [SEV-N]. Catena di escalation: [ruoli/contatti]. Dipendenze a valle: [DB, cache, code, terze parti].

## Obiettivo
Scrivi un runbook operativo completo per lo scenario di incidente indicato, con sezioni: metadati (severità, owner), sintomi e segnali, diagnosi passo-passo in ordine di probabilità, azioni di mitigazione con comandi, criteri di escalation, procedura di rollback, comunicazione agli stakeholder e checklist post-incident. La diagnosi deve essere un albero decisionale ordinato.

## Tono & stile
Operativo, imperativo, inequivocabile. Frasi brevi, istruzioni numerate, zero ambiguità.

## Formato output
Documento Word: H1 titolo, tabella metadati, H2 per ogni sezione numerata, H3 per i rami di diagnosi/mitigazione. Comandi in blocchi di codice, ciascuno preceduto dal contesto e seguito dall'output atteso. Tabella per i criteri di escalation. Checklist post-incident con caselle di spunta.

## Vincoli & regole
Ordina la diagnosi dalla causa più probabile/meno rischiosa alla più rara/rischiosa. Usa placeholder espliciti ([host], [namespace], [soglia]) per ogni valore specifico dell'ambiente: non inventare nomi di host, comandi distruttivi o soglie. Ogni passo di diagnosi deve indicare cosa aspettarsi e dove andare a seconda dell'esito. Includi sempre escalation, rollback e checklist post-incident. Massimo 1.800 parole.

Grok · xAI

## Ruolo
Agisci come un SRE/On-call Engineer senior che scrive runbook eseguibili sotto pressione, pensati per essere seguiti alle 3 di notte da chi non conosce a fondo il sistema.

## Tono & stile
Operativo, imperativo, inequivocabile. Frasi brevi, istruzioni numerate, zero ambiguità.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

Mistral · Mistral AI

## Ruolo
Agisci come un SRE/On-call Engineer senior che scrive runbook eseguibili sotto pressione, pensati per essere seguiti alle 3 di notte da chi non conosce a fondo il sistema.

## Tono & stile
Operativo, imperativo, inequivocabile. Frasi brevi, istruzioni numerate, zero ambiguità.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

ChatGPT · OpenAI

## Ruolo
Agisci come un SRE/On-call Engineer senior che scrive runbook eseguibili sotto pressione, pensati per essere seguiti alle 3 di notte da chi non conosce a fondo il sistema.

## Tono & stile
Operativo, imperativo, inequivocabile. Frasi brevi, istruzioni numerate, zero ambiguità.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

Perplexity · Perplexity

Scrivi un runbook operativo completo per lo scenario di incidente indicato, con sezioni: metadati (severità, owner), sintomi e segnali, diagnosi passo-passo in ordine di probabilità, azioni di mitigazione con comandi, criteri di escalation, procedura di rollback, comunicazione agli stakeholder e checklist post-incident. La diagnosi deve essere un albero decisionale ordinato.
Ruolo: Agisci come un SRE/On-call Engineer senior che scrive runbook eseguibili sotto pressione, pensati per essere seguiti alle 3 di notte da chi non conosce a fondo il sistema.
Contesto: Servizio/sistema: [nome e stack]. Scenario di incidente: [es. latenza elevata, coda intasata, errori 5xx]. Infrastruttura: [es. Kubernetes, VM, serverless]. Strumenti di osservabilità: [es. Grafana, Datadog]. Severità tipica: [SEV-N]. Catena di escalation: [ruoli/contatti]. Dipendenze a valle: [DB, cache, code, terze parti].
Formato output: Documento Word: H1 titolo, tabella metadati, H2 per ogni sezione numerata, H3 per i rami di diagnosi/mitigazione. Comandi in blocchi di codice, ciascuno preceduto dal contesto e seguito dall'output atteso. Tabella per i criteri di escalation. Checklist post-incident con caselle di spunta.
Vincoli & regole: Ordina la diagnosi dalla causa più probabile/meno rischiosa alla più rara/rischiosa. Usa placeholder espliciti ([host], [namespace], [soglia]) per ogni valore specifico dell'ambiente: non inventare nomi di host, comandi distruttivi o soglie. Ogni passo di diagnosi deve indicare cosa aspettarsi e dove andare a seconda dell'esito. Includi sempre escalation, rollback e checklist post-incident. Massimo 1.800 parole.
Tono & stile: Operativo, imperativo, inequivocabile. Frasi brevi, istruzioni numerate, zero ambiguità.

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

Per cosa serve esattamente un runbook?

È 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.

Include i comandi da eseguire?

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.

Gestisce escalation e comunicazione?

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 prompt su misura?

Costruiscine uno in poche domande — e adattalo a ogni modello.

Crea il tuo prompt