Узнаёте о падении от клиентов: почему так нельзя жить

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

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

Особенно коварна частичная деградация: в офисе всё открывается, у части регионов — нет; главная страница жива, форма заявки молчит; сертификат пугает только часть браузеров. Без внешних проверок такие сбои живут дольше полных падений.

Сценарии без алертов

Ночью падает база — утром отдел продаж открывает смену в пустоту. Сертификат истекает в выходные — конверсия обнуляется на два дня. Сеть доставки контента отдаёт ошибки выборочно — в офисе «всё ок». Форма заявки ломается скриптом, проверка «главная открывается» остаётся зелёной. Бизнес теряет лиды, мониторинг молчит.

Ещё один сюжет — «мониторинг есть, но в почте, которую никто не читает ночью». Формально сигнал был. Фактически — нет владельца дежурства и второго человека на подхвате.

Почему «мы иногда смотрим» не работает

Человек не дежурит круглосуточно без системы. Ручная проверка по понедельникам ловит только то, что ещё лежит. Ложные срабатывания без настройки приводят к тому, что команда начинает игнорировать сигналы. В итоге мониторинг формально существует, фактически — нет.

Отдельная ошибка — считать проверку доступности площадки размещения заменой своему контролю приложения. Хостер может быть жив, а ваш кабинет, обмен или оплата — нет.

Что проверять на самом деле

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

Каналы оповещения должны совпадать с тем, где люди реально живут: мессенджер дежурного, короткое сообщение на критичный приоритет, дублирование второму человеку. Один общий ящик «всем» — путь к «все видели, никто не взял».

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

Ошибки внедрения

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

Что меняется для бизнеса

С оповещением до клиента вы сокращаете окно слепоты. Рекламу можно приостановить до звонков в поддержку. Коммуникацию — подготовить заранее. Инженера — разбудить по делу, а не после трёх часов простоя.

Считайте стоимость часа недоступности витрины или CRM и сравните с ценой нормального мониторинга. Обычно аргумент заканчивается за одну таблицу на планёрке.

С чего начать за неделю

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

На что смотреть через месяц

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

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

Отдельно договоритесь, что считается успехом для бизнеса, а что — для инженерии. Для коммерции важны заявки, оплаты, скорость ответа клиенту. Для инженерии — повторяемость, наблюдаемость, откат. Когда метрики разные и не согласованы, проект «закрывают», а боль возвращается.

Практический минимум на ближайшие две недели

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

Документируйте коротко: схема, доступы, владельцы, даты проверок. Документ на две страницы, который читают, полезнее wiki на двести, которую забыли. Обновляйте его после каждого инцидента — именно тогда правда свежая.

И наконец назначьте человека, а не «команду». Коллективная ответственность в инцидентах обычно означает отсутствие ответственности. Заместитель нужен, но имя на дверце должно быть одно.

Итог

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