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 станут управляемыми, понятными и защищенными.