Sviluppo & Tech Word Avanzato

Template per Postmortem Incidente in Word

Serve a SRE, DevOps e team di ingegneria che devono analizzare un incident senza colpevolizzare e trasformarlo in azioni concrete. Concreto: fornisci cronologia, impatto e fattori contribuenti e ottieni un postmortem strutturato con riepilogo, timeline degli eventi, analisi della causa radice a 5 Whys, tabella delle azioni correttive con owner e priorita e lezioni apprese, pronto per Word.

#postmortem #incident #causa-radice #sre #blameless

Usa nel Playbox Personalizza nel wizard

Claude · Anthropic

<role>
Agisci come un Site Reliability Engineer senior esperto di gestione degli incidenti e redazione di postmortem blameless con analisi della causa radice.
</role>

<task>
Redigi il postmortem dell'incidente: sintetizza gravita, durata e impatto; ricostruisci la timeline degli eventi; conduci un'analisi della causa radice con i 5 Whys fino alla causa sistemica; definisci azioni correttive specifiche con owner (ruolo), categoria e priorita; chiudi con le lezioni apprese e i rischi residui.
</task>

<context>
Incidente: [titolo e breve descrizione]. Gravita: [es. SEV1/SEV2]. Finestra temporale: [inizio e fine, con orari]. Impatto osservato: [servizi/funzioni colpite, utenti impattati, eventuali SLA violati]. Cronologia eventi nota: [sequenza di alert, azioni, rilevamenti con orari]. Fattori contribuenti emersi: [cosa si e capito, es. deploy, cambio config, dipendenza esterna]. Ruoli coinvolti: [es. on-call, backend, DevOps].
</context>

<output_format>
Restituisci un documento Word strutturato a sezioni con heading, pronto da incollare. H1 '1. Riepilogo' (gravita, durata, impatto sintetico); H1 '2. Impatto' (utenti/servizi/SLA); H1 '3. Timeline' con tabella markdown | Orario | Evento | Azione | Attore (ruolo) |; H1 '4. Analisi causa radice - 5 Whys' con catena numerata di domande/risposte e riga finale 'Causa radice:'; H1 '5. Azioni correttive' con tabella | ID | Azione | Categoria (Prevenzione/Rilevamento/Mitigazione) | Owner (ruolo) | Priorita | Stato |; H1 '6. Lezioni apprese' (cosa ha funzionato, cosa no, rischi residui).
</output_format>

<constraints>
Mantieni un taglio blameless: nessuna colpa a persone, gli errori umani vanno riformulati come carenze di processo/automazione. Usa solo gli orari e i fatti forniti per la timeline; non inventare eventi. NON inventare metriche di impatto: dove mancano usa [DA QUANTIFICARE]. La catena dei 5 Whys deve concludersi in una causa sistemica, non in 'errore dell'operatore'. Ogni azione correttiva deve essere specifica e avere owner (ruolo), categoria e priorita. Nessun nome proprio di persone reali, solo ruoli. Tutto in italiano.
</constraints>

<tone>
Professionale, oggettivo, costruttivo e non colpevolizzante.
</tone>

DeepSeek · DeepSeek

Ruolo: Agisci come un Site Reliability Engineer senior esperto di gestione degli incidenti e redazione di postmortem blameless con analisi della causa radice.

Obiettivo: Redigi il postmortem dell'incidente: sintetizza gravita, durata e impatto; ricostruisci la timeline degli eventi; conduci un'analisi della causa radice con i 5 Whys fino alla causa sistemica; definisci azioni correttive specifiche con owner (ruolo), categoria e priorita; chiudi con le lezioni apprese e i rischi residui.

Contesto: Incidente: [titolo e breve descrizione]. Gravita: [es. SEV1/SEV2]. Finestra temporale: [inizio e fine, con orari]. Impatto osservato: [servizi/funzioni colpite, utenti impattati, eventuali SLA violati]. Cronologia eventi nota: [sequenza di alert, azioni, rilevamenti con orari]. Fattori contribuenti emersi: [cosa si e capito, es. deploy, cambio config, dipendenza esterna]. Ruoli coinvolti: [es. on-call, backend, DevOps].

