Сколько стоит ночной простой, которого никто не заметил до утра

MAATRIX

Утром вы открываете дашборд и видите ровный график — сервис жив, все процессы подняты, ошибок в логах нет. Только время последнего успешного запроса почему-то с четырёх утра до половины восьмого пустое. Никто не звонил, никто не писал в саппорт, апдейт-статус не менялся — и первая реакция обычно: «ну и хорошо, значит, простой был несущественный, раз никто не заметил». Это ловушка. Ночной простой, который прошёл тихо, стоит разбирать внимательнее, а не меньше — потому что тишина здесь не индикатор безобидности, а индикатор того, что вы не знаете реальных масштабов случившегося.

Почему тихий простой — это не повод расслабляться

Логика «мало пользователей ночью — мало потерь» работает только для одной части уравнения: прямых потерь трафика в конкретный момент. Действительно, если у вас B2B SaaS с основной аудиторией в одном часовом поясе, ночью запросов на порядок меньше, чем днём, и формальный подсчёт «недополученных сессий» даст скромное число.

Проблема в том, что вы считаете последствия, отталкиваясь от предположения, будто знаете все параметры инцидента: когда он начался, когда закончился, кого затронул. А тихий простой по определению — ситуация, где хотя бы один из этих параметров вам неизвестен, потому что система, которая должна была его зафиксировать, этого не сделала вовремя. Вы оцениваете не инцидент, а собственную слепую зону.

Есть и вторая часть: сам факт, что падение никто не заметил до утра, — это не про везение с малым трафиком, это диагноз вашей системе мониторинга и алертинга. Если бы алерты работали как должны, кто-то узнал бы о проблеме в течение минут независимо от того, три пользователя было ночью или три тысячи. То, что этого не произошло, означает дыру в системе, которая точно так же сработает — точнее, не сработает — и в дневное время, просто с другими ставками.

Сколько часов на самом деле вы потеряли, если никто не заметил

Первый честный вопрос, который надо задать себе перед любым расчётом ущерба: вы вообще знаете, сколько длился простой? Если единственное, что у вас есть, — это разрыв в графике мониторинга, вы знаете не время простоя, а время, прошедшее между последней успешной проверкой и первой успешной проверкой после инцидента. Это верхняя граница, но не факт.

Разница может быть существенной. Пример: проверка health-check каждые 5 минут, инцидент начался в 03:12, следующая проверка после восстановления прошла успешно в 03:47. Формально «простой» — это интервал между последней зелёной и первой зелёной точкой, то есть что-то около получаса-сорока минут. Но что если сама проверка мониторинга тоже была недоступна или отвечала ложноположительно из-за кеша, балансировщика, CDN? Тогда реальное окно могло быть шире, чем показывает график.

Второй момент — время реакции, если бы алерт всё-таки сработал. Разница между «алерт пришёл дежурному в 03:15, он отреагировал в 03:20» и «никто не узнал до 08:00, когда кто-то открыл дашборд по привычке» — это разница в часах простоя, а не в минутах. И потери здесь растут не линейно: чем дольше сервис недоступен, тем больше вторичных эффектов — отвалившиеся вебхуки, зависшие очереди задач, ошибки в интеграциях у клиентов, которые сами могут заметить их не сразу.

Практический вывод: прежде чем считать деньги, зафиксируйте честный диапазон времени простоя — «от» и «до», а не одну цифру, — и отдельно посчитайте, сколько из этого диапазона составило время до обнаружения. Это две разные метрики: MTTD (mean time to detect) и MTTR (mean time to recover). Если MTTD у вас исчисляется часами, это первое, что нужно чинить, — раньше, чем оптимизировать сам процесс восстановления.

Утро по Москве — это не утро по всему миру

Если ваша аудитория ограничена одним часовым поясом, ночной простой действительно может быть периодом минимальной активности. Но так бывает не всегда, и это стоит проверить, а не предполагать. Даже у формально «локального» сервиса могут быть:

• клиенты, которые работают допоздна или начинают день раньше среднего — суточное распределение трафика редко бывает идеальным колоколом с нулём в 3–4 утра;
• фоновые задачи и интеграции — cron-джобы, синхронизации, вебхуки от платёжных систем, бэкапы, — которые как раз специально запланированы на ночь, потому что «трафика меньше»; тихий простой ломает именно их;
• пользователей из других регионов — партнёров, удалённых сотрудников, клиентов с зарубежными офисами, для которых ваша глубокая ночь — это их рабочий день.

