SLA/OLA con provider

1) Termini e bordi

SLI è un indicatore misurabile (disponibilità, latenza p99, webhoop elaborati con successo, RPO/RTO).
SLO - Destinazione SLI per la finestra di misurazione (ad esempio 99. 9 %/30 giorni).
SLA è un documento giuridicamente vincolante (SLO + procedure + rimborso).
OLA - Obiettivi interni e processi che garantiscono il rispetto della SLA.
UC (Underpinning Contract) - Substrato con terzi (canali, data center, CDN, ecc.).

Limiti: separare chiaramente l'area di responsabilità del provider (cloud/WAF/CDN/gateway di pagamento/provider KYC) dalla tua zona (codice, config, impostazioni client).

2) Matrice di criticità e selezione del modello

La matrice dipende dalla profondità della SLA, dalla quantità di controlli e dai requisiti OLA/UC.

3) Metriche e finestre di misurazione

Disponibilità (Availability) - La percentuale di tempo in cui il servizio esegue le richieste in base alle tolleranze.
Latenza: p95/p99 per operazioni chiave; «successo lento» è considerato.
Affidabilità dei dati: RPO (perdita massima di dati consentita) e RTO (tempi di ripristino).
Larghezza di banda/limiti: quote garantite (RPS/MBps).
Qualità delle integrazioni: percentuale di siti Web ≤ X min consegnati, quota di risposte 2xx, ripetizioni e deduplicazione.
Finestra di misurazione: 30 giorni mensili/scorrevoli, eccezioni (lavoro programmato) con limiti.

• `Availability_ext = 1 − (Downtime_confirmed_outages / Total_minutes_in_window)`
• In cui outage è uno stato non disponibile confermato per il monitoraggio esterno e non solo per la pagina di stato del provider.

4) Contenuto SLA (modello di partizione)

1. Oggetto e ambito (servizi, regioni, versioni API).
2. Definizioni (SLI/SLO, «incidente», «lavoro programmato», «forza maggiore»).
3. Obiettivi del servizio (SLO) per categoria di richieste e regione.
4. Il monitoraggio e la prova, in che modo, con quali sensori, con quale frequenza.
5. Incidenti e escalation: canali, tempi di risposta/aggiornamenti, ruoli.
6. Rimborsi: prestiti/multe/bonus, soglie, formule.
7. Sicurezza e privacy: DPA, crittografia, registri, segnalazioni di violazioni.
8. Modifiche al servizio: deprecati, finestra di notifica, compatibilità.
9. Continuità e DR: RPO/RTO, test di ripristino.
10. Controllo e compilazione: facoltà di verifica, rendicontazione, certificazione.
11. Exit Plan esporta i dati, i tempi, il formato e la migrazione.
12. Disposizioni legali: giurisdizione, forza maggiore, riservatezza, scadenza.

5) Esempi di formulazione (sezioni)

5. 1 Disponibilità e misurazione

"Il provider fornisce 99. 95% di disponibilità per mese di calendario. La disponibilità è misurata da un monitoraggio sintetico esterno del Cliente di regioni ≥3 a un intervallo di ≤1 min. L'indisponibilità registrata in regioni ≥2 è considerata contemporaneamente un incidente di livello SEV2 e viene registrata in Downtime"

5. 2 Latitanza API chiave

"p99 tempo di risposta" POST/payments/authorize ", 450 ms nel 95% dei giorni del mese. Per la percentuale di richieste oltre la soglia viene fornito un report di analisi delle cause

5. 3 Incidenti e escalation

"S1: ack 15 minuti, update ogni 30 minuti, recupero mirato 2 ore; S2: ack 30 min, update 60 min; S3: giorno lavorativo successivo. Telefono 24 x 7, chat bridge, email"

5. 4 Rimborsi (prestiti)

If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%

I prestiti non escludono altri modi per risarcire i danni in caso di grave negligenza.

5. 5 Deprecati e compatibilità

Almeno 180 giorni di notifica per le modifiche che interrompono la compatibilità. Supporto parallelo per almeno 90 giorni"

5. 6 Uscita (Exit)

"Entro 30 giorni dalla disdetta, il provider fornisce gratuitamente l'esportazione completa dei dati nei formati Parket/JSON + schema; servizi di migrazione aggiuntivi - a tariffa X. La distruzione delle copie è confermata dall'atto"

6) OLA - Supporto interno per SLA esterno

• Obiettivi: p99 gateway da 200 ms, rate da 0. 3%, DR: RPO 0, RTO 30 min.
• Responsabilità: SRE-on-call, 24 x 7; dashboard e alert comuni.
• Processi: disordine in release, perf-smook in PR, euristics shading.
• Gate: unità di deposito in caso di fallimento del test SLO/xaoc; Aggiornamento runbook obbligatorio.

