Інцидент-бот і чат-операції
1) Мета і цінність
Інцидент-бот - це інтерфейс управління інцидентом прямо з корпоративного чату (Slack/Teams/Telegram): одне введення тексту → дії в десятках систем. Він:- скорочує MTTA/MTTR за рахунок автоматизації рутини;
- створює єдиний контур фактів (SoT) і комунікацій;
- забезпечує доказовість (аудит, таймлайни, SLA апдейтів);
- знижує навантаження на on-call і «поховання» в консолях.
2) Ролі і RACI в чат-операціях
Incident Commander (IC) - власник інциденту: відкриття/закриття, пріоритет, рішення.
Comms Lead (CL) - тексти і розклад оновлень (зовнішні/внутрішні).
Domain Leads (Payments/Games/Core/Infra) - техфакти і фікси.
Scribe - таймлайн, журнал дій.
Bot Admin - права/політики/інтеграції бота.
Правило: у одного інциденту один IC і один CL; зміна ролі - явною командою бота.
3) Базові сценарії (end-to-end)
1. Старт інциденту: алерт → '/incident new p1 «Deposits EU down»'→ бот створює картку, вар-рум, призначає IC/CL, ставить таймер першого апдейта.
2. Ведення: `/incident add-facts`, `/incident status set degraded`, `/incident assign @payments-lead`, `/incident timer 20m`.
3. Комунікації: `/incident publish status` (черновик CL), `/incident partners notify`, `/incident regulator draft`.
4. Дії: `/runbook psp-failover PSP1→PSP2`, `/feature toggle replay-center off 60m`, `/traffic shift 30% eu→uk`.
5. Закриття і пост-мортем: '/incident resolve', авто-збір таймлайну, '/postmortem generate'.
4) Команди бота (ядро)
Створення/класифікація
`/incident new p{1|2|3|4} "
`/incident severity set p2`, `/incident tag add payments,psp`
Володіння та ролі
`/incident ic @user`, `/incident comms @user`, `/incident assign @user [domain]`
Таймери і SLO апдейтів
'/incident next-update 15m', '/incident remind'( бот пінгує CL), '/incident eta set 18: 30`
Факти і статус
`/incident fact "auth-success PSP1 -25% TR/EU"`, `/incident status {investigating|degraded|monitoring|resolved}`
Комм-пакети
`/incident draft public|partners|regulator`, `/incident publish public`
Інтеграції
'/runbook
Закриття/пост-мортем
`/incident resolve [reason=…]`, `/postmortem generate`, `/postmortem assign @owner`
5) Інтеграції (мінімально необхідні)
Моніторинг/Observability: альберти, SLI/SLO (burn-rate), лінки на дашборди.
Incident Manager (ITSM): двостороння синхронізація статусу/полів.
Статус-сторінка: чернетки і публікація через CL (policy-gate).
Провайдери (PSP/KYC/Ігрові студії): довідники контактів, швидкі листи/канали.
Release/Feature Flags: канаркові стопи/відкати, посилання на релізи.
Runbooks/Auto-remediation: каталог безпечних дій з guardrails.
CMDB/власники: авто-призначення доменних лідів, ескалації.
Сховище таймлайнів: WORM/immutable для аудиту/пост-мортемів.
6) Архітектура бота
Gateway (Chat Adapter): Slack/Teams/Telegram інтерфейси.
Command Parser + Policy Engine: авторизація, валідація, SoD і допуски.
Orchestrator: сценарії інцидентів, таймери, нагадування.
Integrations Layer: клієнти до ITSM, моніторингу, статус-сторінки, релізів, runbooks.
Evidence Store: події, факти, дифи повідомлень, вкладення (WORM).
Metrics & Audit: метрики якості, логи дій, трасування команд.
7) Політики, права і безпека
RBAC/ABAC: хто може створювати/закривати, змінювати severity, публікувати назовні.
SoD: Comms publish вимагає ролі CL; high-risk дії (PSP-роутинг, PII-експорт) - dual control.
JIT-права: тимчасова видача доменним лідам на час інциденту.
Підпис і шифрування: вебхуки/запити до систем - HMAC/мTLS.
Захист від «fat-finger»: підтвердження небезпечних команд, dry-run і TTL на дію.
PII-гігієна: маскування в чернетках/логах; заборона PII у відкритих каналах.
8) Потоки автоматизації (приклад)
Алерт P1 → бот створює вар-рум ('#inc -2025-11-01-001'), пінгує чергових (IC, CL, Payments/Infra).
Прив'язує дашборди/SLI, відкриває тікет в ITSM, готує шаблон першого публічного апдейта.
Ставить таймери: «наступний апдейт через 15 хв», нагадування CL.
Пропонує runbooks: “PSP reroute 30% → PSP2”, “degrade replay-center”, “autoscale settle-workers”.
При публікації - фіксує версію тексту і публікує в статус-сторінку/соцмережі (через CL).
При закритті - збирає таймлайн, метрики, чернетку пост-мортема, розсилку VIP/партнерам.
9) Таймлайни і доказовість
Кожна подія логується: 'Т + мм: опис, автор/бот, команда, результат, посилання'.
Підтримуються редакції повідомлень (diff), прив'язка до релізів/фічфлагів/планових робіт.
Експорт: PDF/CSV для аудиту та регуляторів.
10) Метрики (KPI/KRI ChatOps)
MTTA (чат): від алерта до '/incident new'.
MTTS (setup): до готовності вар-руму і призначення ролей.
Cadence adherence: дотримання інтервалів публічних апдейтів.
Runbook usage rate: частка інцидентів з автоматизованими діями.
Consistency score: розбіжності між каналами = 0 - мета.
Pager fatigue↓: зниження ручних пейджерів при тому ж/кращому SLO.
Postmortem SLA: частка пост-мортемів, зібраних ≤ D + 5.
11) Каталог шаблонів (фрагменти)
Створення P1:
/incident new p1 "Deposits EU down" components=payments,deposits regions=EU
Перший публічний апдейт (через CL):
/incident draft public
/incident publish public
Роутинг PSP і деградація фіч:
/runbook psp-failover PSP1→PSP2 30%
/feature toggle replay-center off 45m
Пост-мортем:
/postmortem generate
/postmortem assign @owner
12) Вбудовування в процеси
Комунікації: зв'язка з «Комунікація при інцидентах» і «Сторінки статусу системи».
Спостережуваність: швидкі посилання на SLO/SLI і синтетику; автоприклад графіків.
Алертінг: автосоздание інциденту при P1/P2; дедуп сигналів в один потік.
Авто-виправлення: однокнопкові runbooks з guardrails і відкатами.
Workflow Engine: human-tasks (4-eyes), таймери ескалацій, чек-листи.
13) Дорожня карта впровадження (4-8 тижнів)
Нед. 1–2: MVP команд: '/incident new', ролі (IC/CL), вар-рум, таймер апдейтів, зв'язок з ITSM і моніторингом.
Нед. 3–4: шаблони повідомлень (публічні/партнери/регулятори), статус-сторінка (chernovik→publikatsiya), каталог 5-7 runbooks.
Нед. 5–6: policy-as-code (RBAC/SoD/JIT), dual control на high-risk, журнал WORM, дашборд KPI ChatOps.
Нед. 7–8: tabletop-навчання P1/P2, інтеграція з релізами/фічфлагами, авто-збір пост-мортема, локалізація.
14) Антипатерни
«Все через бота» без guardrails → випадкові небезпечні дії.
Публікації в статус-сторінку без ролі CL/Legal-review.
Команди без логів/версій → недоведеність.
Складні форми (20 + полів) в чаті - швидкість падає; краще короткі команди + посилання.
Немає таймерів апдейтів → «тиша» при P1.
Відсутність інтеграції з CMDB/власниками → хаос в призначеннях.
15) Підсумок
Інцидент-бот і ChatOps - це не «бот з командами», а операційна платформа: швидкий старт інциденту, дисципліна апдейтів, автоматизовані дії з безпечними обмеженнями, наскрізна спостережуваність і доказовість. Такий контур передбачувано знижує MTTR, підвищує якість комунікацій і захищає виручку iGaming-бізнесу в пікові моменти.