Технологии и Инфраструктура → Облачная архитектура и SLA
Облачная архитектура и SLA
1) Зачем SLA и как ими управлять
SLA (Service Level Agreement) — внешнее обещание бизнесу/партнерам о доступности, скорости и корректности сервиса.
SLO (Service Level Objective) — внутренние целевые уровни для команд.
SLI (Service Level Indicator) — измеримые метрики, на основе которых оценивается SLO.
Для iGaming/финтех характерны жесткие окна пиков (турниры, лайв-ставки, отчетные периоды, «зарплатные» дни), сильная зависимость от PSP/KYC-провайдеров и географии. SLA должны учитывать это поведение, а архитектура — обеспечивать гарантии не только средние, но и перцентильные.
2) Базовая терминология
Доступность (Availability) — доля успешных запросов за интервал.
Латентность — P50/P95/P99 для ключевых операций.
Ошибка — определяйте точно (5xx, таймаут, бизнес-ошибка?).
RTO (Recovery Time Objective) — сколько времени допускается на восстановление.
RPO (Recovery Point Objective) — сколько данных можно потерять при аварии.
Error Budget — 1 − SLO, «запас» на изменения и инциденты.
3) Каркас облачной архитектуры под SLA
3.1 Многозонность (Multi-AZ)
Репликация состояния (БД, кэш, очереди) на минимум 2-3 AZ.
Холодные/теплые стэндбай, автоматический failover.
Локальные балансировщики (L4/L7) с health-чеками per-AZ.
3.2 Мультирегион
Актив-актив: низкие RTO/RPO, сложнее консистентность и стоимость.
Актив-пассив (hot/warm): дешевле, RTO больше, но проще контроль данных.
Географический роутинг (GeoDNS/Anycast), изоляция «blast radius».
3.3 Хранилища и данные
Транзакционные БД: синхронная репликация внутри региона, асинхронная межрегиональная.
Кэш: кросс-региональные реплики, режим «local reads + async warmup».
Объектное хранилище: версионирование, лайф-циклы, cross-region replication.
Очереди/стриминг: зеркальные кластеры/мульти-региональные потоки.
3.4 Изоляция контуров
Разделение критичных сервисов (payments/wallet) и «тяжелых» аналитических задач.
Rate-limits/quotas между контурами, чтобы отчеты не «съедали» прод.
4) Паттерны высокой доступности
Bulkhead & Pool Isolation — изоляция пулов соединений и ресурсов.
Circuit Breaker + Timeouts — защита от зависаний внешних интеграций.
Idempotency — повторяем запросы без двойных списаний.
Graceful Degradation — при деградации отключаем нефундаментальные фичи (аватарки, расширенные фильтры).
Backpressure — управляйте входящим потоком, не допускайте очередей «до горизонта».
Chaos/Failure Injection — плановые «провалы» для проверки гипотез надежности.
5) Стратегии DR (Disaster Recovery)
Выбор: платежи/кошелек — минимум Hot Standby; контент/каталог — Warm; отчеты — Backup & Restore с четкими окнами.
6) Про SLI/SLO: как мерить правильно
6.1 SLI по уровням
Клиентский SLI: end-to-end (включая шлюз и внешних провайдеров).
Сервисный SLI: «чистая» латентность/ошибки сервиса.
Бизнес-SLI: CR (регистрация→депозит), T2W (time-to-wallet), PSP-decline rate.
6.2 Примеры SLO
Доступность Core API: ≥ 99.95% за 30 дней.
Латентность payout-инициации: P95 ≤ 350 мс, P99 ≤ 700 мс.
Доставка вебхуков PSP: ≥ 99.9% в течение 60 сек (с ретраями).
Data Freshness отчетов: ≤ 10 мин лаг в 95% времени.
6.3 Error Budget Policy
50% бюджета — на изменения (релизы/эксперименты), 50% — на инциденты.
Сгорание бюджета → фриз фич, только стабилизация.
7) Производительность и масштабирование
HPA/VPA с SLO-ориентированными сигналами (не только CPU, но и очереди/латентность).
Предиктивный скейлинг на основе расписаний и исторических пиков.
Warm pools / предварительный прогрев соединений к БД/PSP перед турнирами.
Кэширование и edge — уменьшать RTT, особенно для каталогов игр и статических ассетов.
8) Сетевой слой и глобальный трафик
Anycast/GeoDNS для минимизации латентности и локализации аварий.
Failover-политики: health-пробы региона, пороги, «stickiness» с TTL.
mTLS/WAF/Rate Limit на краю, защита от бот-трафика.
Egress-контроль к PSP/KYC по allow-list и SLA-aware ретраям.
9) Данные и консистентность
Выбор уровня согласованности: строгая (payments) vs eventual (каталог/рейтинги).
CQRS для разгрузки чтения и вертикей критичных команд.
Outbox/Inbox для «ровно-однажды» доставки событий.
Миграции без даунтайма: expand-migrate-contract, двойная запись во время MAJOR-изменений.
10) Наблюдаемость (Observability) под SLA
Трейсы сквозь шлюз: корреляция `trace_id` с партнером/регионом/версией API.
SLO-дашборды с burn-rate, «погода» по регионам и провайдерам.
Алерты по симптомам, а не по симптомам-прокси (не CPU, а P99/ошибки).
Synthetics: внешние проверки из стран таргета (TR, BR, EU…).
Аудит и отчетность: экспорт SLI/SLO в партнерский портал.
11) Безопасность и комплаенс
Сегментация сетей и секрет-менеджмент (KMS/Vault).
Шифрование в полете/покое, токенизация PAN/PII.
Политики доступа по ролям для админок/операторок.
Логи неизменяемые (WORM) и ретеншн для аудита.
Регуляторика: хранение в регионе, отчеты, доказуемость выполнения SLA.
12) FinOps: SLA как драйвер стоимости
Ставьте цены на девиации SLO: сколько стоит +0.01% доступности?
Профилируйте пиковые окна, не раздувайте постоянную мощность.
Right-sizing и «spot где можно» для фоновых задач.
Квоты и бюджеты на контуры, не допускайте «бесплатной» деградации.
13) Тестирование надежности
GameDay/Chaos-сессии: выключение AZ/PSP, задержки в очередях, разрывы BGP.
DR-дрили: регулярный тренинг переключения регионов с целями по RTO.
Load & Soak: длительные прогонки с реальными профилями ставок/турниров.
Replay-инцидентов: библиотека известных фейлов и скрипты воспроизведения.
14) Процессная сторона SLA
Каталог SLO: владелец, формула, метрики, источники, алерты.
Изменения через RFC/ADR: оценка влияния на error budget.
Постмортемы: улучшение архитектуры и ранбуков, корректировка SLO.
Коммуникации с партнерами: рассылки, статус-страница, planned maintenance.
15) Примеры SLI/SLO/отчетов
15.1 Формулы
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15.2 Пример набора SLO для Core API
Доступность (30 дней): 99.95%
P95 эндпоинта `/v2/payouts/create`: ≤ 350 мс
Ошибки 5xx (скользящее 1 ч): < 0.3%
Webhook delivery ≤ 60 сек (P99): ≥ 99.9%
RPO для кошелька: ≤ 60 сек, RTO ≤ 5 мин
15.3 Отчет SLA (выжимка)
Выполнено: 99.97% (SLO 99.95%) +
Нарушения: 2 эпизода по региону BR из-за PSP-таймаутов (совокупно 8 мин).
Меры: добавлен smart-routing по кодам отказа, увеличен warm pool соединений к PSP-B.
16) Чек-лист внедрения
1. Определены критичные пользовательские пути и соответствующие SLI.
2. SLO на 30/90 дней + error budget policy.
3. Многозонность и план DR с целями RTO/RPO, регулярные дрили.
4. Synthetics из гео-таргета, дашборды per-region/per-PSP.
5. Паттерны устойчивости: circuit breaker, backpressure, idempotency.
6. Политика деградации и feature flags для отключаемых фич.
7. FinOps: бюджеты по контурам, прогноз пиков, warm pools.
8. Безопасность: сегментация, шифрование, аудит.
9. Документация SLA для партнеров, процесс коммуникаций.
10. Ретроспективы и пересмотр SLO каждые 1–2 квартала.
17) Анти-паттерны
Обещать SLA без измеримых SLI и прозрачной методики подсчета.
Считать доступность «на входе сервиса», игнорируя шлюз/провайдеров.
Опираться только на среднюю латентность, игнорируя хвосты P99.
DR «по бумаге», отсутствие реальных тренировок.
«Вечные» ресурсы без лимитов: один отчет валит прод.
Смешивать прод и тяжелую аналитику в одном кластере/БД.
18) Итог
Облачная архитектура под SLA — это сочетание технических паттернов (multi-AZ/region, изоляция, отказоустойчивые данные), процессов (SLO, error budget, DR-дрили) и экономики (FinOps). Дайте себе право на прогнозируемые сбои: тестируйте отказоустойчивость, меряйте по перцентилям, ограничивайте «взрывной радиус» и открыто коммуницируйте. Тогда обещания SLA станут не маркетингом, а управляемой инженерной практикой.