Не Black Friday. Просто вівторок
Найгірша аварія, яку я бачив, сталась не в жоден зі “офіційних” пікових днів. Звичайний вівторок, середина місяця, магазин побутової техніки. О 19:20, коли трафік з реклами якраз почав рости після робочого дня, платіжний шлюз почав віддавати таймаути. Сайт формально працював — сторінки відкривались, кошик рахувався. Просто оплата не проходила. Ніхто цього не помітив ще сорок хвилин, бо моніторинг перевіряв тільки “чи сайт відповідає на /”, а не “чи проходять платежі”.
З Black Friday все зрозуміло: ти знаєш дату наперед, готуєшся, тестуєш під навантаженням. А от звичайний вівторок так не готують. І саме тут з’ясовується, чи є в компанії реальна структура на випадок збою, чи є тільки надія, що “воно само”.
SLA — це не рядок у договорі “99.9% uptime”
Коли власник бізнесу чує “SLA”, він зазвичай уявляє один відсоток у контракті. На практиці той відсоток сам по собі майже нічого не гарантує. 99.9% на місяць — це приблизно 43 хвилини простою, які ти маєш право “витратити”. Питання в іншому: хто і за скільки хвилин про це дізнається, хто буде цим займатись о третій ночі в неділю, і що саме вважається “інцидентом” — повний даун сайту чи ще й ситуація, коли оплата відвалюється, а каталог працює.
Робочий SLA — це документ з кількома шарами: цільовий рівень доступності, час реакції за типом проблеми, канал зв’язку в екстреному випадку, і чітко прописано, що саме входить у підтримку, а що ні. Без останнього пункту весь документ — просто гарна цифра для маркетингу.
Скільки насправді коштує простій
Тут майже завжди рахують неправильно. Власники множать середній денний дохід на кількість годин простою і лякаються великою цифрою — або, навпаки, заспокоюють себе тим, що “ніч, трафіку мало, нестрашно”. Обидва підходи не працюють, бо втрати сильно залежать від конкретного вікна часу.
Приклад ближче до реальності: інтернет-магазин з середнім чеком 1200 грн і 40 замовленнями щогодини у вечірній пік. Годинна аварія з 19:00 до 20:00 — це не “одна година з доби”, а приблизно 48 000 грн замовлень, які або пішли до конкурента, або взагалі не відбулись, плюс частина клієнтів, які просто більше не повернуться після невдалого досвіду. Та сама година о 5 ранку коштує на порядок менше. Якщо в компанії немає таблиці “втрати по годинах доби”, розмова про пріоритети інцидентів ведеться наосліп.
Рівні критичності: не кожна проблема — пожежа
Класична помилка — реагувати на все з однаковою терміновістю. Тоді або команда вигорає від постійних нічних дзвінків через дрібниці, або справді критичний збій губиться серед десятка дрібних тікетів. Робочий поділ зазвичай виглядає так:
- Критичний (P1) — сайт недоступний, оплата не проходить, замовлення не зберігаються. Реакція за хвилини, не за години.
- Високий (P2) — окремий важливий блок не працює: пошук, фільтри, особистий кабінет. Бізнес продовжується, але з тертям.
- Середній (P3) — косметичні або локальні баги, що не блокують покупку.
- Низький (P4) — все інше, йде в звичайний беклог.
Для кожного рівня — своє контрактне вікно реакції. P1 вночі в неділю має піднімати чергового інженера. P4 спокійно чекає до понеділка. Коли ця градація прописана заздалегідь, зникає найгірша частина будь-якого інциденту — суперечка про те, наскільки все серйозно, поки клієнти вже не можуть оформити замовлення.
Моніторинг, який бачить проблему раніше за клієнта
“Сайт пінгується” — це не моніторинг, це заспокійлива іконка. Реальна аварія майже завжди ховається глибше: черга задач раптом перестала розбиратись і росте, база даних почала віддавати повільні запити, платіжний провайдер відповідає з затримкою в 8 секунд замість 200 мілісекунд. Формально все “працює”.
Тому варто дивитись не тільки на аптайм головної сторінки, а на конкретні бізнес-метрики: скільки замовлень оформлено за останні 15 хвилин порівняно з тим самим часом тиждень тому, скільки платежів завершились помилкою, наскільки виросла черга. Різке падіння кількості успішних замовлень — куди раніший і чесніший сигнал, ніж будь-який uptime-чекер.
Хто піднімає слухавку о третій ночі
Ескалація — той момент, де добрі наміри розбиваються об реальність. “Ми напишемо в Telegram, і хтось відповість” — не план, а сподівання. Робоча схема має відповідати на три питання заздалегідь: хто перший на зв’язку, що робити, якщо він не відповів за 10 хвилин, і хто приймає рішення, якщо проблема виходить за межі одного спеціаліста — наприклад, потрібно одночасно чіпати і хостинг, і платіжний шлюз, і код.
Без другого контакту в ланцюжку одна відпустка чи вимкнений телефон перетворює критичний інцидент на “чекаємо до ранку”.
Що підтримка не покриває — і чому про це треба говорити наперед
Тут більшість конфліктів з клієнтами і виникає. Підтримка сайту зазвичай не відповідає за збій самого хостинг-провайдера, за падіння стороннього платіжного шлюзу, за проблеми в API служби доставки, за DDoS вище певного порогу — це окремі домовленості з окремими постачальниками. Якщо це не прописано явно, клієнт дізнається про межі відповідальності саме в момент аварії, коли емоції і так на максимумі.
Чесніше — одразу дати список: що входить у підтримку, що ні, і хто відповідальний за суміжні системи. Звучить як дрібниця на етапі підписання договору. Під час реального збою ця дрібниця вирішує, наскільки швидко проблему взагалі почнуть вирішувати, а не з’ясовувати чия вона.
Runbook: інструкція на випадок, коли все горить
Коли сервер падає о другій ночі, ніхто не хоче в цей момент згадувати архітектуру системи з нуля. Runbook — покроковий документ на конкретні типові сценарії: не працює оплата, база даних недоступна, черга задач забита, сайт віддає 500-ту на всіх сторінках. Для кожного сценарію — де дивитись логи, які команди запустити першими, кого підключати, якщо перший крок не допоміг.
Без цього документа кожна аварія перетворюється на розслідування з нуля навіть тими, хто вже бачив таку саму проблему місяць тому.
Після того, як все запрацювало
Найслабше місце більшості команд — саме тут. Сайт знову працює, всі видихнули, і на цьому все закінчується. А варто зупинитись і розібрати: що саме сталось, чому моніторинг не спрацював раніше, чи можна було відреагувати швидше, що змінити в коді чи процесі, щоб та сама причина не повторилась через два місяці.
Post-mortem без пошуку винних — не формальність для галочки. Команда, яка боїться описувати власні помилки, повторює їх. Команда, яка розбирає інцидент спокійно, за рік проходить через набагато менше аварій того самого типу.
Якщо коротко
SLA на папері нічого не гарантує сам по собі. Гарантує конкретна структура за ним: хто відповідає за що, за скільки хвилин, з яким запасним контактом, і що робити далі, коли проблема вже трапилась. Дешевше один раз побудувати цю структуру, ніж щоразу під час аварії вигадувати її на ходу — і щоразу платити за це втраченими замовленнями.
