Rapoarte de uptime și audituri SLA

1) De ce avem nevoie de un proces formal de raportare uptime?

Încrederea clienților și transparența contractelor - o singură tehnică de măsurare, calcule repetabile.
SLO și gestionarea bugetului de eroare - care leagă faptul de disponibilitate cu versiuni și incidente.
Creditele SLA corecte sunt formule obiective, plăți/compensări previzibile.
Sustenabilitate juridică - bază de probe, audit independent, Legal Hold.

2) Termeni și limite

SLI Disponibilitate - procent de validări/tranzacții de succes pe perioadă.
SLO - țintă internă (ex. 99. 95% în 28 zile).
SLA - angajament extern (ex. 99. 9 %/lună + credite pentru servicii).
Fereastra de măsurare - luna calendaristică (SLA) și fereastra de rulare (SLO).
Domeniul de aplicare - ce componente sunt incluse în calcul (margine, API, plăți) și care nu sunt (portal admin, non-prod).

3) Surse de adevăr (și atunci când unul este responsabil)

1. Sintetica (blackbox/headless) este SLI-ul primar pentru „accesibilitatea ochilor utilizatorului”.
2. Jurnale/valori - confirmați scara și natura eșecului.
3. Evenimentele de afaceri sunt „succesul tranzacției” (de exemplu, plata autorizată).
4. Status page - comunicare publică; este verificat împotriva faptelor nr. 1-3.

În caz de discrepanțe: se acordă prioritate sinteticilor cu cvorumul corect din ≥2 regiuni.

4) Metodologia de calcul al disponibilității

4. 1 Formulă de bază

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

4. 2 Cvorum multiregional

Un incident este numărat dacă ≥N regiuni independente/ASN înregistrează simultan un eșec.
Recomandat: N = 2 din 3 (EU/NA/APAC).

4. 3 tipuri SLI

HTTP SLI: код 2xx/3xx, latență ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expirare.
Afaceri SLI: tranzacții de succes/toate încercările (cu excepția eșecurilor clienților).

4. 4 Excepții (documentate)

Ferestrele de întreținere programate au fost declarate în avans N ore și observate.
Forță majoră din partea SLA (de exemplu, furnizorul de dezastre IX) - numai dacă există dovezi și notificare publică.
Erorile/restricțiile clientului (cota depășită, 4xx).

5) Politica de întreținere a ferestrelor

Sloturi orare convenite în contract (ex. Sun 02: 00-04: 00 UTC + 0).
"Mentenanță = true 'markeri în alertă/panouri → excludere de la SLI.
Pragul de notificare: cel puțin 5 zile lucrătoare (sau ca în contract).
Pe fereastră - impactul SLA este luat în considerare.

6) Cazuri de margine și reguli de rotunjire

Brownout (degradare parțială): numărați procentul de eșecuri (timpi de inactivitate ponderați), nu „0/1”.
Flapping: unitate minimă de cont - interval de probă (de exemplu, 30-60 secunde) + histerezis (pentru: 2-5 minute).
Deriva ceasului: tot timpul în UTC și ISO-8601; Sincronizarea NTP.

7) Exemple de PromQL (sintetice → uptime)

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) Exemple de SQL (agregarea raportului)

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) Șablon lunar de raport (Client-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) credite SLA: calcul și aplicare

Tabelul creditelor: de exemplu, 99. 0–99. 5% → 5% RMN; 98. 0–99. 0% → 10% etc.
True-up: Creditul se aplică ca notă de credit în contul următor.

Automatizare: „if” measured _ availability

Casetă de prezentare pentru client: card portal „Soldul creditelor SLA”.

11) Audit, dovezi și deținere legală

Traseul de audit: cine/ce/când este calculat, versiunea metodologiei, sumele de control.
Datele brute sunt imuabile (numai pentru adăugare); ajustări - prin înregistrări separate.
Legal Hold: înghețarea intervalului de date (mostre, jurnale, carduri incidente, alerte).
Arhive replica - WORM/S3 Object Lock.

12) Reconcilierea cu pagina statutului public

Un incident pe o pagină de stare trebuie să aibă o cronologie și componente.
Nepotrivirea timp/scară este → creată de discrepanță-înregistrare și este postat de RCA.
Rezumatul raportului conține secțiunea Note de reconciliere.

13) Incidente și raportare

Fiecare fereastră de nefuncționare corespunde unui card INC (ID, SEV, proprietar, RCA, CAPA).
În raport: link către INC, cauza rădăcină scurtă, statutul CAPA.
Pentru SEV-1: subiecte postmore ≤ 48 de ore de la închidere.

14) Controlul calității datelor

Igiena probelor:> 99% din resturile reușite de agenți, absența lacunelor> 5 minute.
Anti-zgomot: cvorum + multi-fereastră, debunch.
Eșantionarea urmelor/jurnalelor este înregistrată și documentată.
Teste de metodă: teste unitare de calcule, fișiere de aur pe baza datelor istorice.

15) Securitate și confidențialitate

TLS/mTLS pentru ingerare, semnătură pachet (HMAC).
ediție PII în jurnale/rapoarte; Raportul SLA nu trebuie să dezvăluie date cu caracter personal.
RBAC/ABAC privind rapoartele; urmele de acces sunt scrise în jurnalul de audit.

16) Tablouri de bord și widget-uri SLO (ce să arate)

Disponibilitate globală prin serviciu pentru luna/trimestrul.
Downtime ferestre cu severitate și canal de detectare.
Eroare buget arde (rapid/lent) și tendințele.
Eliberează suprapunerea - adnotări ale calculelor.
Prognoza creditelor SLA - la tendința actuală.

17) Planul de implementare (3 iterații)

1. Model și date (2 săptămâni): fixați SLI/SLO/SLA, includeți sintetica cvorumului, colectați „materii prime” în DWH.
2. Calcul și raport (2-3 săptămâni): formule, SQL/PromQL, șabloane YAML/PDF, portal clienți, auto-credite.
3. Audit și automatizare (3-4 săptămâni): Legal Hold, reconciliere cu pagina de stare, cărți web semnate, reglementări privind litigiile.

18) Lista de verificare a calității raportului

• Domeniul de aplicare, SLI, metoda și fereastra de măsurare definite.
• Există cvorum și multi-fereastră; flapping este suprimat.
• Excepțiile (întreținere/forță majoră) sunt documentate.
• Fiecare fereastră de nefuncționare este asociată cu INC și RCA.
• Credite SLA calculate și reflectate în facturare.
• Raport reproductibil (formulă/versiuni de date).
• Traseul de audit și Legal Hold sunt incluse.
• Pagina statutului public este reconciliată.

19) Mini-Întrebări frecvente

De ce este sintetica principala sursă?
Este cel mai apropiat de calea utilizatorului și include un perimetru (DNS/CDN/WAF). Măsurători/jurnale - clarificați motivul.

Cum se numără degradarea parțială?
Downtime ponderat: proporția de eșecuri × durata ferestrei, și nu „totul sau nimic”.

Trebuie să stochez cecuri „crude”?
Da, am făcut-o. Pentru auditare și recalculare într-un litigiu - brut este necesar.

Rezultat

Rapoartele de uptime și auditurile SLA nu sunt o „cifră la sfârșitul lunii”, ci un sistem reproductibil de măsurători, reguli și dovezi: SLI-uri corecte, verificări ale cvorumului, formule transparente, legarea cu incidentele și facturarea, controlul excepției și Legal Hold. Înregistrați metodologia, automatizați calculul și creditele, păstrați traseul auditului - iar SLA-urile dvs. vor deveni gestionabile, ușor de înțeles și sigure.