Модуль 5.1. Производительность, масштабирование, надёжность
Темы: SLO/SLA/SLI, SLO-деревья, RPS/latency/throughput, очереди и backpressure, кэширование, горизонталь/вертикаль, режимы деградации. Артефакт: NFR-каталог. Практика: NFR для 3 критичных сценариев.
Зачем модуль
Системный аналитик (SA) должен переводить бизнес-ожидания («чекаут не должен тормозить») в измеримые не-функциональные требования (NFR): целевые задержки, доступность, пропускную способность, стратегии масштабирования и деградации. Этот модуль даст вам язык, формулы и шаблоны — чтобы договориться с бизнесом, написать проверяемые критерии и построить систему мониторингов/алертов.
Базовые определения (как сотруднику — к исполнению)
- SLI (Service Level Indicator) — измеряемый показатель: p95 latency, error-rate, availability, throughput.
- SLO (Service Level Objective) — целевое значение SLI: «p95 POST /payments < 3 с в 8:00–23:00, 99% дней месяца».
- SLA (Service Level Agreement) — юридическое соглашение с последствиями (штрафы/кредиты). Внутри компании чаще работаем с SLO.
- Error Budget = 1 − SLO по доступности (на период). Например, при 99.9%: 43.2 мин «бюджета» в месяц.
Нормы для формулировки SLO
- Указывайте метрику, окно, время суток, зону времени, популяцию запросов (например, «успешные 2xx+3xx, RU-регион»).
- Для задержек — квантили (p95/p99), не среднее.
- Для доступности — доля успешных запросов (исключая planned maintenance по договорённости).
SLO-деревья: каскад целей и составная доступность
Большинство сценариев используют несколько сервисов. Составная доступность «в серии» = произведение доступностей:
A_total = A_gateway × A_checkout × A_payments × A_db Пример: 0.999 × 0.999 × 0.999 × 0.999 ≈ 99.6%
Параллель (fallback/реплика):
A_parallel = 1 − Π(1 − A_i)
Пример: два независимых PSP по 99.0% → A ≈ 99.99%
Как строить SLO-дерево
- Возьмите бизнес-SLO («Оформление заказа» ≥ 99.8% успешно, p95<2.5s).
- Разложите на под-SLO по зависимостям (Gateway, Checkout API, Payments, DB, кэш).
- Заложите бюджеты (кто сколько «съедает»).
- Добавьте операционные SLO: очереди (lag), кэши (hit-ratio), фоновые воркеры (время обработки).
Производительность: RPS, задержки, throughput
- RPS — запросов в секунду (по эндпоинту/классу).
- Throughput — скорость обработки фоновых задач/сообщений.
- Допустимая загрузка: ρ = λ/μ (Литтл/очереди). ρ→1 ⇒ рост хвостов задержек (tail latency).
- Headroom: запас мощности (обычно целимся в ρ ≤ 0.6–0.7 на пике).
Типовые целевые задержки (ориентиры)
- UI-критичные GET — p95 200–500 мс.
- Мутации (POST платежа) — p95 1–3 с.
- Фоновые задачи — SLA в минутах (например, «PDF-счёт ≤ 2 мин p95»).
Очереди, backpressure и ретраи
Когда пиковая нагрузка выше пропускной способности, спасают очереди и обратное давление:
- Очередь (work queue): сглаживает пики, защищает бэкенд. Важны prefetch, лимиты конкурентности, DLQ, ретраи с экспонентой + jitter.
- Backpressure: ограничение потребителя (tokens/leaky bucket), 429/503 + Retry-After.
- Идемпотентность обязательна (повторы неизбежны).
- Lag SLO: «p95 lag < 5 сек в 9:00–22:00».
Кэширование: где и как
Паттерны:
- Cache-Aside (читатели/заполнители) — самый частый.
- Read-Through — приложение не знает о кэше.
- Write-Through — запись сразу и в кэш и в БД.
- Write-Behind — запись в БД асинхронно (риск потери при сбое).
Ключевые SLI кэша:
- Hit Ratio (глобально и по ключевым наборам).
- Staleness (возраст данных), E2E latency.
- Warm-up политика и invalidation (события/TTL/версионирование ключей).
Риски:
- Двойное инвалидационное обновление → рассогласование. Решение: версионированные ключи или event-driven инвалидация.
- «Горячие ключи» → лок: используйте singleflight/locking и jitter для TTL.
Масштабирование: вертикаль vs горизонталь
- Вертикаль (больше CPU/RAM): быстро, но потолок и цена растут нелинейно.
- Горизонталь (больше инстансов/шардов): требует статус-лесса, sticky-балансировки, идемпотентности, шардирования БД.
Шаблон решения:
- Статус-лесс сервисы (состояние — во внешних хранилищах/кэше).
- Autoscaling по метрикам (CPU/RPS/queue-depth/p95).
- DB: read-реплики, партиционирование, шардинг (по ключу домена).
- Хранение: CDN, объектное, асинхронные загрузки.
Надёжность: отказоустойчивость и деградации
Паттерны устойчивости:
- Timeouts и Circuit Breakers (fail-fast).
- Bulkheads (изоляция пулов/ресурсов).
- Rate Limits/quota.
- Retry только для retryable ошибок (5xx/timeout), с jitter.
- Chaos/Failure Injection — тренировка.
Режимы деградации (заранее описанные «ступени»):
- Мягкая деградация: кэшированные/устаревшие данные (stale-while-revalidate), частичные ответы, скрыть «тяжёлые» блоки UI.
- Функциональная деградация: временно выключить вторичные фичи (рекомендации/история).
- Ограничения: только предоплата, запрет редких методов.
- Read-only: сохраняем поиск/каталог, блокируем создание.
- Техработы: информируем, используем бюджет ошибок.
Все режимы должны иметь явные фичефлаги, AC и сценарии отката.
Тесты производительности и ёмкости
Типы:
-
Baseline (нормальный режим), Stress (рост до деградации), Spike (резкий всплеск), Soak (длительный), Failover (отказ узла).
Что фиксировать: профили по RPS, p50/p95/p99, ошибки, saturations (CPU/IO/db-connections), точки слома, деградации.
Критерии готовности:
- «Пик ×2» укладывается в SLO.
- Нет локальных горячих точек (один инстанс/шард «горит»).
- План включения деградаций документирован/проверен.
Что именно должен сделать SA
- Сформировать NFR по сценариям (SLO/SLA, окна, оговорки).
- Построить SLO-дерево и распределить бюджеты.
- Утвердить профили нагрузки (обычный/пик/анонс/праздник).
- Описать очереди/кэш: где, какие цели hit-ratio/lag.
- Прописать режимы деградации и правила ретраев.
- Подготовить каталог NFR и связать его с AC/RTM.
- Включить обсервабилити в требования: трассировка, метрики, логи, алерты.
Примеры формулировок (готовые блоки)
Чекаут → «Создание платежа»
- SLO-latency: p95 < 2.5 с (08:00–23:00, RU), p99 < 5 с.
- Availability: ≥ 99.9%/квартал (исключая 1 плановое окно/мес ≤ 30 мин).
- Throughput: выдерживать 250 RPS (пик) с headroom 30%.
- Retry policy (client): 2 попытки на 5xx/timeout с экспонентой (100/300 мс + jitter).
- Idempotency: Idempotency-Key TTL 72ч.
- Degradation: при PSP UNAVAILABLE — 202 Accepted + вебхук/поллинг.
Каталог → «Поиск»
- SLO-latency: p95 GET /search < 300 мс (CDN+кэш), p99 < 800 мс.
- Hit-ratio кэша: ≥ 0.85.
- Degradation: отсутствие рекомендаций/фасетов при cache_miss_rate > 0.3.
Отчёт DWH → «Выручка дневная»
- Freshness: p95 freshness ≤ 15 мин 08:00–23:00.
- Completeness: ≥ 99.9% записей за день к 00:30+1.
- Integrity: 0 несогласованностей сумм (refund ≤ captured).
- Backfill: за 90 дней идемпотентный, окна по датам.
Артефакт: NFR-каталог (шаблон)
# NFR Catalog vX.Y.Z Owner: <Команда/Сервис>, SA: <ФИО>, Контакты: <#канал> ## Сценарий: <Короткое имя, например "Checkout: CreatePayment"> Бизнес-значимость: High | Medium | Low Популяция: RU, web+mobile, 8:00–23:00 (Europe/Stockholm) ### Цели (SLO) - Latency: p95 < ...; p99 < ...; окно: ... - Availability: >= ...% / период: ... - Error rate: < ...% - Throughput: >= ... RPS (пик), headroom >= ... - Queue Lag: p95 < ... сек (если применимо) - Cache: hit-ratio >= ...; staleness <= ... ### Ограничения/допущения - Исключаем planned maintenance до ... мин/мес - Внешний PSP с SLA 99.0% → fallback ... ### Деградации (ступени) 1) Кэш-только ответы (TTL=...); отключить X 2) Ограничение RPS до ... 3) Read-only режим / 202 Accepted для мутаций ### Ретраи/идемпотентность - Классы ошибок «ретраим»: ... - Политика: attempts/backoff/jitter - Idempotency-Key TTL: ... ### Обсервабилити и алерты - Метрики: latency p95/p99, error_rate, rps, queue_depth, cache_hit - Алерты: условия и каналы - Trace: `traceparent` + `correlationId` обязателен ### Тесты и приёмка - Perf: baseline/stress/spike/soak - Failure: отключение PSP, падение реплики БД - Критерии: ... ### Риски и планы - Риск: ... | План: ...
Практические мини-расчёты и правила большого пальца
Сколько инстансов нужно?
Нагрузка: пик 250 RPS, p95 2.5с, среднее CPU 30% на 1 pod при 50 RPS.
Требуется: минимум 250/50 = 5 pod (+ headroom 30%) → 7 pod.
Очередь и воркеры
Вход: 1 200 задач/мин (20/с). Средняя обработка 150 мс → μ ≈ 6.7/с на воркер.
Воркеров: λ/μ ≈ 20/6.7 ≈ 3 → с запасом 5–6.
Lag SLO: держим p95 < 5 сек.
Глобальные доступности
SLO чекаута 99.8% при PSP=99.0% только с параллельным PSP или асинхронным 202 Accepted.
Риски и меры (таблица)
|
Риск |
Проявление |
Меры |
|---|---|---|
|
Хвостовая задержка (p99) |
Пользователи «подвисают» |
Таймауты короче серверных, CB, пулы, ограничение конкурентности, профилирование GC/IO |
|
RETRY-шторм |
Всплеск дублей, лавинообразная нагрузка |
Экспонента+джиттер, лимиты попыток, классификация ошибок, идемпотентность |
|
Горячие ключи кэша |
Шипы латентности, шторм к БД |
Singleflight, pre-warm, шардирование, локальные кэши |
|
Общая БД для разных сервисов |
Блокировки/глухой монолит |
«БД на сервис», CQRS/витрины, события |
|
Отсутствие деградаций |
Полная недоступность |
План деградаций, фичефлаги, регулярные учения |
|
Наблюдаемость «вслепую» |
Долго ищем причины |
Обязательная трассировка, стандартизованные метрики и логи |
Вопрос–Ответ
Q: Чем SLO отличается от SLA?
A: SLO — внутренняя целевая метрика. SLA — юридический договор с компенсациями. Сначала формулируем SLO, потом (если нужно) SLA.
Q: Почему квантили (p95/p99), а не среднее?
A: Среднее скрывает хвосты, а пользователь страдает от p95/p99.
Q: Сколько закладывать headroom?
A: Обычно 20–40% к расчётной мощности на пике. Смотрите историю и «чёрные пятницы».
Q: Что важнее — кэш или шардирование БД?
A: Для чтений — кэш даёт мгновенный выигрыш. Для длительной устойчивости и записей — партиционирование/шардирование неизбежно.
Q: Можно ли «ретраить» POST без идемпотентности?
A: Нельзя. Всегда ключ идемпотентности/дедуп.
Q: Как выбирать целевую доступность?
A: По стоимости простоя и стоимости повышения надёжности. Иногда 99.5% лучше и дешевле, чем 99.99% (дорогая сложность).
Практика (90–120 мин): NFR для 3 критичных сценариев
Выберите 3 сценария (например: CreatePayment, Search, GenerateInvoice). Для каждого:
- Заполните карточку из NFR-каталога.
- Постройте SLO-дерево (серии/параллели, бюджеты).
- Определите режимы деградации и ретраи.
- Укажите метрики и алерты (условия/каналы).
- Подготовьте план перф-тестов (baseline/stress/spike/soak + failure).
Критерии зачёта
- SLO сформулированы точно (метрика, окно, популяция).
- Учтены доступность, задержки, throughput, кэш/очереди (если применимо).
- Есть SLO-дерево и расчёт составной доступности.
- Режимы деградации и ретраи описаны.
- Метрики/алерты привязаны к SLO, есть приёмочные перф-тесты.
Шпаргалка (распечатайте)
- SLI → SLO → (иногда) SLA. Ошибка бюджета управляет темпом изменений.
- Составная доступность в серии умножается — не обещайте сверхзначения без параллелей.
- Очередь + backpressure + идемпотентность — ваш «аварийный ремень».
- Кэш спасает задержку, но не забывайте про инвалидацию и горячие ключи.
- Горизонталь работает при статус-лессе и шардировании.
- Деградации проектируются заранее и регулярно тренируются.
- Наблюдаемость — часть NFR: трассы, метрики, логи, алерты.
