Sviluppo & Tech Word Avanzato

Template per Specifica di Osservabilità in Word

Un servizio senza osservabilità è una scatola nera che esplode di notte: questo prompt scrive la spec che definisce cosa misurare, quando svegliare qualcuno e quanto budget di errore puoi bruciare.

#observability #slo #sli #tracing #alerting

Usa nel Playbox Personalizza nel wizard

Claude · Anthropic

<role>
Agisci come Site Reliability Engineer senior responsabile della pratica di osservabilità su servizi ad alto traffico, esperto di SLO engineering e gestione degli error budget.
</role>

<task>
Redigi una specifica di osservabilità completa per il servizio indicato, articolata in sezioni: scopo, catalogo SLI, SLO con error budget, logging strutturato, metriche, tracing distribuito, policy di alerting con severità ed escalation, e revisione/ownership.
</task>

<context>
Servizio: [nome servizio]. Architettura: [microservizi/monolite/serverless]. Stack di telemetria disponibile: [strumenti di metriche/log/tracing]. Criticità di business: [impatto di un downtime]. Team on-call: [ruoli/turni]. Requisiti di compliance log: [conservazione/anonimizzazione].
</context>

<output_format>
Documento in markdown con heading H1 per il titolo, H2 per le sezioni numerate, H3 per le sottosezioni. Usa tabelle markdown per SLI, SLO, alerting. Minimo 6 sezioni principali, almeno 5 SLI e 5 allarmi tabellati.
</output_format>

<constraints>
Non presentare target SLO come decisi se non forniti: etichettali '(da validare)'. Niente valori di latenza o traffico inventati come reali. Ogni allarme deve avere severità, canale e owner. Massimo 1.800 parole. Tutto in italiano.
</constraints>

<tone>
Professionale, normativo, da documento di riferimento interno. Frasi brevi e prescrittive.
</tone>

DeepSeek · DeepSeek

Ruolo: Agisci come Site Reliability Engineer senior responsabile della pratica di osservabilità su servizi ad alto traffico, esperto di SLO engineering e gestione degli error budget.

Obiettivo: Redigi una specifica di osservabilità completa per il servizio indicato, articolata in sezioni: scopo, catalogo SLI, SLO con error budget, logging strutturato, metriche, tracing distribuito, policy di alerting con severità ed escalation, e revisione/ownership.

Contesto: Servizio: [nome servizio]. Architettura: [microservizi/monolite/serverless]. Stack di telemetria disponibile: [strumenti di metriche/log/tracing]. Criticità di business: [impatto di un downtime]. Team on-call: [ruoli/turni]. Requisiti di compliance log: [conservazione/anonimizzazione].

Formato output: Documento in markdown con heading H1 per il titolo, H2 per le sezioni numerate, H3 per le sottosezioni. Usa tabelle markdown per SLI, SLO, alerting. Minimo 6 sezioni principali, almeno 5 SLI e 5 allarmi tabellati.

Vincoli & regole: Non presentare target SLO come decisi se non forniti: etichettali '(da validare)'. Niente valori di latenza o traffico inventati come reali. Ogni allarme deve avere severità, canale e owner. Massimo 1.800 parole. Tutto in italiano.

Tono & stile: Professionale, normativo, da documento di riferimento interno. Frasi brevi e prescrittive.

Gemini · Google

## Ruolo
Agisci come Site Reliability Engineer senior responsabile della pratica di osservabilità su servizi ad alto traffico, esperto di SLO engineering e gestione degli error budget.

## Contesto
Servizio: [nome servizio]. Architettura: [microservizi/monolite/serverless]. Stack di telemetria disponibile: [strumenti di metriche/log/tracing]. Criticità di business: [impatto di un downtime]. Team on-call: [ruoli/turni]. Requisiti di compliance log: [conservazione/anonimizzazione].

## Obiettivo
Redigi una specifica di osservabilità completa per il servizio indicato, articolata in sezioni: scopo, catalogo SLI, SLO con error budget, logging strutturato, metriche, tracing distribuito, policy di alerting con severità ed escalation, e revisione/ownership.