Formato output: Restituisci un documento Word strutturato a sezioni con heading, pronto da incollare. H1 '1. Riepilogo' (gravita, durata, impatto sintetico); H1 '2. Impatto' (utenti/servizi/SLA); H1 '3. Timeline' con tabella markdown | Orario | Evento | Azione | Attore (ruolo) |; H1 '4. Analisi causa radice - 5 Whys' con catena numerata di domande/risposte e riga finale 'Causa radice:'; H1 '5. Azioni correttive' con tabella | ID | Azione | Categoria (Prevenzione/Rilevamento/Mitigazione) | Owner (ruolo) | Priorita | Stato |; H1 '6. Lezioni apprese' (cosa ha funzionato, cosa no, rischi residui).

Vincoli & regole: Mantieni un taglio blameless: nessuna colpa a persone, gli errori umani vanno riformulati come carenze di processo/automazione. Usa solo gli orari e i fatti forniti per la timeline; non inventare eventi. NON inventare metriche di impatto: dove mancano usa [DA QUANTIFICARE]. La catena dei 5 Whys deve concludersi in una causa sistemica, non in 'errore dell'operatore'. Ogni azione correttiva deve essere specifica e avere owner (ruolo), categoria e priorita. Nessun nome proprio di persone reali, solo ruoli. Tutto in italiano.

Tono & stile: Professionale, oggettivo, costruttivo e non colpevolizzante.

Gemini · Google

## Ruolo
Agisci come un Site Reliability Engineer senior esperto di gestione degli incidenti e redazione di postmortem blameless con analisi della causa radice.

## Contesto
Incidente: [titolo e breve descrizione]. Gravita: [es. SEV1/SEV2]. Finestra temporale: [inizio e fine, con orari]. Impatto osservato: [servizi/funzioni colpite, utenti impattati, eventuali SLA violati]. Cronologia eventi nota: [sequenza di alert, azioni, rilevamenti con orari]. Fattori contribuenti emersi: [cosa si e capito, es. deploy, cambio config, dipendenza esterna]. Ruoli coinvolti: [es. on-call, backend, DevOps].

## Obiettivo
Redigi il postmortem dell'incidente: sintetizza gravita, durata e impatto; ricostruisci la timeline degli eventi; conduci un'analisi della causa radice con i 5 Whys fino alla causa sistemica; definisci azioni correttive specifiche con owner (ruolo), categoria e priorita; chiudi con le lezioni apprese e i rischi residui.

## Tono & stile
Professionale, oggettivo, costruttivo e non colpevolizzante.

## Formato output
Restituisci un documento Word strutturato a sezioni con heading, pronto da incollare. H1 '1. Riepilogo' (gravita, durata, impatto sintetico); H1 '2. Impatto' (utenti/servizi/SLA); H1 '3. Timeline' con tabella markdown | Orario | Evento | Azione | Attore (ruolo) |; H1 '4. Analisi causa radice - 5 Whys' con catena numerata di domande/risposte e riga finale 'Causa radice:'; H1 '5. Azioni correttive' con tabella | ID | Azione | Categoria (Prevenzione/Rilevamento/Mitigazione) | Owner (ruolo) | Priorita | Stato |; H1 '6. Lezioni apprese' (cosa ha funzionato, cosa no, rischi residui).

## Vincoli & regole
Mantieni un taglio blameless: nessuna colpa a persone, gli errori umani vanno riformulati come carenze di processo/automazione. Usa solo gli orari e i fatti forniti per la timeline; non inventare eventi. NON inventare metriche di impatto: dove mancano usa [DA QUANTIFICARE]. La catena dei 5 Whys deve concludersi in una causa sistemica, non in 'errore dell'operatore'. Ogni azione correttiva deve essere specifica e avere owner (ruolo), categoria e priorita. Nessun nome proprio di persone reali, solo ruoli. Tutto in italiano.

Grok · xAI

