Технології та Інфраструктура → AI-Ops і автономні системи
AI-Ops і автономні системи
1) Що таке AI-Ops
AI-Ops - це застосування ML/AI до операційних даних (логи, метрики, трейси, події релізів/інцидентів), щоб:- раніше виявляти проблеми (антиципація інцидентів),
- автоматично усувати збої (auto-remediation),
- оптимізувати вартість і продуктивність (предиктивний скейлінг, інтелектуальний роутинг),
- прискорювати аналіз інцидентів (кореляція сигналів, генерація постмортемів).
1. відчувати (збирати телеметрію),
2. розуміти (моделі, евристики, правила),
3. діяти (виконувати безпечні зміни в проді за ранбуками),
4. вчитися (замикати петлю зворотного зв'язку через пост-інцидентну аналітику).
2) Шари AI-Ops-архітектури
1. Збір телеметрії (Observability 3-в-1): метрики (Prometheus/OTel), логи (Loki/ELK), трейси (OTel/Jaeger).
2. Збагачення та фіче-інжиніринг: агрегації, ковзні вікна, сезонність, бізнес-мітки ('partner','game _ id','region','VIP','psp').
- детекція аномалій (STL, Prophet, Isolation Forest, автокодувальники),
- причинно-наслідкові графи (кореляції залежностей),
- класифікація інцидентів і пріоритизація (ML + доменні правила SRE).
- 4. Рішення та дії: ранбуки, авто-ретраї, перемикання трафіку, авто-скейлінг, зміна лімітів, фоловер-роутинг.
- 5. Людино-машинний контур: LLM-копілот для NOC/SRE, чат-команди, «what-if» симуляції.
- 6. Губернація і безпека: схвалення, вікна змін, катастрофні стоп-умови, аудит.
3) Джерела даних і фічі
Інфраструктура: CPU/Memory/IO/Latency, помилки мереж, поди/ноди K8s, ліміти/requests, node pressure.
Сервіси: RPS/P50/P95/P99, 4xx/5xx, saturations, помилки ретраїв, circuit-breaker події.
Бізнес-сигнали: registratsiya→depozit (CR), GGR/Net Deposits, відмова PSP за кодами, VIP-трафік, турніри, промо-кампанії.
Екстра-фактори: релізи/фічефлаги, регуляторні звіти, платіжні вікна банків, матчі/івенти (піки ставок).
Корисні фічі: тижнева/годинна сезонність, лаги, rolling-поли, rate-of-change, error-mix за кодами, дельти versiya→versiya, saturation-score.
4) Кейси застосування
4. 1 Раннє виявлення інцидентів
Аномальне зростання відмов'psp _ decline _ rate'в регіоні → автоматичний фейловер на резервний PSP, обмежений за сегментами (не чіпаючи VIP).
Нестандартний патерн затримок трейсів в ланцюжку'web → gateway → wallet'→ авто-шифт трафіку на здорові поди, прогрів кеша, перезапуск деградуючих інстансів.
4. 2 Предиктивний капасіті-менеджмент
Прогноз RPS з урахуванням матч-розкладів і промо → попереджувальний скейлінг K8s, прогрів з'єднань до БД/кешу, білінг-квоти хмари.
Економія: зниження оверсайзингу поза піками при збереженні SLO.
4. 3 Авто-ремедіація (self-healing)
Помилка «stuck payouts queue» → ранбук: пауза консьюмера, дедуплікація, репроцес з DLQ, контроль ідемпотентності.
Degraded shard БД → евакуація читань, перемикання writer, throttling фонових джобів.
4. 4 Кореляція і RCA
ML-кластеризація алертів (alert storms) + причинні графи → один «інцидент-картка» замість десятків повідомлень.
Авто-генерація таймлайну інциденту і чернетки постмортема.
4. 5 Копілот для NOC/SRE (LLM)
Команда: «Покажи все, що змінилося за 15 хв до сплеску 5xx по/v2/payouts в регіоні EU».
Відповідь: diff конфігів, реліз-ноти, дельти метрик, порушені поди, гіпотези + кнопки «запустити ранбук».
5) Патерни прийняття рішень
Safe-automation: дія тільки в «зеленому коридорі» (гардрайл: max% трафіку, max крок скейла, список дозволених команд).
Human-in-the-loop: критичні кроки (перемикання БД master, масові фічефлаги) - з підтвердженням on-call.
Мультисигналність: тригер - не один алерт, а узгодженість: метрики + трейси + лог-патерн + ознака релізу.
Canary-ремедіація: спочатку застосувати до 1-5% трафіку, потім ескалувати.
Rollback-by-design: у кожної дії є зворотний крок і таймаут.
6) Ранбуки (Runbooks) і плейбуки
Структура ранбука: умова → верифікація → дії → валідація → відкат → журнал.
Приклади:- PSP відмова> X% в країні Y: перемкнути на роут B, знизити'retry _ budget', активувати кеш лімітів, відкрити тікет до PSP.
- Зростання latency в wallet-сервісі: збільшити репліки, прогріти Redis-ключі «ліміти», включити «read-only» режим для важких звітів, обмежити сторонні агрегації.
7) Моделі: від простого до зрілого
1. Базові правила і STL-сезонність: швидкий старт, мало фолс-позитивів.
2. Supervised-моделі на інцидент-історії: класифікатор «критичності/субсистеми», підказка RCA.
3. Unsupervised/Deep: автоencoder/Isolation Forest для складних патернів.
4. Policy-Learning: навчання політик ремедіації (offline-симуляції + обмежені онлайнові експерименти).
Важливо: моделі ≠ магія. Робіть ретроспективну оцінку, контроль дрейфу, champion-challenger, і зберігайте фічі/лейбли.
8) A/B та експериментування в операціях
Експерименти над операційними рішеннями: різні стратегії ретраїв/таймаутів, маршрутизація PSP, ліміти з'єднань.
Метрики успіху: MTTR, error budget burn, cost-per-RPS,% фолс-автофіксів.
Стоп-умови і швидка зупинка при деградації SLO.
9) Губернація, ризик і відповідність
Політика дій: перелік допустимих автоматизацій, зони ризику, вікна змін, рівні схвалень.
Аудит і трасування: хто/коли/чому запустив ранбук; артефакти для постмортему.
PII/PCI: маскування у фічах/логах, мінімізація даних, секрет-скани.
Регуляторика iGaming/фінтех: прозорість рішень (explainability), логіка зупинок виплат/лімітів повинна бути відтворювана і пояснима.
10) Інструментарій (референс-стек)
Observability: OpenTelemetry, Prometheus, Grafana/Tempo/Jaeger, Loki/ELK.
Каталоги та знання: сервіс-каталог, залежність графів, inventory конфігів/фічефлагів.
ML-пайплайни: Feature Store, оффлайн-DWH + онлайн-фічі, модель-регістр, CI/CD моделей, drift-моніторинг.
Автоматизація: оркестратор ранбуків (Argo/StackStorm/自opisnyye), K8s оператори, GitOps (Argo CD/Flux).
Інциденти: чат-опс (Slack/Telegram/Teams), сторожові боти, шаблони постмортемів.
Безпека: Vault/KMS, політика ключів, mTLS, підпис артефактів.
11) Метрики зрілості AI-Ops
Виявлення: частка інцидентів, помічених до скарг користувачів; середнє випередження виявлення.
Реакція: MTTA/MTTR,% авто-ремедіацій без ескалації, якість RCA (precision/recall).
Надійність: burn-rate, SLO adherence, «шум» алертів (alerts per on-call hour).
Економіка: економія $ на обчисленнях (rightsizing), зниження відхилень від бюджету, cost-per-transaction.
Культура: частка інцидентів з постмортемами, покриття сервісів ранбуками, швидкість впровадження правил.
12) Покроковий план впровадження
1. Телеметрія і єдиний словник сигналів. Обов'язкові лейбли: `service`, `version`, `region`, `partner`, `api_version`.
2. Анти-шум і кореляція. Дедуплікація алертів, угруповання по інциденту.
3. Бібліотека ранбуків. Сценарії для топ-10 ризиків (платежі, wallet, каталоги ігор, турніри, звіти).
4. Первинні моделі. STL/Prophet + правила; пілот на 2-3 сервісах.
5. Копілот і чат-опс. Натуральні запити, швидкі дії, шаблони постмортемів.
6. Гардрайли і контроль. Canaries, ліміти на дії, журнал аудиту.
7. Експерименти та навчання. Champion-challenger, A/B, ретроспективна оцінка вигоди.
8. Масштабування. Підключення всіх критичних потоків, навчання команд, SLO-рев'ю.
13) Приклади політик і конфігів
13. 1 Політика авто-скейлінгу (ідея)
Попереджувальний скейлінг при прогнозі RPS> P95 останнього тижня на + X%.
Холодний старт: прогрів з'єднань до Redis/PSP, прогрівши кешів.
Стоп-умова: помилка 5xx зростає після скейла → відкат.
13. 2 Ранбук «PSP деградація»
1. Перевірити'psp _ error _ rate> T'і'region in {BR, TR}'.
2. Увімкнути smart-routing на PSP-B тільки для non-VIP; обмежити'max _ retries = 2'.
3. Створити тікет PSP-A; зібрати 100 запитів/відповідей для RCA.
4. Моніторити CR депозиту і T2W (time-to-wallet). Відкат при погіршенні> Y%.
13. 3 Шаблон постмортема (з автогенерацією)
Детектор → Таймлайн → Гіпотези → Вплив (користувачі/дохід) → Дії → Уроки → Зміни ранбуків/моделей.
14) Анти-патерни
«Чорний ящик» без гардрайлів: боти правлять продом без лімітів і аудиту.
Моделі без даних про бізнес-події: бачать CPU, але не розуміють промо/матчі.
Алерт-шторми: відсутність кореляції → у on-call «тунельний зір».
Авто-ремедіації без відкату/валідації результату.
«Вічні пілоти»: немає виходу на реальні дії, тільки дешборди.
Відсутність постмортемів - немає навчання системи.
15) Контекст iGaming/фінтех
Піки навантаження (турніри, лайв-ставки, фінали): предиктивний скейлінг, прогрів кешів, підготовка лімітів PSP.
Відповідальні ігри/ліміти: моделі не повинні знімати ліміти гравця автоматично без правил відповідності.
Регуляторні вікна звітності: розкладу завантажень, SLA на вивантаження, пріоритет черг.
Мульти-PSP: динамічна маршрутизація по країнах, часу доби, кодам помилок, вартості транзакції.
VIP-сегмент: окремі гардрайли - ніяких агресивних дій без підтвердження (human-in-the-loop).
16) Чек-лист готовності
1. Єдиний шар OTel, уніфіковані лейбли і траси крізь шлюз.
2. Карта залежностей сервісів і версій (service topology).
3. Каталог ранбуків з симуляціями та unit-тестами.
4. Мінімум одна модель аномалій в проді + звіт про якість.
5. Чат-копілот, здатний читати логи/метрики і запускати безпечні дії.
6. Гардрайли, канарки, відкати, аудит змін.
7. Регулярні постмортеми та оновлення знань/моделей за підсумками.
Підсумок
AI-Ops - це не «магічний ШІ поверх логів», а дисципліна: якісна телеметрія, зрозумілі ранбуки, обережні автоматизації та контрольовані моделі. Впроваджуючи петлю спостерігати → розуміти → діяти → вчитися з чіткими гардрайлами, ви отримаєте самозцілювану платформу, яка раніше помічає ризики, швидше відновлюється і дешевше обходиться бізнесу.