Не 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 на бумаге сам по себе ничего не гарантирует. Гарантирует конкретная структура за ним: кто отвечает за что, за сколько минут, с каким запасным контактом, и что делать дальше, когда проблема уже случилась. Дешевле один раз построить эту структуру, чем каждый раз во время аварии придумывать её на ходу — и каждый раз платить за это потерянными заказами.
