Мониторинг и резервное копирование

О том, что сайт лежал четыре часа, вы узнали от клиента. Или от рекламщика, который спросил, почему заявки в понедельник упали до нуля. Хуже варианта нет: деньги потеряны, репутация просела, а по логам уже не восстановить, что именно случилось.

Второй повод — «иногда тормозит». Пользователи жалуются, разработчики не могут повторить, все смотрят друг на друга. Без метрик такой спор длится месяцами, потому что доказать нечего ни одной стороне.

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

И четвёртый — диск, забитый под завязку в три часа ночи, сертификат, истёкший в воскресенье, память, которую медленно съедала утечка две недели. Всё это видно заранее, если кто-то смотрит.

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

Логи со всех сервисов в одном месте с поиском. Когда что-то сломалось, разница между «искать по семи серверам» и «ввести запрос в одно поле» — это разница между часом и минутой.

Проверки снаружи: открывается ли сайт из интернета, за сколько, валиден ли сертификат и сколько ему осталось, отвечает ли API. Внутренний мониторинг не заметит, что сервер жив, а к нему не пройти из-за проблемы у провайдера.

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

И оповещения в Telegram: сообщение приходит при реальной проблеме и при её устранении, чтобы было видно, что всё вернулось в норму.

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

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

И в тексте сразу пишется, что произошло, чего это касается и что обычно с этим делают. Оповещение вида «CRITICAL: check_disk failed» в три ночи бесполезно; «На сервере с базой осталось 5% места, растут логи, обычно чистится командой X» — полезно.

Разделяю по срочности: критичное будит, важное приходит в рабочее время, остальное копится в еженедельном отчёте.

Правило трёх копий, которому уже много лет и которое до сих пор работает: три экземпляра данных, на двух разных носителях, один — за пределами площадки. Копия на том же сервере не спасёт от гибели сервера, копия в том же дата-центре не спасёт от проблем дата-центра.

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

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

От 35 000 ₽ за настройку под ключ, два-пять дней работы. В результате: собранные метрики и логи, дашборды под ваш бизнес, оповещения в Telegram, внешние проверки, настроенные копии с проверкой восстановления и короткая инструкция, что делать при типовых авариях.

Строю на открытых инструментах — Prometheus, Grafana, Loki. Лицензий платить не нужно, всё живёт на вашем сервере, данные никуда не уходят, и при желании вы полностью управляете этим сами.

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

Ресурсов такой набор требует немного: на среднем сервере он занимает меньше гигабайта памяти и обычно помещается рядом с основным проектом без отдельной машины.