Uptime звіти і аудит SLA

1) Навіщо потрібен формальний процес uptime-звітності

Довіра клієнтів і контрактна прозорість - єдина методика вимірювань, повторювані розрахунки.
Управління SLO і бюджетом помилок - зв'язка факту доступності з релізами та інцидентами.
Правильні SLA-кредити - об'єктивні формули, передбачувані виплати/заліки.
Юридична стійкість - доказова база, незалежний аудит, Legal Hold.

2) Терміни та межі

SLI Availability - частка успішних перевірок/транзакцій за період.
SLO - внутрішня мета (наприклад, 99. 95% за 28 днів).
SLA - зовнішнє зобов'язання (наприклад, 99. 9 %/місяць + сервіс-кредити).
Вікно вимірювання - календарний місяць (SLA) і rolling-вікна (SLO).
Scope - які компоненти входять до розрахунку (edge, API, платежі), а які ні (адмін-портал, non-prod).

3) Джерела істини (і коли який головний)

1. Синтетика (blackbox/headless) - первинний SLI для «доступності очима користувача».
2. Логи/метрики - підтверджують масштаб і характер відмови.
3. Бізнес-події - «успіх операції» (наприклад, платіж авторизований).
4. Статус-сторінка - публічна комунікація; звіряється з фактами № 1-3.

При розбіжностях: пріоритет за синтетикою з коректним quorum з ≥2 регіонів.

4) Методика розрахунку доступності

4. 1 Базова формула

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

4. 2 Багато-регіонний quorum

Інцидент зараховується, якщо ≥N незалежних регіонів/ASN одночасно фіксують відмову.
Рекомендуємо: N = 2 з 3 (EU/NA/APAC).

4. 3 Типи SLI

HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
Бізнес SLI: успішні транзакції/всі спроби (з виключенням клієнтських відмов).

4. 4 Винятки (documented)

Планові maintenance вікна, оголошені заздалегідь N годин і дотримані.
Force majeure з SLA (наприклад, провайдер IX-катастрофи) - тільки за наявності доказів і публічного повідомлення.
Клієнтські помилки/обмеження (quota exceeded, 4xx).

5) Політика maintenance вікон

Тимчасові слоти, узгоджені в контракті (наприклад, нд 02:00–04:00 по UTC + 0).
Маркери'maintenance = true'в алертах/панелях → виняток з SLI.
Поріг повідомлення: мінімум за 5 робочих днів (або як у договорі).
Поза вікном - вважається SLA-вплив.

6) Edge-кейси і правила округлення

Brownout (часткове погіршення): вважати частку відмов (weighted downtime), а не «0/1».
Flapping: мінімальна одиниця обліку - інтервал проби (наприклад, 30-60 сек) + hysteresis (for: 2-5 хв).
Clock drift: всі часи в UTC і ISO-8601; синхронізація NTP.

7) Приклади PromQL (синтетика → аптайм)

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) Приклади SQL (агрегації звіту)

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) Шаблон щомісячного звіту (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) SLA-кредити: розрахунок і застосування

Таблиця кредитів: наприклад, 99. 0–99. 5% → 5% MRR; 98. 0–99. 0% → 10% і т.д.
True-up: кредит застосовується як credit note до наступного рахунку.
Автоматизація: правило "якщо'measured _ availability <SLA'→'credit _ note. create()`».
Вітрина для клієнта: портальна картка «SLA credits balance».

11) Аудит, докази і Legal Hold

Аудит-трейл: хто/що/коли розрахував, версія методики, контрольні суми.
Raw-дані незмінні (append-only); коригування - окремими записами.
Legal Hold: заморожування діапазону даних (проби, логи, інцидент-картки, алерти).
Репліка архівів: незалежне сховище (WORM/S3 Object Lock).

12) Звірка з публічною статус-сторінкою

Інцидент на статус-сторінці зобов'язаний мати таймлайн і компоненти.
Невідповідність часу/масштабу → створюється discrepancy-record і проводиться RCA.
Підсумок звіту містить розділ «Reconciliation Notes».

13) Інциденти та звітність

Кожному вікну даунтайму відповідає INC-картка (ID, SEV, власник, RCA, CAPA).
У звіті: посилання на INC, короткий root cause, статус CAPA.
Для SEV-1: постмор тим ≤ 48 год від закриття.

14) Контроль якості даних

Гігієна проб: > 99% успішних скрейпів агентів, відсутність пропусків> 5 хвилин.
Анти-шум: quorum + multi-window, debounce.
Семплювання трас/логів фіксується і документується.
Тести методики: юніт-тести розрахунків, golden-файли на історичних даних.

15) Безпека і приватність

TLS/mTLS для ingest, підпис пакетів (HMAC).
PII-редакція в логах/звітах; SLA-звіт не повинен розкривати персональні дані.
RBAC/ABAC на звіти; сліди доступу пишуться в аудит-лог.

16) Дашборди і SLO-віджети (що показувати)

Overall availability по сервісах за місяць/квартал.
Downtime windows з severity і каналом детекту.
Error budget burn (fast/slow) і тренди.
Releases overlay - анотації викладок.
SLA credits forecast - при поточному тренді.

17) План впровадження (3 ітерації)

1. Модель і дані (2 тижні): зафіксувати SLI/SLO/SLA, включити quorum-синтетику, зібрати «сировину» в DWH.
2. Розрахунок і звіт (2-3 тижні): формули, SQL/PromQL, шаблони YAML/PDF, портал клієнта, авто-кредити.
3. Аудит та автоматизація (3-4 тижні): Legal Hold, reconciliation зі статус-сторінкою, підписані вебхуки, регламенти диспутів.

18) Чек-лист якості звіту

• Визначено scope, SLI, методику та вікно вимірювання.
• Є quorum і multi-window; flapping пригнічується.
• Винятки (maintenance/force majeure) документовані.
• Кожне вікно даунтайму пов'язане з INC і RCA.
• Підраховані SLA-кредити і відображені в білінгу.
• Звіт відтворюємо (версії формул/даних).
• Аудит-трейл і Legal Hold включені.
• Публічна статус-сторінка узгоджена (reconciliation notes).

19) Міні-FAQ

Чому синтетика - головне джерело?
Вона найближче до призначеного для користувача шляху і включає периметр (DNS/CDN/WAF). Метрики/логи - уточнюють причину.

Як рахувати часткові деградації?
Зважений даунтайм: частка неуспіхів × тривалість вікна, а не «все або нічого».

Чи потрібно зберігати «сирі» перевірки?
Так. Для аудиту і повторного розрахунку при суперечці - raw потрібні обов'язково.

Підсумок

Uptime-звіти і аудит SLA - це не «цифра в кінці місяця», а відтворювана система вимірювань, правил і доказів: коректні SLI, quorum-перевірки, прозорі формули, зв'язка з інцидентами і білінгом, контроль винятків і Legal Hold. Зафіксуйте методику, автоматизуйте розрахунок і кредити, тримайте аудит-трейл - і ваші SLA стануть керованими, зрозумілими і захищеними.