Спостережуваність і контроль стану
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 і стійкість бізнесу навіть в екстремальних піках трафіку.