## Ruolo
Agisci come un Site Reliability Engineer senior esperto di gestione degli incidenti e redazione di postmortem blameless con analisi della causa radice.

## Obiettivo
Redigi il postmortem dell'incidente: sintetizza gravita, durata e impatto; ricostruisci la timeline degli eventi; conduci un'analisi della causa radice con i 5 Whys fino alla causa sistemica; definisci azioni correttive specifiche con owner (ruolo), categoria e priorita; chiudi con le lezioni apprese e i rischi residui.

## Contesto
Incidente: [titolo e breve descrizione]. Gravita: [es. SEV1/SEV2]. Finestra temporale: [inizio e fine, con orari]. Impatto osservato: [servizi/funzioni colpite, utenti impattati, eventuali SLA violati]. Cronologia eventi nota: [sequenza di alert, azioni, rilevamenti con orari]. Fattori contribuenti emersi: [cosa si e capito, es. deploy, cambio config, dipendenza esterna]. Ruoli coinvolti: [es. on-call, backend, DevOps].

## Formato output
Restituisci un documento Word strutturato a sezioni con heading, pronto da incollare. H1 '1. Riepilogo' (gravita, durata, impatto sintetico); H1 '2. Impatto' (utenti/servizi/SLA); H1 '3. Timeline' con tabella markdown | Orario | Evento | Azione | Attore (ruolo) |; H1 '4. Analisi causa radice - 5 Whys' con catena numerata di domande/risposte e riga finale 'Causa radice:'; H1 '5. Azioni correttive' con tabella | ID | Azione | Categoria (Prevenzione/Rilevamento/Mitigazione) | Owner (ruolo) | Priorita | Stato |; H1 '6. Lezioni apprese' (cosa ha funzionato, cosa no, rischi residui).

## Vincoli & regole
Mantieni un taglio blameless: nessuna colpa a persone, gli errori umani vanno riformulati come carenze di processo/automazione. Usa solo gli orari e i fatti forniti per la timeline; non inventare eventi. NON inventare metriche di impatto: dove mancano usa [DA QUANTIFICARE]. La catena dei 5 Whys deve concludersi in una causa sistemica, non in 'errore dell'operatore'. Ogni azione correttiva deve essere specifica e avere owner (ruolo), categoria e priorita. Nessun nome proprio di persone reali, solo ruoli. Tutto in italiano.

## Tono & stile
Professionale, oggettivo, costruttivo e non colpevolizzante.

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

Mistral · Mistral AI

## Ruolo
Agisci come un Site Reliability Engineer senior esperto di gestione degli incidenti e redazione di postmortem blameless con analisi della causa radice.

## Obiettivo
Redigi il postmortem dell'incidente: sintetizza gravita, durata e impatto; ricostruisci la timeline degli eventi; conduci un'analisi della causa radice con i 5 Whys fino alla causa sistemica; definisci azioni correttive specifiche con owner (ruolo), categoria e priorita; chiudi con le lezioni apprese e i rischi residui.

## Contesto
Incidente: [titolo e breve descrizione]. Gravita: [es. SEV1/SEV2]. Finestra temporale: [inizio e fine, con orari]. Impatto osservato: [servizi/funzioni colpite, utenti impattati, eventuali SLA violati]. Cronologia eventi nota: [sequenza di alert, azioni, rilevamenti con orari]. Fattori contribuenti emersi: [cosa si e capito, es. deploy, cambio config, dipendenza esterna]. Ruoli coinvolti: [es. on-call, backend, DevOps].

## Formato output
Restituisci un documento Word strutturato a sezioni con heading, pronto da incollare. H1 '1. Riepilogo' (gravita, durata, impatto sintetico); H1 '2. Impatto' (utenti/servizi/SLA); H1 '3. Timeline' con tabella markdown | Orario | Evento | Azione | Attore (ruolo) |; H1 '4. Analisi causa radice - 5 Whys' con catena numerata di domande/risposte e riga finale 'Causa radice:'; H1 '5. Azioni correttive' con tabella | ID | Azione | Categoria (Prevenzione/Rilevamento/Mitigazione) | Owner (ruolo) | Priorita | Stato |; H1 '6. Lezioni apprese' (cosa ha funzionato, cosa no, rischi residui).

