SLA/OLA с провайдерами

1) Термины и границы

SLI — измеряемый индикатор (доступность, латентность p99, успешно обработанные вебхуки, RPO/RTO).
SLO — целевое значение SLI за окно измерения (например, 99.9%/30 дней).
SLA — юридически обязывающий документ (SLO + процедуры + возмещение).
OLA — внутренние цели и процессы, обеспечивающие соблюдение SLA.
UC (Underpinning Contract) — «подложка» с третьими лицами (каналы, ЦОД, CDN и т. п.).

Границы: четко отделяйте область ответственности провайдера (облако/WAF/CDN/платежный шлюз/провайдер KYC) от вашей зоны (код, конфиг, клиентские настройки).

2) Матрица критичности и выбор модели

От матрицы зависит глубина SLA, объем проверок и требования к OLA/UC.

3) Метрики и окна измерения

Доступность (Availability): доля времени, когда сервис выполняет запросы согласно допускам.
Латентность: p95/p99 для ключевых операций; «медленный успех» учитывается.
Надежность данных: RPO (максимально допустимая потеря данных) и RTO (время восстановления).
Пропускная способность/лимиты: гарантированные квоты (RPS/MBps).
Качество интеграций: доля доставленных вебхуков ≤ X мин, доля 2xx-ответов, повторов и дедупликации.
Окно измерения: помесячно/скользящие 30 дней, исключения (плановые работы) с лимитами.

• `Availability_ext = 1 − (Downtime_confirmed_outages / Total_minutes_in_window)`
• Где outage — подтвержденное недоступное состояние по внешнему мониторингу, а не только по статус-странице провайдера.

4) Содержание SLA (шаблон разделов)

1. Предмет и область (сервисы, регионы, версии API).
2. Определения (SLI/SLO, «инцидент», «плановые работы», «форс-мажор»).
3. Цели сервиса (SLO) по категориям запросов и регионам.
4. Мониторинг и доказательная база: каким способом, чьими датчиками, с какой периодичностью.
5. Инциденты и эскалации: каналы, сроки отклика/обновлений, роли.
6. Возмещения: кредиты/штрафы/бонусы, пороги, формулы.
7. Безопасность и приватность: DPA, шифрование, журналы, уведомления о нарушениях.
8. Изменения сервиса: депрекейты, окно нотификаций, совместимость.
9. Непрерывность и DR: RPO/RTO, тесты восстановления.
10. Аудит и комплаенс: право на аудит, отчетность, аттестации.
11. Exit Plan: экспорт данных, сроки, формат, помощь в миграции.
12. Юридические положения: юрисдикция, форс-мажор, конфиденциальность, срок действия.

5) Примеры формулировок (фрагменты)

5.1 Доступность и измерение

«Провайдер обеспечивает 99.95% доступности в каждый календарный месяц. Доступность измеряется внешним синтетическим мониторингом Заказчика из ≥3 регионов с интервалом ≤1 мин. Зафиксированная недоступность в ≥2 регионах одновременно считается инцидентом уровня SEV2 и засчитывается в Downtime.»

5.2 Латентность ключевого API

«p99 времени ответа `POST /payments/authorize` ≤ 450 мс в 95% дней месяца. Для доли запросов, превышающих порог, предоставляется отчет с анализом причин.»

5.3 Инциденты и эскалации

«S1: ack ≤ 15 мин, апдейты каждые ≤ 30 мин, целевое восстановление ≤ 2 ч; S2: ack ≤ 30 мин, апдейты ≤ 60 мин; S3: следующий рабочий день. Каналы: телефон 24×7, чат-бридж, email.»

5.4 Возмещения (кредиты)

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

Кредиты не исключают иных способов возмещения ущерба при грубой небрежности.

5.5 Депрекейты и совместимость

«Не менее 180 дней уведомления для изменений, ломающих совместимость. Параллельная поддержка vN и vN+1 не менее 90 дней.»

5.6 Выход (Exit)

«В течение 30 дней после расторжения провайдер бесплатно предоставляет полный экспорт данных в форматах Parquet/JSON + схемы; дополнительные услуги миграции — по тарифу X. Уничтожение копий подтверждается актом.»

6) OLA: внутренняя опора для внешнего SLA

• Цели: p99 gateway ≤ 200 мс, error rate ≤ 0.3%, DR: RPO 0, RTO 30 мин.
• Ответственность: SRE-on-call, 24×7; общие дашборды и алерты.
• Процессы: хаос-смоук в релизах, перф-смоук на PR, эвристики шейдинга.
• Гейты: блок деплоя при провале SLO/хаос-теста; обязательное обновление runbook.