Отдельная ситуация — сервисы, которые изначально рассчитаны на несколько часовых поясов: RU/US/UK-аудитория, международные клиенты, распределённая команда. Для них понятие «ночь, когда никого нет» вообще не работает буквально: пока в Москве 4 утра, в Лондоне 1 ночи, а в Нью-Йорке 20:00 — там ещё вполне рабочий вечер. Инцидент, который выглядит «тихим» по московским часам, может ударить по реальному пиковому окну для части аудитории.

Практическая проверка простая: посмотрите в аналитике распределение трафика по часам за последние недели, с разбивкой по гео, если она есть. Если хотя бы 10–15% активности приходится на ваше «ночное» окно, расчёт «никто не заметил, значит все спали» перестаёт быть корректным.

Тишина мониторинга — это диагноз, а не совпадение

Здесь стоит остановиться отдельно, потому что это самая важная часть разбора. Есть принципиальная разница между двумя ситуациями:

1. Мониторинг зафиксировал падение, отправил алерт, но дежурный не отреагировал вовремя (человеческий фактор, проблема эскалации).
2. Мониторинг вообще не зафиксировал падение, или зафиксировал, но не смог никого оповестить (техническая проблема в самой системе наблюдения).

Второй случай гораздо тревожнее, и «инцидент прошёл незамеченным до утра» чаще всего означает именно его. Частые причины, которые встречаются на практике:

• Мониторинг стоял на том же сервере, что и сервис. Если у вас health-check или Uptime Kuma развёрнуты на той же машине, что и продакшен, при полном падении хоста мониторинг падает вместе с ним — и вместо алерта «сервис недоступен» вы получаете тишину, потому что сама система, которая должна была её нарушить, тоже лежит.
• Канал уведомлений тихо сломался. Бот в Telegram потерял токен после ротации, email попал в спам, вебхук в Slack стал возвращать 403 после смены прав — и с точки зрения мониторинга всё работает: событие сгенерировано, отправлено, а то, что оно никуда не дошло, никто не проверяет отдельным алертом.
• Порог алерта был настроен неправильно. Например, алерт настроен на «сервис недоступен 3 проверки подряд», проверка раз в 10 минут — итого до 30 минут задержки только на подтверждение, прежде чем что-то вообще произойдёт. Ночью, когда никто не смотрит дашборд вручную, это уже существенное окно.
• Алерт ушёл, но в канал, который никто не открывает ночью. Уведомление в общий рабочий чат — это не то же самое, что уведомление дежурному лично, с эскалацией через 10–15 минут молчания.

Если разбор инцидента приводит вас к одной из этих причин — это хорошая новость в плохой упаковке: значит, проблема не в везении и не в «просто так сложилось», а в конкретном узле системы, который можно исправить. Полезно формализовать такой разбор как обычный постмортем, даже если у инцидента не было видимых жертв среди пользователей — структура «что произошло, когда узнали, почему не раньше, что чиним» работает одинаково и для громких, и для тихих падений.

Что будет, если такой же простой случится днём

Вот ключевой практический вопрос, который стоит задать себе после разбора тихого ночного инцидента: если бы система мониторинга так же промолчала в 14:00 в будний день, вы бы узнали о падении раньше, чем клиенты сами начали писать в поддержку?

Если честный ответ — «нет, узнали бы так же поздно, просто жалоб было бы намного больше» — значит, вам повезло с таймингом, а не то, что у вас надёжная система. Ночной инцидент в этом смысле — бесплатный тест на прочность мониторинга, прошедший незамеченным именно потому, что ставки были низкие. В следующий раз ставки могут быть другими, а дыра в системе — той же самой.

Стоит превратить абстрактное «а что если» в конкретный список: какие узлы мониторинга физически совпадают с продакшен-инфраструктурой (общий сервер, сеть, DNS-провайдер), какие каналы оповещения не имеют резервного дублирования, есть ли эскалация для случая «дежурный не ответил за N минут» или там просто одно уведомление без резерва.

