Regole di Business - Observability

Questo documento elenca le regole di business fondamentali del dominio Observability, identificate con codice univoco BR-NNN. Ogni regola è technology-independent (vale su Prometheus, OpenTelemetry, qualsiasi backend) e descrive un vincolo invariante sul comportamento del sistema di osservabilità.

---

BR-001 - Strumentazione obbligatoria dei segnali critici

Codice: BR-001 Nome: Ogni servizio espone i Golden Signals Descrizione: Ogni Service strumentato deve emettere almeno i Golden Signals (latenza, traffico, errori, saturazione) - o equivalenti RED (Rate, Errors, Duration) / USE (Utilization, Saturation, Errors). Un servizio non strumentato è una zona cieca. Motivazione: Senza segnali non c'è osservabilità; i Golden Signals sono il minimo per diagnosticare la salute. Priorità: ALTA Attori: Service Owner, Instrumentation Layer Tracciabilità: Golden Signals, Metodo RED, Metodo USE (glossary); instrument-service.md.

---

BR-002 - Propagazione del contesto end-to-end

Codice: BR-002 Nome: Ogni richiesta propaga il trace context tra i servizi Descrizione: Ogni Span generato in una richiesta distribuita deve propagare il TraceContext (W3C Trace Context) ai servizi a valle, così che tutti gli span appartengano alla stessa Trace. Una propagazione interrotta spezza la traccia. Motivazione: Correlare l'intera richiesta attraverso i confini di servizio. Priorità: ALTA Attori: Instrumentation Layer, Service Owner Violazione: trace orfane (span senza parent), diagnosi impossibile cross-service. Tracciabilità: Propagazione del contesto, W3C Trace Context (glossary); instrument-service.md.

---

BR-003 - Cardinalità delle metriche sotto controllo

Codice: BR-003 Nome: Le label delle metriche non hanno cardinalità illimitata Descrizione: Nessuna Metric deve usare come label valori ad alta cardinalità non limitata (es. user ID, request ID, timestamp). L'esplosione di cardinalità fa crescere le serie temporali fino a saturare il backend. Motivazione: Prevenire il crash del backend delle metriche e contenere i costi. Priorità: ALTA Attori: Service Owner, Telemetry Backend Violazione: esplosione di cardinalità → degrado o crash del backend. Tracciabilità: Cardinalità, Esplosione di cardinalità (glossary); domain-faq.md.

---

BR-004 - SLO con error budget espliciti

Codice: BR-004 Nome: Ogni servizio critico ha SLI, SLO ed error budget definiti Descrizione: Ogni Service critico deve avere SLI misurabili, SLO target dichiarati e un ErrorBudget derivato. Le decisioni operative (rilasci, alerting) si basano sul consumo dell'error budget, non su soglie arbitrarie. Motivazione: Bilanciare affidabilità e velocità di sviluppo in modo misurabile. Priorità: ALTA Attori: SRE, Service Owner Tracciabilità: SLI, SLO, Error Budget (glossary); define-slo.md.

---

BR-005 - Alert azionabili e basati su sintomi

Codice: BR-005 Nome: Un alert si attiva su un sintomo che richiede azione umana Descrizione: Ogni Alert deve segnalare un sintomo rilevante per l'utente (es. burn rate dell'error budget elevato) e richiedere un'azione. Sono vietati gli alert su cause senza impatto o quelli che non richiedono intervento (rumore). Motivazione: Evitare la fatica da alert; ogni notifica deve meritare attenzione. Priorità: ALTA Attori: SRE, Alerting Engine Tracciabilità: Alerting, Burn Rate (glossary); evaluate-alert.md.

---

BR-006 - I tre segnali sono correlabili

Codice: BR-006 Nome: Metriche, log e tracce condividono identificatori di correlazione Descrizione: I tre pilastri (Metric, Log, Trace) devono essere correlabili tramite identificatori comuni (trace_id, service.name, exemplar). Da un alert metrico si deve poter risalire alle tracce e ai log rilevanti. Motivazione: Ridurre l'MTTR navigando tra segnali durante un incident. Priorità: ALTA Attori: Instrumentation Layer, SRE Tracciabilità: Correlazione, Exemplar (glossary); domain-faq.md.

---

BR-007 - Convenzioni semantiche e logging strutturato

Codice: BR-007 Nome: Telemetria con attributi semantici standard e log strutturati Descrizione: La telemetria deve usare le Semantic Conventions (attributi Resource standard come service.name, service.version) e i log devono essere strutturati (JSON con campi tipizzati), non testo libero. Questo rende i segnali interrogabili e correlabili. Motivazione: Interoperabilità tra strumenti e query affidabili. Priorità: MEDIA Attori: Instrumentation Layer, Service Owner Tracciabilità: Semantic Conventions, Logging strutturato, Resource (glossary).

---

BR-008 - Campionamento e retention governati dal costo

Codice: BR-008 Nome: Sampling e retention sono dimensionati sul valore del segnale Descrizione: Il Sampling (head o tail-based) e la Retention dei segnali devono bilanciare osservabilità e costo: si conserva ad alta fedeltà ciò che ha valore diagnostico (errori, code di latenza) e si campiona o si riduce la retention del resto. Motivazione: Mantenere l'osservabilità sostenibile economicamente. Priorità: MEDIA Attori: SRE, Telemetry Backend Tracciabilità: Campionamento head/tail-based, Retention (glossary); domain-faq.md.