Analisi operativo

1) Cos'è un analista operativo e perché è necessario

L'analisi operativo (Ops Analytics) è l'assemblaggio di sistema di segnali da osservazione (metriche/logi/trailer), ITSM (incidenti/problemi/modifiche), CI/CD (rilasci/configi), provider (PSP/KYC/CDN/Cloud), FinOps (costi) e business-SLI (successo dei pagamenti, registrazione), trasformato in vetrine unificate e dashboard decisionali.

• Ridurre il MTTD/MTTR grazie al rilevamento precoce e alla corretta attribuzione delle cause
• tenere SLO e bilancio degli errori sotto controllo;
• Associare le modifiche all'impatto (comunicati/configi, SLI/SLO/reclami/costi);
• dare self-service ai team e al management.

2) Sorgenti e strati di dati canonici

Telemetria: metriche (SLI/risorse), fogli (sempling/redazione PII), roulotte (trace _ id/span _ id, rilascio-tag).
Plugin ITSM/Invident: SEC, Timestamp T0/Detected/Ack/Declared/Mitigated/Recovered, RCA/CAPE.
CI/CD & Config: versioni, committenti, canarico/blue-green, flag state, conferme di destinazione.
Provider: states/SLA, ritardi, codici di errore, peso delle rotte.
FinOps: costo per tag/account/tenenti, $/unità (1k opera.) .
DataOps: freschezza delle vetrine, errori DQ, lineage.

Il principio chiave è la correlazione unificata attraverso gli identificatori: «service», «region», «tenant», «release _ id», «change _ id», «insidioso _ id», «corrender», «trace _ id».

3) Modello di dati unificato (wireframe semplificato)

dim_service(service_id, owner, tier, slo_targets…)
dim_time(ts, date, hour, tz)
dim_region(region_id, country, cloud)
dim_provider(provider_id, type, sla)
fact_sli(ts, service_id, region_id, tenant, metric, value, target, window)
fact_incident(incident_id, service_id, sev, t0, t_detected, t_ack, t_declared, t_mitigated, t_recovered, root_cause, trigger_id, burn_minutes)
fact_change(change_id, type(code    config    infra), service_id, region_id, started_at, finished_at, canary_pct, outcome(ok    rollback), annotations)
fact_cost(ts, service_id, region_id, tenant, cost_total, cost_per_1k)
fact_provider(ts, provider_id, region_id, metric(latency    error    status), value)
fact_dq(ts, dataset, freshness_min, dq_errors)

4) SLI/SLO e metriche aziendali

Бизнес-SLI: `payment_success_ratio`, `signup_completion`, `deposit_latency`.
Тех-SLI: `availability`, `http_p95`, `error_rate`, `queue_depth`.
Livello SLO - Obiettivi + burn-rate (finestra breve/lunga), annotazioni di violazione automatiche.
Normalizzazione: prestazioni per 1k di successo/utenti/traffico.

5) Correlazioni e attribuzione delle cause

Release/configi ↔ SLI/SLO: annotazioni su grafici; rapporti causali (percentuale di incidenti relativi a cambiamenti; MTTR cambio-incidenti).
I provider ↔ SLI aziendali: il peso delle rotte vs latency/errori, il contributo di ogni provider in errori SLO.
Capacità/risorse ritardate, surriscaldamento dei pool, crescita p95, impatto sulla conversione.

6) Anomalie e previsioni

Anomalia-oggetto - Stagionalità + soglie perimetrali + variazioni-finestre di ricerca (prima/dopo il rilascio).
Prognosi: carichi di lavoro settimanali/stagionali, bilancio di bilancio burn-out, predizione dei costi ($/anno) .
Gardreille: alert solo con quorum delle sorgenti (synthetic + RUM + Business SLI).

7) Vetrine e dashboard (arbitro)

1. Executive 28d: SEV mix, mediana MTTR/MTTD, SLO adherence, $/unità, top cause.
2. SRE Ops: SLI/SLO + burn-rate, Page Storm, Actionable %, Change Failure Rate.
3. Le release/confighi sono SLI/SLO/reclami, rimborsi e effetti.
4. Providers: lo stato delle linee PSP/KYC/CDN, gli effetti sul business SLI, i tempi delle risposte.
5. FinOps: cost per 1k txn, logi/egress, anomalie dei costi, raccomandazioni (sempling, conservazione).
6. DataOps: freschezza di vetrine, errori DQ, SLA di pipline, backfill di successo.

8) Qualità dei dati e governance

Contratti eventi: schemi chiari per incidenti/release/SLI (campi obbligatori, fuso orario unico).
Checker DQ: completezza, unicità delle chiavi, timeline non coerente (t0≤detected≤ack...).
Linea da dashbord a sorgente (traceable).
PII/segreti: modifica/maschera per criteri; WORM per l'evidence.
Vetrine Ops ≤ 5 minuti di ritardo.

9) Metriche di maturità degli analisti operativi

Coverage:% di servizi critici in vetrine e bordi SLO (obiettivo 95%).
Freshness: percentuale di widget con una freschezza di 5 min (obiettivo del 95%).
Actionability:% delle transizioni dal dashbord all'azione (playbook/SOP/ticket) sono ≥ al 90%.
Detection Coverage: l' 85% degli incidenti rileva l'automazione.
Attraction Rate è il 90% degli incidenti con causa e trigger confermati.
Change Impact Share - Percentuale di incidenti relativi al cambiamento (controllando il trend).
Data Quality: errori DQ/settimana di .

10) Processo: dai dati alle attività