## Vincoli & regole
Mantieni un taglio blameless: nessuna colpa a persone, gli errori umani vanno riformulati come carenze di processo/automazione. Usa solo gli orari e i fatti forniti per la timeline; non inventare eventi. NON inventare metriche di impatto: dove mancano usa [DA QUANTIFICARE]. La catena dei 5 Whys deve concludersi in una causa sistemica, non in 'errore dell'operatore'. Ogni azione correttiva deve essere specifica e avere owner (ruolo), categoria e priorita. Nessun nome proprio di persone reali, solo ruoli. Tutto in italiano.

## Tono & stile
Professionale, oggettivo, costruttivo e non colpevolizzante.

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

ChatGPT · OpenAI

## Ruolo
Agisci come un Site Reliability Engineer senior esperto di gestione degli incidenti e redazione di postmortem blameless con analisi della causa radice.

## Obiettivo
Redigi il postmortem dell'incidente: sintetizza gravita, durata e impatto; ricostruisci la timeline degli eventi; conduci un'analisi della causa radice con i 5 Whys fino alla causa sistemica; definisci azioni correttive specifiche con owner (ruolo), categoria e priorita; chiudi con le lezioni apprese e i rischi residui.

## Contesto
Incidente: [titolo e breve descrizione]. Gravita: [es. SEV1/SEV2]. Finestra temporale: [inizio e fine, con orari]. Impatto osservato: [servizi/funzioni colpite, utenti impattati, eventuali SLA violati]. Cronologia eventi nota: [sequenza di alert, azioni, rilevamenti con orari]. Fattori contribuenti emersi: [cosa si e capito, es. deploy, cambio config, dipendenza esterna]. Ruoli coinvolti: [es. on-call, backend, DevOps].

## Formato output
Restituisci un documento Word strutturato a sezioni con heading, pronto da incollare. H1 '1. Riepilogo' (gravita, durata, impatto sintetico); H1 '2. Impatto' (utenti/servizi/SLA); H1 '3. Timeline' con tabella markdown | Orario | Evento | Azione | Attore (ruolo) |; H1 '4. Analisi causa radice - 5 Whys' con catena numerata di domande/risposte e riga finale 'Causa radice:'; H1 '5. Azioni correttive' con tabella | ID | Azione | Categoria (Prevenzione/Rilevamento/Mitigazione) | Owner (ruolo) | Priorita | Stato |; H1 '6. Lezioni apprese' (cosa ha funzionato, cosa no, rischi residui).

## Vincoli & regole
Mantieni un taglio blameless: nessuna colpa a persone, gli errori umani vanno riformulati come carenze di processo/automazione. Usa solo gli orari e i fatti forniti per la timeline; non inventare eventi. NON inventare metriche di impatto: dove mancano usa [DA QUANTIFICARE]. La catena dei 5 Whys deve concludersi in una causa sistemica, non in 'errore dell'operatore'. Ogni azione correttiva deve essere specifica e avere owner (ruolo), categoria e priorita. Nessun nome proprio di persone reali, solo ruoli. Tutto in italiano.

## Tono & stile
Professionale, oggettivo, costruttivo e non colpevolizzante.

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

Perplexity · Perplexity

