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/xaoc-тесту; обов'язкове оновлення 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-план перетворюють залежність від провайдерів в контрольовану, вимірювану і економічно передбачувану частину вашої платформи.