Torrent Gear

Практики 24/7-експлуатації та on-call в казино

1) Цілі 24/7-операцій

Бізнес-SLO: логін ≥ 99. 9%, депозит ≥ 99. 85%, ставка/сеттлмент ≥ 99. 9%, p95 WS RTT ≤ 120 мс.

Інцидентні цілі: MTTD ≤ 1 хв (по синтетиці), MTTR ≤ 15-30 хв для грошових флоу.

Якість підтримки: <3% тікетів йде на другий день без відповіді, CSAT саппорта ≥ 90%.

2) Організація on-call: моделі та розклади

Моделі

Follow-the-sun: 3 гео-команди (Європа/Америка/APAC), мінімальне нічне навантаження.

Нічна ротація в регіоні: тиждень нічних змін на людину раз на N тижнів (компенсація/відгули).

Комірки (cell-based): чергування по продуктових осередках (бренди/ринки) + загальний L1.

Ролі в зміні

L1 On-call (Incident Commander за замовчуванням) - приймає алерт, координує, тримає зв'язок з саппортом.

L2 Доменні інженери - платежі, game-gateway/WS, БД/гаманець, платформний SRE.

Коммс-офіцер - статус-сторінка, партнери/провайдери, внутрішні апдейти.

Duty Manager - бізнес-ескалації, пріоритизація, винятки (VIP/регулятор).

Шаблон зміни (12 × 7 або 8 × 5 + чергування)

Зміна: 8/10/12 годин. Перезміна 15-30 хв «warm handover».

Дотримуйтесь правила 2 ночей поспіль максимум і не більше 7 on-call-днів в 14-денному вікні.

Кожна зміна має Roster: черговий, резерв, менеджер з виклику, контактні L2.

3) Класифікація інцидентів і SLA

SEV	Приклад	Вплив	SLA реакції	SLA рішення
SEV-1	Масовий провал депозитів, недоступний логін	Втрата виручки/регуляторний ризик	≤ 5 хв	≤ 30 хв до стабілізації
SEV-2	Висока затримка ставок, лаг провайдера ігор	Зниження конверсії	≤ 10 хв	≤ 2 год
SEV-3	Частковий збій промо/звітів	Обмежений вплив	≤ 30 хв	≤ 8 год
SEV-4	Мінорні баги/алерти якості	Немає негайного впливу	Планово	Планово

4) Алертинг без шуму

Принципи: симптомні SLO-алерти → причинні ресурсні → контекст.

Симптоми: `login_success_ratio↓`, `deposit_success_by_psp↓`, `ws_rtt_p95↑`, `game_launch_success↓`.

Причини: `db_conn_saturation↑`, `queue_lag↑`, `psp_timeout↑`, `provider_launch_latency↑`.

Захист від шуму: required consecutive violations ≥ 3, авто-супрес при релізі, дедуплікація і угруповання.

Черговий набір: критичне - PagerDuty/Opsgenie; решта - Slack/пошта.

Текст алерта: «Що/Де/Скільки/Дія». Приклад:

💡 SEV-2: deposit success DE/PSP-A 97. 1% < 99% 10m. Impact: EU. Probable cause: PSP timeout↑. Runbook: `PD-42`.

5) Runbook'і і ескалації

Міні-шаблон runbook

1. Детект: посилання на дашборди (SLO, причинні), трейс, логи.

2. Швидкі перевірки: health PSP/провайдерів, DR-регіон синтетика, статус БД/кешу.

3. Тимчасові заходи: фіча-прапори/kill-switch, rate-limits, перемикання PSP/провайдера, деградація важких фіч.

4. Ескалації: хто L2/L3, контакти 24 × 7 провайдера.

5. Критерії зеленої зони: SLO в нормі N хвилин, черги

6. Коммс: шаблон статусу, affected markets/brands, ETA/next update.

Ескалаційні сходи

T0-5 хв: L1 приймає, призначає IC, запускає runbook.

T5-10 хв: кличемо профільний L2 + Коммс-офіцера.

T10-15 хв: Duty Manager/продукт, при необхідності юридичний/комплаєнс.

Зовнішні: PSP/Game provider - за регламентом (SLA-канал, тікет, дзвінок).

6) Комунікації та статус-сторінка

Внутрішні апдейти кожні 10-15 хв для SEV-1/2 (канал #war -room, шаблон повідомлень).

Статус-сторінка: поточний статус, порушені ринки, тимчасові заходи, наступний апдейт через X хв.

Post-incident note для саппорту/афіліатів/партнерів: що було, як компенсуємо.

Шаблони заздалегідь: коротко, без «внутрішньої кухні», без вини.

7) Робота із зовнішніми залежностями (PSP/ігри/CDN)

Каталог контактів 24 × 7: PSP A/B, провайдери ігор, CDN/WAF, хмара.

SLA-моніторинг: синтетика на депозити/запуск ігор, автоматичні тригери тікетів.

Failover-політики: маршрут на PSP-B при'success <99% 10 хв', перемикання провайдера ігор при'TTFS> 800мс'.