## Tono & stile
Professionale, normativo, da documento di riferimento interno. Frasi brevi e prescrittive.

## Formato output
Documento in markdown con heading H1 per il titolo, H2 per le sezioni numerate, H3 per le sottosezioni. Usa tabelle markdown per SLI, SLO, alerting. Minimo 6 sezioni principali, almeno 5 SLI e 5 allarmi tabellati.

## Vincoli & regole
Non presentare target SLO come decisi se non forniti: etichettali '(da validare)'. Niente valori di latenza o traffico inventati come reali. Ogni allarme deve avere severità, canale e owner. Massimo 1.800 parole. Tutto in italiano.

Grok · xAI

## Ruolo
Agisci come Site Reliability Engineer senior responsabile della pratica di osservabilità su servizi ad alto traffico, esperto di SLO engineering e gestione degli error budget.

## Obiettivo
Redigi una specifica di osservabilità completa per il servizio indicato, articolata in sezioni: scopo, catalogo SLI, SLO con error budget, logging strutturato, metriche, tracing distribuito, policy di alerting con severità ed escalation, e revisione/ownership.

## Contesto
Servizio: [nome servizio]. Architettura: [microservizi/monolite/serverless]. Stack di telemetria disponibile: [strumenti di metriche/log/tracing]. Criticità di business: [impatto di un downtime]. Team on-call: [ruoli/turni]. Requisiti di compliance log: [conservazione/anonimizzazione].

## Formato output
Documento in markdown con heading H1 per il titolo, H2 per le sezioni numerate, H3 per le sottosezioni. Usa tabelle markdown per SLI, SLO, alerting. Minimo 6 sezioni principali, almeno 5 SLI e 5 allarmi tabellati.

## Vincoli & regole
Non presentare target SLO come decisi se non forniti: etichettali '(da validare)'. Niente valori di latenza o traffico inventati come reali. Ogni allarme deve avere severità, canale e owner. Massimo 1.800 parole. Tutto in italiano.

## Tono & stile
Professionale, normativo, da documento di riferimento interno. Frasi brevi e prescrittive.

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

Mistral · Mistral AI

## Ruolo
Agisci come Site Reliability Engineer senior responsabile della pratica di osservabilità su servizi ad alto traffico, esperto di SLO engineering e gestione degli error budget.

## Obiettivo
Redigi una specifica di osservabilità completa per il servizio indicato, articolata in sezioni: scopo, catalogo SLI, SLO con error budget, logging strutturato, metriche, tracing distribuito, policy di alerting con severità ed escalation, e revisione/ownership.

## Contesto
Servizio: [nome servizio]. Architettura: [microservizi/monolite/serverless]. Stack di telemetria disponibile: [strumenti di metriche/log/tracing]. Criticità di business: [impatto di un downtime]. Team on-call: [ruoli/turni]. Requisiti di compliance log: [conservazione/anonimizzazione].

## Formato output
Documento in markdown con heading H1 per il titolo, H2 per le sezioni numerate, H3 per le sottosezioni. Usa tabelle markdown per SLI, SLO, alerting. Minimo 6 sezioni principali, almeno 5 SLI e 5 allarmi tabellati.

## Vincoli & regole
Non presentare target SLO come decisi se non forniti: etichettali '(da validare)'. Niente valori di latenza o traffico inventati come reali. Ogni allarme deve avere severità, canale e owner. Massimo 1.800 parole. Tutto in italiano.

## Tono & stile
Professionale, normativo, da documento di riferimento interno. Frasi brevi e prescrittive.

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

ChatGPT · OpenAI

## Ruolo
Agisci come Site Reliability Engineer senior responsabile della pratica di osservabilità su servizi ad alto traffico, esperto di SLO engineering e gestione degli error budget.

## Obiettivo
Redigi una specifica di osservabilità completa per il servizio indicato, articolata in sezioni: scopo, catalogo SLI, SLO con error budget, logging strutturato, metriche, tracing distribuito, policy di alerting con severità ed escalation, e revisione/ownership.

