Наблюдаемость и контроль состояния
1) Цели и принципы
Цель: в реальном времени понять “что происходит” и “почему”, чтобы предупреждать инциденты и быстро восстанавливаться, не нарушая SLO и не раздувая OPEX.
Принципы: SLO-first, “золотые сигналы” (latency, traffic, errors, saturation), единый стандарт телеметрии (OpenTelemetry), минимально достаточные детали, объяснимость, cost-aware наблюдаемость.
2) Слои наблюдаемости
1. Метрики: агрегаты для SLI/SLO, capacity и трендов (RED/USE-модели).
2. Трейсы: причинно-следственные цепочки запросов, платежных и игровых транзакций.
3. Логи/ивенты: детальный контекст и аудит действий операторов/сервисов.
4. Синтетика (black-box): внешние проверки API/веб-путей, PSP/KYC хелс-пинги.
5. RUM (реальный пользователь): фронтовые метрики (TTFB, LCP, JS-ошибки), гео/девайс срезы.
6. Низкоуровневая телеметрия: eBPF/профайлинг CPU/IO/alloc, сетевые перцентильные задержки.
3) Набор SLI и “золотые сигналы”
Latency: p50/p95/p99 по критичным путям (логин, депозит, ставка, вывод).
Errors: доля 5xx/timeout/decline (с нормализацией по провайдерам/банкам).
Traffic/Throughput: RPS/TPS, активные сессии, события/сек.
Saturation: загрузка CPU/RAM/IO, глубина очередей, pool-usage, replication lag.
Бизнес-SLI: успешные депозиты/ставки % за окно, отклонения конверсии KYC/PSP, доля chargeback.
4) Архитектура телеметрии
Стандартизованный инжест: OpenTelemetry SDK/collector → нормализация, семплинг, privacy-фильтры → хранилища (TSDB, трассировки, логи).
Корреляция: trace-id/span-id в логах и метриках (exemplars); единые correlation-id для платежей/игровых событий.
Топология: сервис-мапа (service graph), зависимые внешние провайдеры с живыми SLI.
Управление стоимостью: уровни ретенции, агрегации, динамический семплинг, “горячие”/“холодные” классы хранения.
5) Метрики: дизайн и кардинальность
Правила: малое число лейблов, запрет на high-cardinality (userId, sessionId) в time-series; такие детали — только в трассы/логи.
RED/USE: Requests-Errors-Duration для API; Utilization-Saturation-Errors для инфраструктуры.
Exemplars: привязка высоких перцентилей к конкретным trace-примерам.
Бизнес-метрики: $/RPS, конверсия PSP по банкам/ГЕО, отказоустойчивость провайдеров.
6) Трейсинг: глубина и семплинг
Контекст: прокидываем trace-контекст сквозь фронт → API → брокеры → воркеры → БД/PSP.
Семплинг: базовый 1–10%, при аномалиях — динамическое повышение по правилам (tail-based).
Фокус: платежные флоу (init → auth → capture/settle), игровые транзакции (bet → settle), KYC (init → verify).
Аннотации: PSP-код ответа, bank-BIN/issuer-категория, регион, риск-скор.
7) Логи и аудит
Структурированные логи: JSON, уровень по профилю (INFO на проде, DEBUG в отладке).
Фильтры приватности: маскирование PII, запрет сырых документов KYC в логах.
События аудита: кто/что/где/когда/зачем, ID тикета, pre/post значения для высокорисковых операций (бонусы, лимиты, PSP-роутинг).
Неподменяемость: WORM/immutable, подпись, ретеншн по политике.
8) Контроль состояния (health)
Liveness/Readiness/Startup: правильные пробы (не проверять внешние зависимости в liveness).
Degraded-mode: явные флаги деградации сервиса, чтобы алерты и страница статуса были согласованы.
Budget health: burn-rate бюджета ошибок (быстрое/медленное окно), headroom по ресурсам и очередям.
9) Алертинг и раннее предупреждение
SLO-алерты: по бюджету ошибок (4-часовые и 1-часовые окна) вместо “сырого” p95.
Аномалии: STL/IQR/онлайн-детекторы для всплесков 5xx, падения авторизаций PSP в конкретном ГЕО/банке.
Root-cause hints: связываем алерты с последними релизами/фичефлагами/плановыми работами.
Runbooks: у каждого алерта — линки на плейбук, графики, “быстрые проверки”.
10) Дашборды (кто и что видит)
Exec: аптайм/SLO, burn-rate, успешные депозиты/ставки, статус провайдеров, прогноз емкости и $/RPS.
SRE/платформа: RED/USE по сервисам, очереди/lag, pool-usage, replication lag, CDN/WAF, eBPF-профайлы.
Payments/Risk: успехи авторизаций по PSP/банкам/GEO, soft/hard declines, время KYC, chargeback early-signals.
Support/CS: статус-панель инцидентов, SLA ответов, FAQ-макросы.
11) Управление стоимостью наблюдаемости (FinOps-Observability)
Ретеншн: 7–14 дней для “сырых” трасс, агрегаты дольше; выборочно — горячие сервисы.
Сэмплинг/агрегация: динамический семплинг по аномалиям, downsampling старых рядов.
Ингест-политики: отсечь шум (health-пинги, избыточные логи), квоты на high-cardinality метрики.
KPI стоимости: $/GB ingest, $/trace, $/SLI дашборда; периодические ревью топ-пожирателей.
12) Приватность и комплаенс
PII/финансы: маскирование, токенизация, минимизация данных в телеметрии.
Гео-локализация: хранение и обработка по юрисдикции; лог-экспорт — только через утвержденные workflow с шифрованием и TTL.
Аудит доступа к телеметрии: RBAC/ABAC, SoD для выгрузок, журнал запросов.
13) Интеграция с инцидент-менеджментом и релизами
Статус-страница: автоматический фид апдейтов из инцидент-карточки.
Релиз-гейт: канареечный анализ по SLI, авто-стоп релиза при burn-rate>порог.
Post-mortem: таймлайн из трасс/логов, фактические SLI и окна нарушения.
14) Практическая методика внедрения (8–12 недель)
Нед. 1–2: инвентаризация критичных путей и SLI; выбор стека (OTel, TSDB, логи, трассы); карта зависимостей.
Нед. 3–4: внедрение OTel в 3–5 ключевых сервисов (логин/депозит/ставка), базовые RED/USE, trace-контекст в логи.
Нед. 5–6: SLO и burn-rate-алерты; синтетика по PSP/KYC; первые runbooks; RUM на веб/мобайл.
Нед. 7–8: динамический семплинг, exemplars, сервис-мапа; дашборды Exec/SRE/Payments.
Нед. 9–10: eBPF/профайлинг горячих узких мест; privacy-фильтры; квоты/ретенции.
Нед. 11–12: релиз-гейты и авто-rollback по SLI; интеграция со статус-страницей; tabletop-учения.
15) Шаблоны артефактов
SLO-карта сервиса: SLI, цели, окна, бюджет ошибок, алерты, владельцы.
Alert Spec: метрика/условие, пороги, дедуп/сайленс, получатели, runbook.
Dashboard Spec: аудитория, вопросы, 6–8 виджетов, источник данных, частота обновления.
Telemetry Policy: какие поля допустимы/запрещены, ретеншн, маскирование, экспорт.
Cost Review Pack: топ-серии/лог-потоки, предложение по сэмплингу/TTL, ожидаемая экономия.
16) KPI функции наблюдаемости
MTTA/MTTR (улучшение после внедрения SLO-алертинга).
% инцидентов, обнаруженных синтетикой/SLI до жалоб пользователей.
Доля релизов, прошедших гейт по SLI без ручного вмешательства.
Снижение $/RPS на телеметрию при сохранении диагностичности.
Покрытие трассингом критичных путей (>90%).
Точность корреляции “апдейт статуса ↔ фактические SLI”.
17) Антипаттерны
“Все логируем” → взрыв стоимости и шум.
Алерты по “сырым” метрикам вместо SLO/burn-rate → pager-fatigue.
Высокая кардинальность метрик (userId) → TSDB-штормы.
Трейсы без контекста бизнеса (PSP/банк/GEO) → нет инсайта.
Нет связи наблюдаемости с релизами/инцидентами → телеметрия живет отдельно.
Итог
Наблюдаемость и контроль состояния — это не набор инструментов, а управляемая система: правильные SLI/SLO → стандартизованная телеметрия и корреляция → SLO-алертинг и runbooks → интеграция с релизами и статус-коммуникацией → cost-aware эксплуатация и приватность. Такой контур дает ранние сигналы, быстрое RCA и устойчивость бизнеса даже в экстремальных пиках трафика.