Мониторинг работы сервиса: как узнавать о сбоях раньше клиента

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

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

Зачем больше одного слоя

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

Поэтому у меня три слоя, и каждый отвечает на свой вопрос.

Три слоя проверки

Слой 1: видно ли сервис снаружи

Каждые пять минут внешняя проверка стучится в сервис так же, как это сделал бы клиент, и ждёт ответа. Если ответа нет или пришла ошибка, мне сразу уходит сообщение в Telegram.

По сути это обычный мониторинг доступности сайта. Он ловит самое грубое: сервис недоступен целиком. Зато он ничего не знает о том, что происходит внутри.

Слой 2: здоровы ли внутренности

На управляющем сервере регулярно запускается скрипт, который проверяет то, что снаружи не видно:

• работают ли нужные сервисы;
• хватает ли места на диске и памяти;
• отвечают ли рабочие узлы, через которые идут клиенты;
• свежая ли последняя резервная копия базы.

Последний пункт выглядит лишним, пока не пригодится. Мне он пригодился в первую же неделю. Резервное копирование запускалось в отдельном служебном контейнере, а плановая чистка сервера удалила образ, из которого этот контейнер собирался. Копирование молча перестало запускаться: никакой ошибки на экране, сервис при этом работал как обычно. Проверка свежести заметила, что последняя копия слишком старая, и подняла тревогу. Копии не делались примерно одиннадцать часов. Без этой проверки я узнал бы об этом только в день, когда копия понадобилась.

Слой 3: кто присмотрит за смотрящим

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

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

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

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

Как не утонуть в тревогах

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

Здоровый прогон молчит. Если проверка прошла, сообщения нет. Сообщение означает, что надо посмотреть.

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

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

Тревога не теряется, даже если не доставлена. Если отправить уведомление не получилось, полный текст пишется в журнал на сервере. Потом можно восстановить, что было.

Что это дало

Главное изменение не в технике, а в порядке событий. Раньше цепочка была «сбой, клиент заметил, клиент написал, я чиню». Теперь «сбой, мне пришёл сигнал, я чиню». Бывает, что клиент в этот момент ещё ничего не заметил.

Скажу честно, где здесь граница. Мониторинг не чинит. Он сокращает время между поломкой и моментом, когда о ней знает тот, кто может починить. Упавший узел по-прежнему поднимаю я. Разница в том, что делаю это по сигналу и спокойно, а не в ответ на жалобу. Процент доступности я не называю: я его не измеряю, а выдумывать не буду.

Как это перенести на ваш бизнес

Серверы есть не у всех, а вот ситуация «узнаём о проблеме последними» знакома почти всем. Посмотрите на свои процессы с тем же вопросом: откуда вы обычно узнаёте о поломке?

• Заявки с сайта перестали приходить, а заметили через три дня, когда кто-то удивился тишине. Во что обходятся такие дни, я считал в посте про утекающие заявки.
• Выгрузка в учётную систему встала, и об этом сообщила бухгалтерия в конце месяца.
• Интеграция с CRM тихо отвалилась после обновления, а менеджеры неделю работали по старым данным.

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

Если у вас есть процесс, о поломке которого вы узнаёте от клиентов или коллег, опишите его. Первый разбор бесплатный: скажу, где поставить проверку, чтобы узнавать первым.