7) Мониторинг и доказательства

Синтетика: внешние пробы (HTTP/TCP), путь пользователя, «медленный успех».
RUM: реальный пользовательский мониторинг для подтверждения влияния.
Корреляция: метки `provider`, `region`, `api_method`, `incident_id`.
Артефакты: скриншоты/трейсы/логи, экспорт KPI, хронология эскалаций.

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

8) Инциденты и взаимодействие

1. Классификация SEV, открытие war-room, назначение IC.

2. Уведомление провайдера по «горячему каналу», передача артефактов.

3. Обходные режимы/фича-флаги (stale, шейдинг, rate-cap).

4. Совместный таймлайн, восстановление.

5. Постмортем + действия: обновление конфига лимитов, ключей, резервных маршрутов.

6. Инициация кредитов по SLA, фиксация в биллинге.

9) Безопасность и DPA

DPA/приватность: роли контроллера/процессора, категории данных, база законности, сроки/цели обработки, субпроцессоры и их SLA.
Шифрование: TLS1.2+, PFS; данные «на покое», управление ключами (KMS/HSM), ротация.
Аудит: логи доступа, уведомления о нарушениях ≤ 72 ч, пентест-отчеты по запросу.
Локализация: регион хранения, запрет вывоза без согласия.

10) Supply Chain и совместимость

SBOM/уязвимости: политика CVSS-порогов и сроки исправлений (критикал ≤ 7 дней, high ≤ 14).
Совместимость API: контрактные тесты, «песочницы» и стабильные фикстуры.
Изменения провайдера: ранние релиз-ноты, превью/бета-окна, обратная совместимость.

11) Многопровайдерность и фейловер

Active/Active: сложнее и дороже, но выше доступность (учтите консистентность).
Active/Passive: холодный/теплый резерв, регулярные тренировки DR.
Абстракции/адаптеры: единый контракт, маршрутизация по здоровью/стоимости/углеродному фактору (если релевантно).
Лицензионные/коммерческие условия: переносимость, ограничение на вывод данных, стоимость egress.

12) Exit-план и периодические репетиции

Каталог данных/схем и объемы.
Сценарий переносимости SDK/API (минимум — second source).
Тест «сухого выхода»: экспорт/импорт, восстановление, проверка инвариантов.
Юридические сроки хранения/удаления после выхода.

13) Тесты контракта и conformance

Пробы API: позитив/негатив, лимиты, ошибки и ретраи.
Доставка событий/вебхуков: подпись/время/дедуп/повторы.
Перф-базлайны: p99, пропускная способность; регресс-тесты по релиз-заметкам провайдера.
Кросс-регион: деградация одного региона не должна нарушать SLO глобально.

14) Анти-паттерны

SLA «на статус-странице» без внешних измерений.
Одинаковые цели для всех регионов/эндпоинтов.
Отсутствие прав на аудит и подробных журналов инцидентов.
Нет OLA/UC → внешние обязательства некому выполнять внутри.
Неопределенный exit-план → заложничество поставщика.
«Штрафы только кредитами» без права расторгнуть при систематических нарушениях.
Депрекейты без переходного окна.

15) Чек-лист архитектора

1. Определены SLI/SLO для ключевых флоу и регионов?
2. Выбран способ внешнего мониторинга и доказательная база?
3. В SLA прописаны инциденты, эскалации, окна плановых работ и лимит исключений?
4. Есть кредитная шкала/штрафы и право расторжения при N нарушениях?
5. DPA/безопасность: шифрование, журналы, уведомления, субпроцессоры, локализация?
6. Контрактные тесты и песочницы в пайплайне?
7. Внутренние OLA/UC обеспечивают выполнение внешних SLO?
8. DR: заявлены RPO/RTO, проводятся тренировки, есть отчеты?
9. Exit-план: форматы экспорта, сроки, практика «сухого выхода»?
10. Гейты в CI/CD блокируют релизы, увеличивающие риск нарушения SLA?

16) Мини-примеры (скетчи)

16.1 Политика «деплой-гейт» по риску провайдера

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 Экспорт «доказательств инцидента»

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 Контрактный тест вебхука (псевдокод)

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

Заключение

SLA/OLA — это не только «юридическая бумага», а архитектурный механизм управления риском и качеством. Правильные метрики и окна, внешний мониторинг, четкие процедуры инцидентов и возмещения, внутренние OLA/UC, гейты в пайплайнах, мульти-поставщики и реальный exit-план превращают зависимость от провайдеров в контролируемую, измеряемую и экономически предсказуемую часть вашей платформы.