1. Raccolta, pulizia e normalizzazione della vetrina (ETL/ELT, feature-livello per ML).
2. Rilevamento/previsione dell'escalation per matrice (IC/P1/P2/Comms).
3. Azione: playbook/SOP, uscita-gate, flag-flag, cambio provider.
4. Evidence e AAR/RCA: timeline, grafici, collegamenti a release/logs/roulotte.
5. CAPA e soluzioni alimentari: priorità per i minuti burn e $ -impact.

11) Esempi di query (idea)

11. 1 Impatto delle release SLO (24h)

sql
SELECT r. change_id,
COUNT(i. incident_id) AS incidents,
SUM(i. burn_minutes) AS burn_total_min,
AVG(CASE WHEN i.root_cause='code' THEN 1 ELSE 0 END) AS code_ratio
FROM fact_change r
LEFT JOIN fact_incident i
ON i.trigger_id = r. change_id
WHERE r. started_at >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY burn_total_min DESC;

11. 2 Percentuale di problemi dei provider per regione

sql
SELECT region_id, provider_id,
SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END) AS prov_inc,
COUNT() AS all_inc,
100. 0SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END)/COUNT() AS pct
FROM fact_incident
WHERE t0 >= DATE_TRUNC('month', NOW())
GROUP BY 1,2
ORDER BY pct DESC;

11. 3 Cost per 1k pagamenti riusciti

sql
SELECT date(ts) d,
SUM(cost_total)/NULLIF(SUM(success_payments)/1000. 0,0) AS cost_per_1k
FROM fact_cost c
JOIN biz_payments b USING (ts, service_id, region_id, tenant)
GROUP BY d ORDER BY d DESC;

12) Modelli di manufatti

12. 1 Schema evento incidente (JSON, frammento)

json
{
"incident_id": "2025-11-01-042",
"service": "payments-api",
"region": "eu",
"sev": "SEV-1",
"t0": "2025-11-01T12:04:00Z",
"detected": "2025-11-01T12:07:00Z",
"ack": "2025-11-01T12:09:00Z",
"declared": "2025-11-01T12:11:00Z",
"mitigated": "2025-11-01T12:24:00Z",
"recovered": "2025-11-01T12:48:00Z",
"root_cause": "provider",
"trigger_id": "chg-7842",
"burn_minutes": 18
}

12. 2 Directory delle metriche (YAML, frammento)

yaml metric: biz. payment_success_ratio owner: team-payments type: sli target: 99. 5 windows: ["5m","1h","6h","28d"]
tags: [tier0, region:eu]
pii: false

12. 3 Scheda report Executive (sezioni)

1) SEV mix and MTTR/MTTD trends
2) SLO adherence and burn-out risks
3) Change Impact (CFR)
4) Providers: Degradation and switchover
5) FinOps: $/unit, log anomalies/egress
6) CAPAs: Status and Deadlines

13) Strumenti e pattern architettonici

Data Lake + DWH: livello «crudo» per la telemetria, vetrine per le soluzioni.
Stream processing: near-real-time SLI/burn-rate, in linea per anomalie.
Feature Store - Riutilizzo del fiocco (canarino, stagionalità, provider-segnale).
Semantic Layer/Metric Store: singole definizioni di metriche (SLO, MTTR...).
Access Control: RBAC/ABAC, row-level security per i tenenti/regioni.
Catalog/Lineage: ricerca, descrizione, dipendenze, proprietari.

14) Assegno fogli

14. 1 Avvio degli analisti operativi

• Sono stati approvati i dizionari SLI/SLO, SEC, motivi, tipi di cambiamento.
• Schemi di eventi e timsons unici.
• Connettori di telemetria, ITSM, CI/CD, provider, billing.
• Vetrine: SLI/SLO, Incidents, Changes, Providers, FinOps.
• Executive/SRE/Change/Provider dashboard sono disponibili.
• I quorum-alert e la suppressione sono configurati nelle finestre di servizio.

14. 2 Panoramica Ops settimanale

• trend SEC, MTTR/MTTD, errori SLO, burn-minuto.
• Cambio Impatto e CFR, stato di recupero.
• Incidenti di provider e tempi di reazione.
• FinOps: $/s, anomalie dei loghi/egress.
• CAPO stato, ritardo, priorità.

15) Anti-pattern

«Il muro dei grafici» senza passare alle azioni.
Definizioni di metriche diverse nei comandi (nessun livello semantico).
Nessuna annotazione di release/finestre è una scarsa attribuzione dei motivi.
Orientamento verso la media invece di p95/p99.
Niente normalizzazione sul volume. I grandi servizi sembrano peggiori.
PII nei cassetti/vetrine, violazione delle retene.
I dati vengono «bloccati» (> 5-10 minuti per i widget real-time).

16) Road map di implementazione (4-8 settimane)

1. Ned. 1: accordi per il dizionario delle metriche, schemi di eventi, correlazioni ID connessione SLI/SLO e ITSM.
2. Ned. 2: vetrine Incidents/Changes/Procurers, annotazioni di rilascio; Executive & SRE dashboard.
3. Ned. 3: FinOps strato ($/a) , collegamento con la SLI; anomalia-oggetto con quorum.
4. Ned. 4: self-service (semantic layer/metric store), catalogo e lineage.
5. Ned. 5-6: previsione di carico/costo, report ai provider, CAPA-vetrina.
6. Ned. 7-8: copertura del % Tier-0/1, SLA di freschezza, recensioni Ops regolari.

17) Totale

Un analista operativo è una macchina decisionale, ovvero un'unica definizione di metriche, vetrine fresche, una corretta attribuzione delle cause e passaggi diretti a playbook e SOP. In questo sistema, il team rileva e spiega rapidamente le deviazioni, valuta con precisione l'impatto dei lanci e dei provider, gestisce i costi e riduce il rischio di sistema, mentre gli utenti ricevono un servizio stabile.