## Contesto
Servizio: [nome servizio]. Architettura: [microservizi/monolite/serverless]. Stack di telemetria disponibile: [strumenti di metriche/log/tracing]. Criticità di business: [impatto di un downtime]. Team on-call: [ruoli/turni]. Requisiti di compliance log: [conservazione/anonimizzazione].

## Formato output
Documento in markdown con heading H1 per il titolo, H2 per le sezioni numerate, H3 per le sottosezioni. Usa tabelle markdown per SLI, SLO, alerting. Minimo 6 sezioni principali, almeno 5 SLI e 5 allarmi tabellati.

## Vincoli & regole
Non presentare target SLO come decisi se non forniti: etichettali '(da validare)'. Niente valori di latenza o traffico inventati come reali. Ogni allarme deve avere severità, canale e owner. Massimo 1.800 parole. Tutto in italiano.

## Tono & stile
Professionale, normativo, da documento di riferimento interno. Frasi brevi e prescrittive.

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

Perplexity · Perplexity

Redigi una specifica di osservabilità completa per il servizio indicato, articolata in sezioni: scopo, catalogo SLI, SLO con error budget, logging strutturato, metriche, tracing distribuito, policy di alerting con severità ed escalation, e revisione/ownership.
Ruolo: Agisci come Site Reliability Engineer senior responsabile della pratica di osservabilità su servizi ad alto traffico, esperto di SLO engineering e gestione degli error budget.
Contesto: Servizio: [nome servizio]. Architettura: [microservizi/monolite/serverless]. Stack di telemetria disponibile: [strumenti di metriche/log/tracing]. Criticità di business: [impatto di un downtime]. Team on-call: [ruoli/turni]. Requisiti di compliance log: [conservazione/anonimizzazione].
Formato output: Documento in markdown con heading H1 per il titolo, H2 per le sezioni numerate, H3 per le sottosezioni. Usa tabelle markdown per SLI, SLO, alerting. Minimo 6 sezioni principali, almeno 5 SLI e 5 allarmi tabellati.
Vincoli & regole: Non presentare target SLO come decisi se non forniti: etichettali '(da validare)'. Niente valori di latenza o traffico inventati come reali. Ogni allarme deve avere severità, canale e owner. Massimo 1.800 parole. Tutto in italiano.
Tono & stile: Professionale, normativo, da documento di riferimento interno. Frasi brevi e prescrittive.

Esempio di output

# Specifica di Osservabilità — [nome servizio]

## 1. Scopo e ambito
Questo documento definisce come [nome servizio] viene osservato in produzione...

## 2. Service Level Indicators (SLI)
| ID | SLI | Definizione | Sorgente metrica | Unità |
|----|-----|-------------|------------------|-------|
| SLI-1 | Disponibilità | richieste 2xx/3xx ÷ totali | gateway | % |
| SLI-2 | Latenza p99 | 99° percentile tempo risposta | app metrics | ms |

## 3. Service Level Objectives (SLO)
| SLI | Target (da validare) | Finestra | Error budget |
|-----|----------------------|----------|--------------|
| SLI-1 | 99,9% | 30 gg | 43 min/mese |

## 4. Logging
### 4.1 Livelli e formato strutturato
...
## 5. Tracing distribuito
### 5.1 Propagazione del contesto
...
## 6. Alerting & escalation
| Allarme | Condizione | Severità | Canale | Owner |
|---------|-----------|----------|--------|-------|
| Burn rate alto | budget consumato >2%/h | P1 | on-call | SRE |

Domande frequenti

Va bene sia per microservizi che per un monolite?

Sì. Specifica nell'architettura il tipo di sistema: la sezione tracing si adatta (propagazione di contesto per microservizi, profiling interno per monoliti) mantenendo la struttura SLI/SLO/alerting.

Definisce gli SLO al posto mio?

Propone valori di riferimento di settore esplicitamente etichettati come 'da validare con il business', e impone di non spacciare target numerici come decisi se non li hai forniti.

Posso incollarlo direttamente in Word?

Sì. L'output usa gerarchia di heading H1/H2/H3 e tabelle in formato che Word riconosce alla conversione, con stili coerenti.

Vuoi un prompt su misura?

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

Crea il tuo prompt