Отдельно полезно прикинуть примерный порядок стоимости, если то же самое произойдёт в рабочее время, — не ради точного бюджета, а чтобы аргументировать приоритет починки мониторинга перед другими задачами в бэклоге. Точные цифры тут не нужны (у вас их и нет — это оценка, а не факт): сколько пользователей обычно онлайн в пиковый час, какая доля операций реалистично «сгорает» безвозвратно при недоступности, а какая просто откладывается. И отдельно стоит заглянуть в договор с ключевыми клиентами — есть ли там SLA со штрафами за простой сверх оговорённого уровня: это уже не оценочная, а договорная величина.

Как построить алертинг, который действительно будит ночью

Вывод из всего разбора практический: важно не просто «иметь мониторинг», а иметь мониторинг, который физически независим от того, что он проверяет, и алертинг, который эскалируется, если первое уведомление осталось без ответа. Ниже — рабочий каркас, без точных цифр по времени реакции, потому что они у каждой команды свои.

1. Разнесите мониторинг и продакшен физически. Правило простое: если сервис лежит на сервере A, наблюдатель за ним не должен лежать на сервере A. Отдельный небольшой сервер под мониторинг — недорогое решение, которое снимает целый класс «тихих» отказов, когда мониторинг умирает вместе с тем, что должен был проверять. Если у вас несколько локаций (RU/US/UK), логично держать узел мониторинга в отдельной локации от основного продакшена, чтобы сетевой инцидент у одного провайдера не гасил оба конца сразу.

2. Используйте внешние проверки, а не только внутренние. Внутренний health-check («процесс жив, порт слушает») не видит проблем на уровне сети, DNS, SSL-сертификата или балансировщика перед сервисом. Внешний синтетический чек — запрос снаружи, с реальным HTTP-ответом и проверкой контента страницы, а не только кода 200 — ловит больше реальных сценариев отказа. Инструменты вроде Uptime Kuma, healthchecks.io или связки Prometheus + Alertmanager для этого хорошо подходят — важно не то, какой конкретно инструмент, а то, что он работает снаружи и независимо.

Минимальный конфиг проверки в Uptime Kuma для HTTP-эндпоинта с разумным интервалом:

Monitor Type: HTTP(s)
URL: https://your-service.example/health
Heartbeat Interval: 30-60 sec
Retries: 2
Heartbeat Retry Interval: 20 sec
Resend Notification if Down (every X consecutive): 1

3. Настройте эскалацию, а не одиночное уведомление. Одно сообщение в Telegram, которое дежурный физически не увидел (телефон на беззвучном, разрядился, спал), — тот же провал, что и полное отсутствие мониторинга. Рабочая схема: первое уведомление сразу, если через 5–10 минут нет подтверждения (например, через бота с кнопкой «принято») — второе уведомление другому человеку или в другой канал, ещё через 10–15 минут — звонок. Даже простая связка «бот в Telegram плюс второй канал с задержкой» уже закрывает сценарий «первый канал тихо сломался».

4. Проверяйте сам канал уведомлений отдельно. Раз в сутки или чаще отправляйте тестовый алерт и следите, что он реально доходит, а не просто «отправлен по логам». Для критичных фоновых задач (бэкапы, синхронизации, cron) полезен подход «жду сигнала, а не жду ошибки» — например, через healthchecks.io, где задача сама должна прислать пинг о завершении, и если пинга нет вовремя — это и есть сигнал тревоги, без необходимости, чтобы сама задача корректно отработала обработку ошибки.

5. Явно разделите уровни серьёзности по времени суток, если это оправдано бизнесом. Не всегда нужна одинаковая скорость реакции в 3 часа ночи и в 3 часа дня — но это должно быть осознанным решением с прописанным дежурством, а не случайностью из-за того, что ночью просто некому смотреть в чат. Если у вас распределённая по часовым поясам аудитория, стоит явно прописать, что «тихих часов» в смысле допустимости задержки реакции у вас либо нет вообще, либо они выбраны обоснованно, а не по умолчанию из-за того, что вы сами живёте в одном поясе.

Отдельно про цену минуты простоя магазина и то, как считать стоимость простоя для B2B-сервиса — эти разборы дают методику расчёта, которую можно применить и к ночному инциденту, просто с поправкой на неизвестную точную длительность. А если хочется до конца разобраться, почему «мониторинг есть, но никто его не видит» — это классический антипаттерн мониторинга, который никто не смотрит, стоит его читать вместе с этим текстом.

Если нужно поднять независимый узел мониторинга отдельно от основного продакшена — небольшой сервер в другой локации для внешних проверок и алертинга обходится недорого и снимает целый класс рисков, разобранных выше.

Частые вопросы