7) Monitoraggio e prove

Sintetico: provini esterni (HTTP/TCP), percorso utente, «successo lento».
RUM - Monitoraggio effettivo dell'utente per confermare l'impatto.
Correlazione: etichette «provider», «region», «api _ method», «incident _ id».
Artefatti: screenshot/roulotte/logi, esportazione KPI, cronologia delle escalation.

rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}

8) Incidenti e interazioni

1. Classificazione SEC, apertura war-room, assegnazione IC.

2. Notifica al provider tramite hot channel, trasferimento di manufatti.

3. Modalità di elusione/flag fich (stale, shading, rate-cap).

4. Timeline congiunta, recupero.

5. Aggiorna i limiti, le chiavi, le rotte di riserva.

6. Avvio dei crediti SLA, fissazione in billing.

9) Sicurezza e DPA

DPA/Privacy: ruoli di controller/processore, categorie di dati, database di legalità, data/scopo di elaborazione, sottoprocessori e loro SLA.
Crittografia TLS1. 2+, PFS; dati «a riposo», controllo chiavi (KMS/HSM), rotazione.
≤ di accesso, segnalazioni di violazioni da 72 ore, rapporti pentest su richiesta.
Localizzazione: regione di storage, divieto di estrazione senza consenso.

10) Supply Chain e compatibilità

SBOM/vulnerabilità: soglia CVSS e tempi di correzione (criticato 7 giorni, high-14).
Compatibilità API: test contrattuali, arenili e ficsture stabili.
Modifiche del provider: prime note di rilascio, anticipo/beta, compatibilità inversa.

11) Multiproprietà e feelover

Active/Active: più complessa e costosa, ma maggiore disponibilità (considerate la consistenza).
Active/Passive: riserva fredda/calda, allenamento regolare DR.
Astrazioni/adattatori: un unico contratto, routing per la salute/costo/fattore carbonio (se rilevante).
Condizioni di licenza/vendita: portabilità, limitazione dell'output, costo egress.

12) Piano exit e prove periodiche

Catalogo dati/diagrammi e volumi.
Script di portabilità SDK/API (minimo - seconde source).
Prova di uscita secca: esportazione/importazione, ripristino, verifica degli invarianti.
Tempi legali di conservazione/rimozione dopo l'uscita.

13) Test del contratto e conformance

Prova API positivo/negativo, limiti, errori e retrai.
Consegna di eventi/webhoop: firma/ora/deadup/ripetizioni.
Perf-basline: p99, larghezza di banda; test di regressione delle note di rilascio del provider.
Regione Cross - Il degrado di una regione non deve essere compromesso globalmente dal SLO.

14) Anti-pattern

SLA «a pagina» senza misurazioni esterne.
Obiettivi identici per tutte le regioni/endpoint.
L'assenza di diritti di verifica e registri dettagliati degli incidenti.
No OLA/UC, non c'è nessuno che adempie all'interno.
Un piano esit incerto ha messo in ostaggio il fornitore.
Le multe sono solo crediti, senza il diritto di annullare le violazioni sistematiche.
Deprekate senza finestra di transizione.

15) Assegno-foglia architetto

1. Definiti SLI/SLO per flow chiave e regioni?
2. È stato selezionato un metodo di monitoraggio esterno e una base di prova?
3. La SLA prevede incidenti, escalation, finestre di lavoro programmate e un limite di eccezioni?
4. C'è una scala di credito/multe e il diritto di annullamento in N violazioni?
5. Crittografia, registri, notifiche, sottoprocessori, localizzazione?
6. Test contrattuali e cassette di sabbia in pipline?
7. Le OLE/UC interne consentono l'esecuzione di SLO esterni?
8. DR: RPO/RTO dichiarati, allenamento in corso, rapporti?
9. Exit plan: formati di esportazione, tempi, pratica di uscita secca?
10. I GATE/CD bloccano i comunicati che aumentano il rischio di violazione della SLA?

16) Mini esempi (sketch)

16. 1 Criteri di deposito-gate sui rischi del provider

yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"

16. 2 Esportazione «prove dell'incidente»

bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '.      {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl

16. 3 Test contrattuale webhook (pseudocode)

python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency

Conclusione

SLA/OLA non è solo carta legale, ma un meccanismo architettonico di gestione del rischio e della qualità. Metriche e finestre corrette, monitoraggio esterno, procedure chiare per incidenti e rimborsi, OLA/UC interna, gate in pipline, multi-fornitori e un vero exit plan trasformano la dipendenza dai provider in una parte controllata, misurabile e economicamente prevedibile della vostra piattaforma.