Report uptime e controllo SLA

1) Perché è necessario un processo di reporting formale

La fiducia dei clienti e la trasparenza contrattuale sono una metodologia di misurazione, calcoli ripetuti.
Gestione SLO e bilancio degli errori: collegamento tra disponibilità e release e incidenti.
I prestiti SLA corretti sono formule oggettive, pagamenti prevedibili/pagamenti.
La sostenibilità legale è una base di prova, un controllo indipendente, Legale Hold.

2) Termini e bordi

SLI Availability è la percentuale di verifiche/transazioni riuscite durante il periodo.
SLO è un obiettivo interno (ad esempio 99. 95% in 28 giorni).
SLA è un impegno esterno (ad esempio 99. 9 %/mese + prestiti di servizio).
La finestra di misurazione è il mese di calendario (SLA) e le finestre di rolling (SLO).
Scope - Quali componenti sono inclusi (edge, API, pagamenti) e quali no (portale, no-prod).

3) Fonti di verità (e quando qual è il capo)

1. Sintetica (blackbox/headless) è un SLI primario per «accessibilità con gli occhi dell'utente».
2. Loghi/metriche - conferma la portata e la natura del guasto.
3. Eventi aziendali - Successo dell'operazione (ad esempio, pagamento autorizzato).
4. Stato-pagina - comunicazione pubblica; Controlla i fatti n. 1-3.

Per le discrepanze, la priorità è il sintetico con quorum corretto da regioni ≥2.

4) Metodo di calcolo della disponibilità

4. 1 Formula base

Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)

4. 2 Quorum molto-regionale

L'incidente è contabile se le regioni indipendenti/ASN registrano contemporaneamente un rifiuto.
Raccomandato: N = 2 su 3 (EU/NA/APAC).

4. 3 Tipi di SLI

HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
Business SLI: transazioni di successo/tutti i tentativi (esclusi i guasti client).

4. 4 Eccezioni (documented)

Le finestre maintenance pianificate, annunciate in anticipo N ore e rispettate.
Forza majeure di SLA (ad esempio, il provider di catastrofi IX) - solo in presenza di prove e notifiche pubbliche.
Errori/vincoli client (quota exceeded, 4xx).

5) Criteri di matentenance finestre

Slot temporali concordati nel contratto (ad esempio, vs 02: 00-04: 00 UTC + 0).
I marcatori maintenance = true negli alert/pannelli sono un'eccezione alla SLI.
La soglia di notifica è di almeno 5 giorni lavorativi (o come nel contratto).
Fuori dalla finestra - È considerata l'influenza SLA.

6) valigette Edge e regole di arrotondamento

Brownout (deterioramento parziale) - Conta la percentuale di guasti (weighted downtime) anziché «0/1».
Flapping: unità di contabilità minima - intervallo di prova (ad esempio, 30-60 secondi) + hysteresis (for: 2-5 minuti).
Clock draft: sempre in UTC e ISO-8601; sincronizzazione NTP.

7) Esempi di (sintetico)

promql probe_success{job="blackbox-http"} == 1

promql histogram_quantile(0.95, sum by (le, target) (rate(probe_http_duration_seconds_bucket[5m])))

promql sum_over_time((probe_success==1)[30d]) / (30246060)

promql sum by (target) (max_over_time((probe_success==0)[3m])) >= 2

8) Esempi SQL (aggregazioni report)

sql with checks as (
select target, ts, success -- success: 1/0 from synthetic_checks where ts >=:from and ts <:to
),
agg as (
select date_trunc('month', ts) m, target,
sum(success)::float / count() as availability from checks group by 1,2
)
select m, target, availability,
(1-availability) extract(epoch from (date_trunc('month', m) + interval '1 month' - date_trunc('month', m))) / 60 as downtime_minutes from agg;

sql select a.m, a.target, a.downtime_minutes, s.incident_id, s.start_utc, s.end_utc from monthly_downtime a left join statuspage_incidents s on a.m = date_trunc('month', s.start_utc)
and tstzrange(s.start_utc, s.end_utc) && daterange(a.m, a.m + interval '1 month');

9) Modello di report mensile (Customer-friendly)

