Sprawozdania okresowe i audyty SLA

1) Dlaczego potrzebujemy formalnego procesu sprawozdawczego?

Pewność klienta i przejrzystość kontraktu - jedna technika pomiaru, powtarzalne obliczenia.
SLO i zarządzanie budżetem błędów - powiązanie dostępności z uwolnieniami i incydentami.
Prawidłowe pożyczki SLA są obiektywne formuły, przewidywalne płatności/potrącenia.
Stabilność prawna - podstawa dowodowa, niezależny audyt, Legal Hold.

2) Warunki i granice

Dostępność SLI - odsetek udanych walidacji/transakcji w danym okresie.
SLO - cel wewnętrzny (np. 99. 95% w ciągu 28 dni).
SLA - zobowiązania zewnętrzne (np. 99. 9 %/miesiąc + pożyczki na usługi).
Okno pomiarowe - miesiąc kalendarzowy (SLA) i okno toczenia (SLO).
Zakres - które elementy są uwzględnione w obliczeniach (krawędź, API, płatności) i które nie są (admin portal, non-prod).

3) Źródła prawdy (i kiedy jest odpowiedzialny)

1. Syntetyka (blackbox/headless) jest podstawowym SLI dla „dostępności użytkownika oka”.
2. Dzienniki/metryki - potwierdzenie skali i charakteru awarii.
3. Zdarzenia biznesowe to „sukces transakcji” (na przykład płatność autoryzowana).
4. Strona statusu - komunikacja publiczna; jest sprawdzany na podstawie faktów nr 1-3.

W przypadku rozbieżności: priorytetem jest syntetyka z prawidłowym kworum z ≥ 2 regionów.

4) Metodyka obliczania dostępności

4. 1 Wzór podstawowy

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

4. 2 Kworum wieloregionalne

Incydent jest liczony, jeśli ≥ N niezależne regiony/ASN jednocześnie rejestrują niepowodzenie.
Zalecane: N = 2 z 3 (EU/NA/APAC).

4. 3 typy SLI

HTTP SLI: коz 2xx/3xx, opóźnienie ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
SLI business: udane transakcje/wszystkie próby (z wyłączeniem awarii klienta).

4. 4 Wyjątki (udokumentowane)

Zaplanowane okna konserwacyjne zadeklarowane z wyprzedzeniem N godzin i obserwowane.
Siła wyższa od SLA (na przykład IX dostawca katastrof) - tylko wtedy, gdy istnieją dowody i publiczne zawiadomienia.
Błędy/ograniczenia klienta (przekroczony kontyngent, 4xx).

5) Polityka konserwacji okien

Terminy uzgodnione w umowie (np. Słońce 02: 00-04: 00 UTC + 0).
"Konserwacja = true 'markkers in alert/panels → wyłączenie z SLI.
Próg powiadomienia: co najmniej 5 dni roboczych (lub jak w umowie).
Poza oknem - rozważa się wpływ SLA.

6) Przypadki krawędzi i zasady zaokrąglania

Brownout (częściowa degradacja): policzyć procent niepowodzeń (ważony czas przestoju), a nie „0/1”.
Klapowanie: minimalna jednostka rachunku - interwał próbki (na przykład 30-60 sekund) + histereza (przez: 2-5 minut).
Drift zegara: wszystkie razy w UTC i ISO-8601; Synchronizacja NTP.

7) Przykłady PromQL (syntetyka → 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) Przykłady SQL (agregacja raportów)

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) Miesięczny szablon raportu (przyjazny dla klienta)

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) Kredyty SLA: obliczanie i stosowanie

Tabela kredytów: na przykład 99. 0–99. 5% → 5% MRR; 98. 0–99. 0% → 10% itp.
Prawda: Kredyt ma zastosowanie jako nota kredytowa na następne konto.

Automatyzacja: "if 'measured _ availability

Prezentacja dla klienta: karta portalu „Saldo kredytów SLA”.

11) Audyt, dowody i posiadanie prawa

