Что такое мониторинг инфраструктуры и реагирование на инциденты
Мониторинг серверов — постоянный съём показателей с машин и сервисов, пороги, при которых показатель считается тревожным, и оповещение живого человека. Реагирование на инциденты, в отраслевых текстах — incident response, — вторая половина: кто получает сигнал, что делает в первые минуты, кого поднимает дальше и что происходит с находкой потом. Первая половина без второй — красивые графики, на которые ночью никто не смотрит.
Что входит. Настройка сбора метрик, сведение журналов, пороги под проект, маршруты оповещений и расписание дежурства, инструкции для типовых аварий, разбор после каждого серьёзного случая.
Кому нужно. Проектам, где о проблеме узнают от пользователей. Системам учёта, чей ночной обмен может тихо остановиться. Командам, у которых наблюдение есть, но письма из него уходят в папку «потом».
Сколько стоит. Ответа рынка нет: посадочные по наблюдению за инфраструктурой нашлись у двух компаний, и стоимость не указала ни одна. Наша вилка зависит от числа машин, глубины съёма и того, нужна ли дежурная смена: от 45 000 ₽/мес SLA базовый · от 65 000 ₽/мес мониторинг + on-call · от 95 000 ₽/мес DevOps 24/7; итог от числа машин и режима
Какие метрики снимаем и при каких порогах поднимаем тревогу
Мониторинг и алертинг — разные половины одной работы: снимать показатели умеет любая система, а решить, при каком значении будить человека, за вас не решит никто. Сигнал, который пришёл поздно, бесполезен; сигнал по любому поводу через неделю перестают замечать. Ниже набор, с которого мы начинаем; дальше пороги подстраиваются под профиль нагрузки.
| Что снимаем | Предупреждение | Тревога | Что за этим обычно стоит |
|---|---|---|---|
| Свободное место на диске | занято 80% | занято 90% | Разросшиеся журналы, копии на том же диске, временные файлы обмена |
| Оперативная память | занято 85% | уход в подкачку | Утечка в приложении, слишком много рабочих процессов |
| Средняя нагрузка на процессор | выше числа ядер | вдвое выше числа ядер | Тяжёлый отчёт, выгрузка каталога, наплыв ботов |
| Ожидание дисковых операций | 10% времени | 25% времени | Соседи по гипервизору, нехватка кеша базы, медленный диск |
| Доступность службы | одна неудачная проверка | две подряд | Упал обработчик, кончились соединения, перезапуск не поднялся |
| Время ответа приложения | вдвое выше обычного | втрое выше | Медленный запрос, холодный кеш, блокировка в базе |
| Ошибки веб-сервера за минуту | рост вдвое | рост на порядок | Неудачный релиз, отказ внешнего сервиса, исчерпание лимитов |
| Соединения с базой | 70% лимита | 90% лимита | Зависшие запросы, приложение не закрывает соединения |
| Задержка репликации | 30 секунд | 5 минут | Тяжёлая запись, реплика не успевает — читать с неё уже опасно |
| Длина очереди задач | растёт полчаса | растёт час | Остановился обработчик очереди, внешний сервис не отвечает |
| Возраст последней резервной копии | старше суток | старше двух суток | Расписание сломалось, кончилось место в хранилище |
| Результат проверки восстановления | не запускалась месяц | развернуть не удалось | Копия повреждена — то есть копии фактически нет |
Последние две строки в чужих текстах про наблюдение не встречаются почти никогда, а они важнее половины остальных: сломанное расписание копий обнаруживается в тот день, когда копия понадобилась.
Схема реагирования: сигнал, реакция, разбор, профилактика
Регламент нужен не ради бумаги, а ради того, чтобы в три часа ночи никто не принимал решений с нуля. Схема из четырёх шагов, и на каждом зафиксировано, что происходит.
Сигнал. Порог пробит, оповещение уходит дежурному и дублируется звонком, если это тревога, а не предупреждение. Мелкие поводы собираются в дайджест и разбираются утром — иначе ночной канал зарастает шумом.
Реакция. Дежурный подтверждает, что взял сигнал, открывает инструкцию по этому типу аварии и делает первые шаги: проверить, восстановить, отсечь. Не помогло за отведённое время — эскалация выше. Границы времени и порядок подъёма — часть договора: наблюдение — в рабочий день · рабочий день — до 4 ч · круглосуточный — до 1 ч на аварию; восстановление по регламенту в договоре
Разбор. После восстановления пишется короткий документ: хронология по минутам, причина, что помогло, что мешало. Без поиска виноватых — иначе следующий инцидент начнут скрывать.
Профилактика. Выводы превращаются в задачи: новый порог, недостающая инструкция, запас по ресурсам, правка в коде. Этот шаг пропускают чаще остальных, и из-за него авария случается трижды.
Классификация инцидентов: что поднимает дежурного ночью
Без классификации обращение становится либо срочным, либо забытым. Договориться нужно до первой аварии: в момент аварии на это нет времени.
- Критический. Проект недоступен, платежи не проходят, данные теряются, обмен с учётом встал. Поднимает дежурного в любое время суток.
- Высокий. Работает, но плохо: выросло время ответа, отказала часть функций, не уходят письма. В рабочие часы — немедленно, ночью — по решению дежурного.
- Обычный. Локальная ошибка, сбой задания по расписанию, вопрос по настройке. Плановый срок, без подъёма людей.
- Наблюдение. Показатель ушёл в предупреждение без последствий: в отчёт и в план работ.
Дежурство вне рабочих часов рынок продаёт, но почти не называет своим именем: слово «дежурство» в разведке девятнадцати компаний встречается, термин on-call — ни разу, все пишут «круглосуточно» и «24/7». За этими словами стоит конкретная организация работы: график смен, подтверждение приёма сигнала, эскалация и компенсация ночных подъёмов.
Централизованные журналы и инструкции для типовых аварий
Половина времени разбора уходит не на решение, а на поиск: где лежат журналы этого сервиса, на какой машине, за какое время. Поэтому журналы приложения, веб-сервера, базы и системных служб сводятся в одно место с общим поиском и сроком хранения. Вопрос «что было в 3:14» решается за минуту вместо получаса.
Вторая часть — короткие инструкции на частые случаи: кончилось место, не поднялся обработчик, встала очередь, база отказывает в соединениях, зависла ночная выгрузка. Каждая написана под человека, который видит проект впервые: как проверить, что делать первым, чего нельзя и кого звать. Обновляются после каждого разбора — и оказываются главной ценностью при смене подрядчика: доступы передать легко, а знание о том, как этот проект ломается, уходит вместе с людьми.
Чем это отличается от наблюдения за доступностью веб-страниц
Границу проговорим прямо: услуги соседние и их часто путают. Здесь — инфраструктура: машины, службы, базы, очереди, обмены, дежурство и регламент реагирования. Наблюдение за внешней доступностью, временем отклика страниц, сроком сертификата и работой форм — отдельная услуга со своей страницей и своими тарифами.
Работают они с разных сторон и лучше вместе. Внешняя проверка первой замечает, что страница не открывается, но не объясняет почему. Внутренние метрики показывают причину и обычно предупреждают за час до того, как проблему увидит посетитель.