yaml period: "2025-10-01..2025-10-31 (UTC)"
services:
- name: "API Edge"
sla: "99.90%"
measured_availability: "99.93%"
downtime:
total: "30m 14s"
windows:
- start: "2025-10-12T03:12Z"
end:  "2025-10-12T03:38Z"
impact: "EU+NA, HTTP 5xx spike, p95>2s"
root_cause: "DB connection pool exhaustion"
rca_link: "INC-20251012-0312"
slo_budget:
period_target: "0.10%"
consumed: "0.07%"
- name: "Payments API"
sla: "99.95%"
measured_availability: "99.97%"
summary:
sla_breaches: 0 service_credits: 0 maintenance:
announced: 2 total_duration: "48m"
signatures:
generated_at: "2025-11-01T10:00Z"
report_id: "SLA-2025-10-API"

10) prestiti SLA: calcolo e applicazione

La tabella dei prestiti, ad esempio 99. 0–99. 5% → 5% MRR; 98. 0–99. 0% → 10% ecc.
True-up: il credito viene applicato come credit note al conto successivo.
Automazione: regola se 'measured _ availability <SLA' → 'credit _ note. create()`».
La vetrina per il client è la scheda portale «SLA credits balance».

11) Controllo, prove e Legale Hold

Trail di controllo: chi/cosa/quando ha calcolato, la versione della metodologia, gli importi di controllo.
Dati raw invariati (append-only) regolazioni - record separati.
Legale Hold: congelamento dell'intervallo di dati (campioni, fogli, schede di incidente, alert).
Replica degli archivi: storage indipendente (WORM/S3 Object Lock).

12) Accoppiamento con pagina pubblica

L'incidente sulla pagina di stato deve avere una timeline e componenti.
Il tempo/scala non corrispondente viene creato discrepance-record ed eseguito da RCA.
Il resoconto del report contiene la sezione Recordation Note.

13) Incidenti e rapporti

A ogni finestra di downtime corrisponde una scheda INC (ID, SEC, proprietario, RCA, CAPE).
Nel report si fa riferimento a INC, breve root cause, stato CAPA.
Per il SEV-1, c'è una distanza di 48 ore dalla chiusura.

14) Controllo della qualità dei dati

Igiene dei campioni:> 99% degli agenti screen di successo, nessun pass> 5 minuti.
Anti-rumore: quorum + multi-window, debounce.
La condensazione dei percorsi/logi viene registrata e documentata.
Test di metodologia: test unit di calcolo, file golden su dati storici.

15) Sicurezza e privacy

TLS/mTLS per ingest, firma pacchetti (HMAC).
Redazione PII nei fogli/rapporti; Il report SLA non deve rivelare i dati personali.
RBAC/ABAC per report; le tracce di accesso sono scritte in un controllo-logo.

16) Dashboard e widget SLO (cosa mostrare)

Overall availability per i servizi mese/trimestre.
Downtime windows con severity e canale dei dettagli.
Errore budget burn (fast/slow) e trend.
Release overlay - Annotazioni di punteggi.
SLA credits forecast - al trend corrente.

17) Piano di implementazione (3 iterazioni)

1. Modello e dati (2 settimane): fissare SLI/SLO/SLA, includere quorum-sintetico, raccogliere «materie prime» in DWH.
2. Calcolo e report (2-3 settimane): formule, SQL/PromQL, modelli YAML/PDF, portale client, crediti auto.
3. Controllo e automazione (3-4 settimane): Legale Hold, reconciazione con pagina di stato, webhoop firmati, regolamenti di display.

18) Assegno-foglio di qualità del report

• Definiti scope, SLI, metodologia e finestra di misurazione.
• Ci sono quorum e multi-window; il flapping viene soppresso.
• Le eccezioni sono documentate.
• Ogni finestra di downtime è associata a INC e RCA.
• I crediti SLA sono stati calcolati e sono riportati nel billing.
• Il report è riproduttivo (versioni di formule/dati).
• Controllo trail e Legale Hold sono inclusi.
• Lo stato della pagina pubblica è stato concordato.

19) Mini FAQ

Perché il sintetico è la fonte principale?
È la più vicina al percorso utente e include un perimetro (DNS/CDN/WAF). Metriche/fogli - chiariscono la causa.

Come si contano i degrado parziali?
Downtime ponderato: percentuale di inattività x durata della finestra, non «tutto o niente».

Dobbiamo tenere i controlli crudi?
Sì, sì. Per controllare e calcolare nuovamente una discussione - raw è obbligatorio.

Totale

I report Uptime e le verifiche SLA non sono una «cifra di fine mese», ma un sistema di misurazione, regole e prove riproduttive: controlli SLI corretti, quorum, formule trasparenti, collegamento con incidenti e bollo, controllo delle eccezioni e Legale Hold. Fissare la metodologia, automatizzare il calcolo e i prestiti, mantenere il trail di verifica e rendere le vostre SLA gestibili, comprensibili e protette.