SLA/OLA cu furnizori

1) Termeni și limite

SLI - indicator măsurabil (disponibilitate, latență p99, cărți web prelucrate cu succes, RPO/RTO).
SLO - valoarea SLI țintă pe fereastră de măsurare (de exemplu, 99. 9 %/30 zile).
SLA - document obligatoriu din punct de vedere juridic (SLO + proceduri + rambursare).
OLA - obiective și procese interne care asigură respectarea SLA.
UC (Contract de suport) - „substrat” cu terțe părți (canale, centre de date, CDN etc.).

Limite: separați în mod clar zona de responsabilitate a furnizorului (cloud/WAF/CDN/gateway de plată/furnizor KYC) de zona dvs. (cod, config, setările clientului).

2) Matricea critică și selecția modelului

Matricea determină adâncimea SLA, domeniul de aplicare al verificărilor și cerințele pentru OLA/UC.

3) Măsurători și ferestre de măsurare

Disponibilitate - Procentul de timp pe care serviciul execută interogări în funcție de toleranțe.
Latență: p95/p99 pentru operațiuni cheie; „succes lent” contează.
Fiabilitatea datelor: RPO (pierdere maximă admisă de date) și RTO (timp de recuperare).
Lățime de bandă/limite: cote garantate (RPS/MBps).
Calitatea integrărilor: ponderea cărților web livrate ≤ X minute, cota de răspunsuri 2xx, repetiții și eliminări de duplicate.
Fereastra de măsurare: lunar/laminare 30 zile, excepții (activități planificate) cu limite.

• 'Availability _ ext = 1 − (Downtime_confirmed_outages/ Total_minutes_in_window)'
• În cazul în care întreruperea este starea confirmată indisponibilă prin monitorizare externă, și nu doar prin pagina de stare a furnizorului.

4) conținut SLA (șablon secțiune)

1. Subiect și domeniu de aplicare (servicii, regiuni, versiuni API).
2. Definiții (SLI/SLO, „incident”, „lucrare planificată”, „forță majoră”).
3. Obiective de servicii (SLO) pe categorii de cereri și regiuni.
4. Monitorizarea și baza de probe: în ce fel, ai căror senzori, cu ce frecvență.
5. Incidente și escaladări: canale, timpi de răspuns/actualizare, roluri.
6. Rambursări: credite/amenzi/bonusuri, praguri, formule.
7. Securitate și confidențialitate: DPA, criptare, jurnale, notificări de încălcare.
8. Modificări de serviciu: deprecieri, fereastră de notificare, compatibilitate.
9. Continuitate și DR: RPO/RTO, teste de recuperare.
10. Audit și conformitate: dreptul la audit, raportare, certificare.
11. Plan de ieșire: export de date, date, format, asistență pentru migrație.
12. Prevederi legale: jurisdictie, forta majora, confidentialitate, perioada de valabilitate.

5) Exemple de formulare (fragmente)

5. 1 Disponibilitate și măsurare

"Furnizorul oferă 99. 95% disponibilitate în fiecare lună calendaristică. Disponibilitatea este măsurată prin monitorizarea sintetică externă a Clientului din ≥3 regiuni la intervale de ≤1 minute. Indisponibilitatea înregistrată în ≥2 regiuni este considerată simultan un incident de nivel SEV2 și numărată în Downtime "

5. 2 Latenţă API cheie

„p99 timp de răspuns 'POST/plăți/autoriza” ≤ 450 ms pe 95% din zilele lunii. Un raport de analiză a cauzei este furnizat pentru procentul de cereri care depășesc pragul"

5. 3 Incidente și escaladări

"S1: ack ≤ 15 min, actualizări la fiecare ≤ 30 min, țintă de recuperare ≤ 2 h; S2: ack ≤ 30 min, actualizări ≤ 60 min; S3: A doua zi lucrătoare. Canale: telefon 24 × 7, chat bridge, e-mail"

5. 4 Rambursări (credite)

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

Împrumuturile nu exclud alte metode de despăgubire pentru daune în neglijență gravă.

5. 5 Depreciază și compatibilitatea

"Cel puțin 180 de zile de preaviz pentru modificări care sparg compatibilitatea. Suport concomitent pentru vN și vN + 1 timp de cel puțin 90 de zile"

5. 6 Ieșire

"În termen de 30 de zile de la terminare, furnizorul oferă gratuit exportul complet de date în formatele Parchet/JSON +; servicii suplimentare de migrație - la tariful X. Distrugerea copiilor este confirmată de act"

6) OLA: suport intern pentru SLA extern

• Obiective: p99 gateway ≤ 200 ms, rata de eroare ≤ 0. 3%, DR: RPO 0, RTO 30 min.
• Responsabilitate: SRE-on-call, 24 × 7; tablouri de bord comune și alerte.
• Procese: haos-fum în lansări, perf-fum pe PR, euristica umbririi.
• Porți: implementați blocul atunci când testul SLO/xaoc eșuează; actualizare runbook obligatorie.

