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

Студия сдала сайт, получила деньги и ушла. Через полгода у клиента лёг сервер — и звонят не хостеру, а вам: вы же «делали сайт». Дальше начинается самое дорогое в этой работе: выяснение, что вообще случилось, на сервере, к которому у вас нет доступа, с приложением, которое разворачивал человек, уже уволившийся.

У клиента один сайт, и он смотрит на него каждый день. У студии их тридцать, и ни на один она не смотрит: некогда, да и незачем — работает же.

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

В итоге очередь оповещения выстраивается так: покупатель → клиент → менеджер студии → разработчик. Три звена, каждое со своим временем реакции. Студия в этой очереди последняя, хотя чинить будет именно она.

Простой принято мерить одним числом — «лежали два часа». На практике это три разных отрезка, и стоят они по-разному.

До обнаружения. От момента, когда сломалось, до момента, когда кто-то это заметил. Ночью и в выходные он самый длинный. У нас однажды две трети трафика на сервер шли через чужую машину в том же дата-центре — прозрачный прокси, который отдавал наш сайт байт в байт. Мы увидели это, сложив адреса в логе за десять часов. Не потому, что что-то сломалось, а потому, что сели считать. Сколько недель это длилось до подсчёта — неизвестно.

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

До восстановления. Здесь всё зависит от того, что подготовлено заранее. Копии у нас были полтора года. Восстанавливались из них — ни разу, пока не провели учение: база 621 МБ поднялась за 19 секунд, файлы — за 4, контрольные числа сошлись. До учения любая из этих цифр могла оказаться любой, включая «не восстанавливается».

Три отрезка складываются, и самый дорогой — первый. Не потому, что он самый длинный, а потому, что всё это время клиент думает, что вы знаете.

Формула простая, и в неё стоит подставить свои значения, а не наши.

Допустим — числа условные — час команды стоит 6 000 ₽, инцидент длился три часа, скидка вышла в 15 000 ₽, а вероятность потерять клиента с годовым чеком 600 000 ₽ вы оценили в 10 %. Итого: 18 000 + 15 000 + 60 000 = 93 000 ₽ за одно падение, о котором вы узнали от клиента.

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

У каждого свой предел, и ни один не закрывает всё.

Проверка снаружи. Раз в минуту кто-то заходит на сайт, как покупатель: отвечает ли адрес, открывается ли порт, не истёк ли сертификат. Ловит упавший домен, протухший TLS, зависшее приложение. Не видит, что кончается диск: сайт ещё отвечает.

Метрики изнутри. Небольшой агент на сервере присылает процессор, память, диск и состояние контейнеров. Ловит то, что снаружи не видно: диск на 92 %, контейнер базы в бесконечном перезапуске, память, которую съел один процесс. Не видит упавший домен — с точки зрения сервера всё живо.

Разбор журналов на чужую активность. Попытки входа, сканы портов, адреса, с которых приходит слишком много. Ловит подготовку к тому, что ещё не случилось. Не заменяет ни первого, ни второго.

Что важнее самих проверок — куда приходит сигнал. Уведомление на почту одному человеку в субботу в шесть утра равно отсутствию уведомления. Сигнал должен идти туда, где его увидят: в общий рабочий чат, с названием проекта и клиента в первой строке.

Мониторинг покупает тот, у кого уже болит. Студии, которая отвечает за чужой прод, продаётся не график, а ответ на звонок клиента: «да, мы знаем, уже чиним». Это разные продукты с одной технической начинкой.

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

Честный раздел, без него текст читается как реклама.

Проверка не знает предметной области. Сайт отвечает, база жива, а форма заказа считает доставку неправильно — этого не увидит ни один из трёх способов. Это задача тестов, а не мониторинга.

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

И проверка не заменяет договорённости с клиентом. Если в договоре не написано, кто и в какой срок реагирует, узнать первым — значит взять на себя обязательство, которого раньше не было. Это правильное обязательство, но осознанное.

Если ничего из этого у вас нет, вот минимум, после которого студия перестаёт быть последней в очереди:

После этого вечер закончится, а очередь оповещения развернётся: первым будете вы.

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