Сайт падает ночью — это не гипотеза, а расписание. За два года на этом парке кончались диски, ядро убивало базы данных, у хостера отказывала система хранения, истекали домены, а однажды завис сам сервер мониторинга. Вопрос никогда не стоял «упадёт ли». Вопрос стоял иначе: кто узнает первым — дежурный инженер или клиент, у которого не открылась корзина.
Этот кейс о том, как поток аварий превращается в управляемую рутину. Бот пишет в чат, инженер оказывается в системе через 1–9 минут, типовой инцидент закрывается за 7–50 минут, и каждый эпизод оседает строкой трудозатрат в трекере. Формальных гарантий по времени реакции в договоре нет, но цифры есть.
Сводка
| Отрасль конечного клиента | digital-агентство; клиентские интернет-магазины, в основном на Битрикс |
| Конечный клиент | «Медиастудия» (код-имя), Россия |
| Формат сотрудничества | абонентская поддержка: чат — оперативка, Redmine — фиксация и часы |
| Тип проекта | мониторинг и реакция на инциденты как постоянный процесс |
| Объём работ | ~14 серверов в Zabbix; ~70 инцидентов за 24 месяца, ~30 — с точным хронометражем |
| Дата проекта | 4 июня 2024 – 1 июня 2026 (727 дней); процесс продолжается |
| Трудозатраты | по месячным задачам «реакции на мониторинг», типовой эпизод 0.25–2 ч; разнородный поток в одну цифру не сводим |
| Команда | 3 специалиста (инженер-сисадмин · второй инженер точечно · руководитель проекта) |
| Технологический стек | Zabbix 6.4 · Telegram-бот · ISPmanager · nginx · Apache httpd · MySQL/MariaDB · CentOS 7 / AlmaLinux / Ubuntu |
| Сдано | бот замечает первым в большинстве инцидентов; реакция 1–9 минут; типовое восстановление 7–50 минут; сам мониторинг перенесён на новый сервер за 2 часа — ровно по оценке |
Постановка задачи
До договора парк выглядел так: 12 VDS, прошлый администратор ушёл, «раз-два в неделю что-нибудь стабильно падает». Zabbix у студии уже стоял и исправно слал по 1–12 алертов в день — в пустоту. Смотреть их было некому, реагировать — тем более. Мониторинг существовал, а реакции не существовало.
Запрос клиента простой и жёсткий: узнавать о падениях раньше своих заказчиков и по каждому алерту видеть, кто и что с ним сделал и сколько это заняло. Не «поставьте нам красивые графики», а «сделайте так, чтобы аварии переставали быть сюрпризом».
Что здесь сложного с точки зрения покупателя кейса: мониторинг — это инструмент, который умирает от собственного шума. Сотый проигнорированный алерт ничем не отличается от выключенного Zabbix, и почти у каждой студии он именно так и стоит — установлен, настроен, проигнорирован. О падениях по-прежнему сообщают клиенты. Задача была не «внедрить мониторинг», а построить вокруг него дисциплину реакции. И удержать её 24 месяца подряд: на чужом парке, без штатного дежурного, без бюджета на круглосуточную смену.
Как мы это сделали
1. Критические алерты — в общий рабочий чат, а не в отдельную консоль. В июне 2024 бот Zabbix подключён прямо в чат с клиентом, состав алертов согласовали сразу: «ок, давайте пока критические». Падение и реакцию на него обе стороны видят одновременно, в одной ленте. Спрятать инцидент невозможно, да и незачем: скорость реакции стала публичной метрикой, которую клиент проверяет каждый день, просто читая чат.
2. Месячная задача «реакции на мониторинг» — весь поток аварий на учёте. С июля 2024 по июнь 2026 в трекере каждый месяц живёт одна задача-контейнер. Каждый рестарт, чистка диска, разбор ночного алерта записывается туда отдельной трудозатратой с комментарием: типовой эпизод стоит 0.25–0.5 ч. Первая такая задача закрылась с 0.75 ч на два эпизода. Аварии перестали быть «бесплатной паникой» и стали учётной единицей: клиент платит абонентку и видит, из чего она состоит, до строки.
3. Алерт-гигиена: алерт обязан означать действие. Когда диск, хронически забитый на 95%, сыпал десятками сообщений «меньше 5% места», порог снизили до 3%: уведомление приходит, когда пора действовать, а не когда «как обычно». Когда поток сообщений начал мешать самой работе, бюро попросило клиента почистить состав: «сейчас заббикс больше мешает нам тут чем помогает» — «Оставил только критические, остальные отключил». Шумный мониторинг умирает первым. Этот живёт третий год.
4. Мониторим сам мониторинг. 8 октября 2024 все серверы парка разом «потеряли» агентов: Zabbix-сервер самовольно обновился до 6.4.19. Агенты вернулись за 13 минут, автообновление отключено той же ночью: мониторинг не имеет права обновлять сам себя в случайный момент. В декабре 2025 история серьёзнее: старый ARM-сервер мониторинга начал зависать на 4–8 часов, то есть оставлять весь парк без глаз, а хостер переносить виртуалку отказался. Оценка бюро: «часа два». Вечером 29 декабря база и настройки переехали на новый сервер — ровно 2 часа по трекеру, с переносом IP, чтобы агенты не заметили переезда. Утром от клиента: «По первым проверкам — вроде все работает, спасибо!»
5. Дыры признаём письменно — и закрываем. 30 декабря 2024 сайт, которого не было на мониторинге, пролежал 4.5 часа, пока менеджер клиента не написал вручную; инженер поднял его за 10 минут с момента обращения, после чего сайт встал на мониторинг, а на сервер добавили недостающий syslog. 18 августа 2025 агент сервера бэкапов молчал 20.5 часов: алерт был, его пропустили. В чате — честное «чё-то я пропустил алерт», починка за 7 минут: на сервере сам собой запустился firewalld с единственным разрешённым портом ssh, файрвол снесли. Пропуск, признанный и закрытый за 7 минут, работает на доверие сильнее, чем красивая статистика без единого признания.
Инциденты и реакция
Три показательных эпизода из ~30 задокументированных:
| Дата | Что упало | Кто заметил | Восстановление |
|---|---|---|---|
| 20.02.2025 | общий сервер завис, не пингуется | бот — за 20 мин до клиента | ~22 мин (сбой на стороне хостера) |
| 26.11.2024 | хранилище 3 ТБ: диск забит под 100% | бот, сразу | 3–4 мин |
| 27.01.2025 | упала БД интернет-магазина | менеджер клиента, взято за 1 мин | ~28 мин |
Закономерность одна. Бот ловит первым почти всё; люди клиента приносят ночные эпизоды и то, что в мониторинг ещё не попало. Дальше работает один и тот же контур: инженер в системе за минуты, диагноз вслух в чате, починка — трудозатратой в месячную задачу. А каждое «почему упало» превращается в настройку, чтобы не упало снова: лимиты процессов, ватчдоги, пороги, явные таймауты вместо дефолтов.
Честности ради — потолок у формата есть. Без круглосуточной смены ночной алерт иногда ждёт утра: самые длинные простои периода (4.5–8 часов) пришлись на ночные серии и на сайты, которых в мониторинге ещё не было. Инфраструктура самой студии дольше ~3 часов не лежала ни разу.
Результаты
| Метрика | Значение |
|---|---|
| Инцидентов за 24 месяца | ~70, из них ~30 с точным хронометражем |
| Кто замечает первым | бот — в большинстве случаев |
| Реакция инженера | 1–9 минут от алерта или обращения |
| Восстановление типового инцидента | 7–50 минут |
| Перенос самого Zabbix на новый сервер | 2 часа — ровно по предварительной оценке |
| Ложный массовый алерт (автообновление Zabbix) | разобран за 13 минут, причина устранена той же ночью |
| Пропущенный алерт (единственный признанный) | закрыт за 7 минут после эскалации |
| Фон до старта | «раз-два в неделю что-нибудь стабильно падает» |
Простыми словами: студия с парком из ~14 серверов два года живёт без сюрпризов от собственной инфраструктуры. Падения случаются: на дешёвых VPS с Битрикс-магазинами они неизбежны. Изменилось то, что о них первым сообщает бот, а не разгневанный заказчик, и то, что у каждого падения есть время реакции, причина и вывод, записанные в трекер.
Команда
- Инженер-сисадмин (бюро) — первая линия: реакция на алерты, диагностика, ватчдоги, перенос Zabbix
- Инженер (бюро, точечно) — подключение на консилиумы и параллельные инциденты
- Антон Херсун, Xaver Pro — руководитель проекта: процесс, эскалации, разбор спорных эпизодов
Если ваш Zabbix шлёт алерты в пустоту, а о падениях первыми сообщают заказчики — пришлите бриф или текущую техническую документацию. Мы посмотрим, выделим узкие места, вернёмся с фиксированной оценкой в часах. Первичная оценка бесплатна.