7) Monitorizare și dovezi

Sintetice: sonde externe (HTTP/TCP), calea utilizatorului, „succes lent”.
RUM: monitorizarea reală a utilizatorilor pentru a confirma impactul.
Corelaţie: etichetele 'provider', 'region', 'api _ method', 'incident _ id'.
Artefacte: capturi de ecran/trasee/jurnale, export KPI, cronologie de escaladare.

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

8) Incidente și interacțiuni

1. Clasificare SUV, deschidere cameră de război, scop IC.

2. Notificarea furnizorului prin intermediul „canalului fierbinte”, transmiterea artefactelor.

3. Bypass moduri/caracteristici steaguri (vechi, umbrire, rate-cap).

4. Cronologie comună, recuperare.

5. Acțiuni postmortem +: actualizarea limitelor de configurare, chei, rute de rezervă.

6. Inițierea creditelor SLA, fixarea în facturare.

9) Securitate și DPA

DPA/confidențialitate: roluri de controlor/procesor, categorii de date, baza de legalitate, termene de procesare/obiective, subprocesoare și SLA-urile acestora.
Criptare: TLS1. 2 +, SFP; date „în repaus”, managementul cheilor (KMS/HSM), rotație.
Audit: jurnale de acces, notificări de încălcare ≤ 72 de ore, rapoarte pentest la cerere.
Localizare: regiune de stocare, interzicerea exportului fără consimțământ.

10) Lanțul de aprovizionare și interoperabilitatea

SBOM/vulnerabilități: politica de prag CVSS și timpi de fixare (criticat ≤ 7 zile, ridicat ≤ 14).
Compatibilitate API: teste de contract, cutii de nisip și corpuri stabile.
Modificări ale furnizorului: note de lansare timpurie, previzualizări/ferestre beta, compatibilitate înapoi.

11) Multi-provider și feilover

Activ/Activ: Mai greu și mai scump, dar disponibilitate mai mare (ia în considerare consistența).

Activ/Pasiv: Rece/Warm Reserve, DR. antrenamente regulate

Abstracții/adaptoare: contract unic, rutare sănătate/cost/carbon (dacă este cazul).
Condiții de licență/comerciale: portabilitate, limitare a ieșirii datelor, cost de ieșire.

12) Planul de ieșire și repetițiile periodice

Catalog de date/diagrame și volume.
Script portabilitate SDK/API (minim - a doua sursă).
Test de ieșire uscată: export/import, restaurare, verificare invarianți.
Perioade legale de păstrare/eliminare după eliberare.

13) Testele contractuale și conformitatea

Probe API: Pozitive/Negative, Limite, Erori și Retrăiri.
Livrarea de evenimente/carti web: semnatura/ora/bunicul/repetitii.
Linii de bază Perf: p99, lățime de bandă; teste de regresie pe notele de eliberare ale furnizorului.
Regiunea transversală: degradarea unei regiuni nu ar trebui să încalce SLO la nivel global.

14) Anti-modele

SLA „pe pagina de stare” fără măsurători externe.
Aceleași obiective pentru toate regiunile/punctele finale.
Lipsa drepturilor de audit și jurnalele detaliate ale incidentelor.
Nu există OLA/UC → nu există nimeni care să îndeplinească obligațiile externe în interior.
Plan de ieșire nedefinit → ostatic furnizor.
„Amenzi doar prin împrumuturi” fără dreptul de a rezilia în caz de încălcare sistematică.
Se depreciază fără o fereastră de tranziție.

15) Lista de verificare arhitect

1. Definit SLI/SLO pentru fluxul cheie și regiuni?
2. Metoda de monitorizare externă selectată și baza de probe?
3. Incidentele, escaladările, ferestrele de lucru planificate și limita de excepție sunt precizate în SLA?
4. Au o scară de credit/penalități și un drept de reziliere pentru încălcările N?
5. DPA/securitate: criptare, jurnale, notificări, sub-procesoare, localizare?
6. Teste de contract și cutii de nisip în conductă?
7. OLA/UC-uri interne permit SLO-uri externe?
8. DR: RPO/RTO a declarat, instruire efectuate, rapoarte disponibile?
9. Plan de ieșire: formate de export, calendarul, practica de ieșire uscată?
10. Sunt porti in CI/CD blocarea lansări care cresc riscul de încălcare SLA?

16) Mini-exemple (schițe)

16. 1 Politica de implementare a porților privind riscul furnizorului

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 Exportul de „dovezi 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 Contract Webhook Test (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

Concluzie

SLA/OLA nu este doar o „lucrare juridică”, ci un mecanism arhitectural pentru gestionarea riscului și a calității. Valorile și ferestrele potrivite, monitorizarea externă, procedurile clare de incidente și rambursare, OLA/UC-urile interne, porțile pipelined, multi-furnizorii și un plan real de ieșire transformă dependența furnizorului într-o parte controlată, măsurabilă și previzibilă din punct de vedere economic a platformei dvs.