Inbox-вебхуків: підпис HMAC, ідемпотентність, re-play з черги після деградації провайдера.

8) GameDay і тренування

Щотижневі tabletop-навчання (30-45 хв): читання графіків, прийняття рішень.

Щомісячні технічні DR-драйли (60-90 хв): відмова PSP, лаг провайдера, падіння БД/кластера WS.

KPI навчань: час розпізнавання причини, якість комунікацій, коректність рішень по фічефлагах.

9) Хендовер і документація

Warm handover чек-лист (15-20 хв):

Поточні ризики (зростання лагів, ліміти PSP, гарячі релізи).
Незаповнені тікети/ескалації.
Тимчасові фічефлаги/ліміти і коли зняти.
Резюме інцидентів зміни (SEV/час/дії/залишкові ризики).
Документація: жива база runbook'ів, контактів, схем, «карта флоу» гроші/ігри.

10) On-call здоров'я і стійкість

Правило 8/8/8: робота/сон/особисте. Нічні зміни → відгули.

Бадді-система для новачків, shadow-чергування 2-3 тижні.

Психологічна безпека: «blameless» ретро, підтримка при важких інцидентах.

Аудит навантаження: ≤ 2 «пробудження» за ніч в середньому на інженера - мета; вище → переробка алертингу/архітектури.

11) Метрики операційної ефективності

MTTD/MTTR по доменах (логін/депозит/WS/ігри).

Alert quality: % галасливих/закритих без дій, середнє число алертів/зміну.

Change failure rate: % інцидентів, викликаних релізами; mean time between failures.

Toil: частка повторюваних ручних завдань → план автоматизації.

Provider impact: частка SEV-2/1 через зовнішніх партнерів (аргумент для SLA/міграції).

12) Інструменти та панелі «чергового»

«Червоний» дашборд SLO: логін/депозит/ставки/запуск ігор, 5xx/429, p95, регіони.

Причинні панелі: БД/черги/кеш, PSP/провайдери, CDN/WAF.

On-call диспетчер: активні інциденти, таймери апдейтів, one-click посилання на runbook'і і фічефлаги.

Журнал дій (timeline) - хто що зробив, коли, з прив'язкою до SLO.

13) Типові сценарії та швидкі рішення

A. депозити падають в DE у PSP-A

Дії: канарний marshrut→ PSP-B 50%; підняти таймаут вебхуків; включити JS-челендж в WAF від ботів.

Коммс: статус-сторінка «Degradation DE deposits via PSP-A».

Вихід: success ≥ 99% 15 хв, черга ретраїв

B. зростання p95 WS в лайв-іграх APAC

Дії: збільшуємо репліки WS-шлюзів, включаємо warm-пул нод; rate-limit широкомовних повідомлень; провайдеру - тікет по RTT.

Вихід: p95 WS RTT ≤ 120 мс 20 хв.

C. лаг провайдера ігор (TTFS> 1. 2 с)

Дії: перемкнути лобі на альтернативні столи/студії, включити кеш метаданих; статус-апдейт.

Вихід: TTFS <800 мс, скарги ↓.

14) Чек-лист готовності до 24/7

Ротації та чергування затверджені, «другий номер» на кожній зміні.
SLO-алерти + причинні, антишум, єдині шаблони повідомлень.
Повні runbook'і з «швидкими важелями» (фічефлаги, PSP/провайдери, ліміти).
Контакти 24 × 7 зовнішніх партнерів, тест дзвінка раз на квартал.
Статус-сторінка і шаблони зовнішніх апдейтів.
GameDay/DR-навчання за розкладом, ретроспективи без звинувачень.
Інструменти on-call: дашборди, таймлайн, журнал рішень.
Політика компенсації/відгулів, ліміт нічних пробуджень, підтримка здоров'я.
Пост-інцидентний процес: RCA в 48 год, завдання по виправленнях з власниками і термінами.

15) Шаблон пост-мортема (blameless)

1. Коротко: що сталося, коли, який SEV, вплив і масштаби.

2. Таймлайн: детект → ескалації → дії → стабілізація.

3. Кореневі причини: тих/процеси/люди/постачальники (5 Why).

4. Що спрацювало/що ні: альберти, ранбуки, комунікації.

5. Action items: технічні, процесні, партнерські - відповідальні і дедлайни.

6. Профілактика: тести/моніторинг/навчання, зміни SLO/алертів.

Резюме

Успішні 24/7-операції в казино - це дисципліна SLO, правильно спроектований алармінг без шуму, чіткі runbook'і і ескалації, регулярні навчання і дбайливе ставлення до on-call-людям. Зв'яжіть SLO-панелі з швидкими важелями (фічефлаги, перемикання PSP/провайдерів, деградація важких фіч), підтримуйте комунікації з гравцями і партнерами, міряйте ефективність (MTTD/MTTR/alert quality) - і ваша платформа буде стабільною цілодобово, а команда - продуктивною і стійкою.