Ścieżka audytu: who/what/when calculated, version of the methodology, checksums.
Dane surowe są niezmienne (tylko dodatek); korekty - poprzez oddzielne zapisy.
Blokada prawna: zamrażanie zakresu danych (próbki, dzienniki, karty incydentów, wpisy).
Archiwa repliki - WORM/S3 blokada obiektów.

12) Uzgodnienie ze stroną stanu publicznego

Incydent na stronie stanu musi mieć linię czasu i komponenty.
Niedopasowanie czasu/skali jest → tworzone przez rekord rozbieżności i jest publikowane przez RCA.
Podsumowanie raportu zawiera sekcję Uwagi pojednawcze.

13) Incydenty i sprawozdawczość

Każde okno przestoju odpowiada karcie INC (ID, SEV, właściciel, RCA, CAPA).
W raporcie: link to INC, short root cause, status CAPA.
W przypadku SEV-1: topics postmore ≤ 48 godzin od zamknięcia.

14) Kontrola jakości danych

Higiena próbek:> 99% udanych skrawków środków, brak szczelin> 5 minut.
Anty-hałas: kworum + multi-window, debounce.
Pobieranie próbek śladowych/kłód jest rejestrowane i dokumentowane.
Badania metodologiczne: testy jednostkowe obliczeń, złote pliki oparte na danych historycznych.

15) Bezpieczeństwo i prywatność

TLS/mTLS do spożycia, podpis pakietu (HMAC).
wydanie PII w dziennikach/raportach; Raport SLA nie może ujawniać danych osobowych.
RBAC/ABAC w zakresie sprawozdań; ślady dostępu są zapisywane do dziennika audytu.

16) Deski rozdzielcze i widżety SLO (co pokazać)

Ogólna dostępność według usług za miesiąc/kwartał.
Okna przestojów z kanałem dotkliwości i wykrywania.
Błąd spala budżet (szybko/wolno) i trendy.
Nakładka na wydania - adnotacje obliczeń.
Prognoza kredytów SLA - według obecnego trendu.

17) Plan realizacji (3 iteracje)

1. Model i dane (2 tygodnie): naprawić SLI/SLO/SLA, zawierać syntetyki kworum, zbierać „surowce” w DWH.
2. Obliczanie i raportowanie (2-3 tygodnie): wzory, SQL/PromQL, szablony YAML/PDF, portal klienta, automatyczne kredyty.
3. Audyt i automatyzacja (3-4 tygodnie): Legal Hold, uzgodnienie ze stroną statusu, podpisane haki internetowe, przepisy dotyczące sporów.

18) Lista kontrolna jakości raportu

• Zakres, SLI, metoda i okno pomiarowe zdefiniowane.
• Istnieje kworum i wiele okien; Klapa jest stłumiona.
• Wyjątki (utrzymanie/siła wyższa) są udokumentowane.
• Każde okno przestoju jest związane z INC i RCA.
• Obliczone kredyty SLA i odzwierciedlone w rozliczeniach.
• Powtarzalne sprawozdanie (formuła/wersje danych).
• Uwzględniono ścieżkę audytu i blokadę prawną.
• Strona statusu publicznego jest uzgodniona.

19) Mini-FAQ

Dlaczego syntetyka jest głównym źródłem?
Jest najbliżej ścieżki użytkownika i zawiera obwód (DNS/CDN/WAF). Metryka/dzienniki - wyjaśnić powód.

Jak policzyć częściową degradację?
Ważony czas przestoju: odsetek awarii × czas trwania okna, a nie „całość lub nic”.

Czy muszę przechowywać „surowe” czeki?
Tak, zrobiłem to. Do audytu i ponownego obliczenia w sporze - wymagany jest surowy.

Wynik

Raporty okresowe i audyty SLA nie są „liczbą na koniec miesiąca”, ale powtarzalnym systemem pomiarów, zasad i dowodów: poprawne SLIs, sprawdzenie kworum, przejrzyste wzory, powiązanie z incydentami i rozliczeniami, kontrola wyjątkowa i hold prawny. Zapisz metodologię, zautomatyzuj obliczenia i kredyty, zachowaj ścieżkę audytu - a Twoje SLA staną się zarządzalne, zrozumiałe i bezpieczne.