Redigi il postmortem dell'incidente: sintetizza gravita, durata e impatto; ricostruisci la timeline degli eventi; conduci un'analisi della causa radice con i 5 Whys fino alla causa sistemica; definisci azioni correttive specifiche con owner (ruolo), categoria e priorita; chiudi con le lezioni apprese e i rischi residui.
Ruolo: Agisci come un Site Reliability Engineer senior esperto di gestione degli incidenti e redazione di postmortem blameless con analisi della causa radice.
Contesto: Incidente: [titolo e breve descrizione]. Gravita: [es. SEV1/SEV2]. Finestra temporale: [inizio e fine, con orari]. Impatto osservato: [servizi/funzioni colpite, utenti impattati, eventuali SLA violati]. Cronologia eventi nota: [sequenza di alert, azioni, rilevamenti con orari]. Fattori contribuenti emersi: [cosa si e capito, es. deploy, cambio config, dipendenza esterna]. Ruoli coinvolti: [es. on-call, backend, DevOps].
Formato output: Restituisci un documento Word strutturato a sezioni con heading, pronto da incollare. H1 '1. Riepilogo' (gravita, durata, impatto sintetico); H1 '2. Impatto' (utenti/servizi/SLA); H1 '3. Timeline' con tabella markdown | Orario | Evento | Azione | Attore (ruolo) |; H1 '4. Analisi causa radice - 5 Whys' con catena numerata di domande/risposte e riga finale 'Causa radice:'; H1 '5. Azioni correttive' con tabella | ID | Azione | Categoria (Prevenzione/Rilevamento/Mitigazione) | Owner (ruolo) | Priorita | Stato |; H1 '6. Lezioni apprese' (cosa ha funzionato, cosa no, rischi residui).
Vincoli & regole: Mantieni un taglio blameless: nessuna colpa a persone, gli errori umani vanno riformulati come carenze di processo/automazione. Usa solo gli orari e i fatti forniti per la timeline; non inventare eventi. NON inventare metriche di impatto: dove mancano usa [DA QUANTIFICARE]. La catena dei 5 Whys deve concludersi in una causa sistemica, non in 'errore dell'operatore'. Ogni azione correttiva deve essere specifica e avere owner (ruolo), categoria e priorita. Nessun nome proprio di persone reali, solo ruoli. Tutto in italiano.
Tono & stile: Professionale, oggettivo, costruttivo e non colpevolizzante.

Esempio di output

Postmortem incidente - [Titolo incidente]

1. Riepilogo (H1)
Gravita: [SEV2]. Durata: [data/ora inizio - fine]. Impatto: [es. checkout non disponibile per ~22 minuti].

2. Impatto (H1)
Utenti impattati: [numero o DA QUANTIFICARE]; servizi coinvolti: ...; SLA violato: ...

3. Timeline (H1)
Tabella (markdown):
Orario | Evento | Azione | Attore (ruolo)
14:02 | Picco errori 500 su API ordini | Alert PagerDuty | -
14:08 | Riconosciuto da on-call | Avvio indagine | SRE on-call
14:24 | Rollback deploy v2.3.1 | Servizio ripristinato | SRE on-call

4. Analisi causa radice - 5 Whys (H1)
1. Perche e caduto il checkout? -> errore 500 sull'API ordini
2. Perche errore 500? -> connessioni DB esaurite
3. Perche esaurite? -> nuovo codice apriva connessioni senza chiuderle
4. Perche non rilevato? -> assenza test di carico in pipeline
5. Perche assente? -> stage di performance non previsto nella CI
Causa radice: mancanza di un gate di performance in CI.

5. Azioni correttive (H1)
Tabella:
ID | Azione | Categoria | Owner (ruolo) | Priorita | Stato
AC-1 | Aggiungere connection pool con limite | Prevenzione | Backend Lead | Alta | Aperta
AC-2 | Test di carico in pipeline | Rilevamento | DevOps | Alta | Aperta

6. Lezioni apprese (H1)
Cosa ha funzionato; cosa no; rischi residui.

Domande frequenti

Mantiene l'approccio blameless?

Si: analizza cause sistemiche e di processo, non responsabilita individuali. Non attribuisce colpe a persone e riformula gli errori umani come carenze di processo, automazione o salvaguardie mancanti.

Inventa metriche di impatto?

No: usa solo i dati di durata, utenti impattati e metriche che fornisci. Dove un dato manca usa [DA QUANTIFICARE] invece di stimare numeri non forniti.

Le azioni correttive sono azionabili?

Si: ogni azione e specifica, ha un owner come ruolo, una priorita e una categoria (prevenzione, rilevamento, mitigazione), cosi da essere trasformabile in ticket di backlog.

Vuoi un prompt su misura?

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

Crea il tuo prompt