Инцидент-менеджмент на сервере: разбор без поиска виноватых

Сервер может начать отдавать 502, упереться в лимит файловых дескрипторов или потерять связь с базой за несколько минут. В этот момент поиск виноватого только увеличивает простой: инженер отвлекается от восстановления, а важные факты исчезают из чатов. Рабочий инцидент-менеджмент для Linux-сервера с systemd 252+ и Nginx 1.24+ строится иначе: сначала вернуть сервис, затем сохранить хронологию, найти системную причину и превратить выводы в конкретные изменения.

Что считать инцидентом

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

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

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

Названия уровней не универсальны. Важнее зафиксировать измеримые критерии: долю ошибок, задержку, число затронутых клиентов, потерю заданий и допустимое время восстановления.

Беспричинный разбор защищает эго команды. Фактический разбор защищает следующий релиз.

Первые десять минут: восстановление, а не расследование

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

1. Командир инцидента. Принимает решения о приоритете, фиксирует гипотезы и запрещает несогласованные изменения. Он не обязан сам выполнять команды на сервере.
2. Исполнитель. Проверяет состояние хостов, процессов, сети и зависимостей. Каждое действие записывается с временем и результатом.
3. Коммуникатор. Обновляет внутренний канал и, если нужно, статус-страницу или клиентов. Он не пересказывает неподтверждённые версии.

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

Минимальный снимок состояния

До перезапуска или отката сохраните симптомы. Для Linux с systemd и Nginx пригодятся журнал сервиса, состояние процесса, свободное место, память и активные соединения.

# Версия и состояние сервиса
systemctl --version
systemctl status nginx --no-pager

# Последние записи журнала Nginx
journalctl -u nginx --since "15 minutes ago" --no-pager

# Ресурсы и сетевые соединения
uptime
free -h
df -h
ss -s

Команды не доказывают причину сами по себе. Они помогают закрепить исходную точку: когда начались ошибки, какой процесс работал, хватало ли диска и не изменилось ли число соединений.

Как вести хронологию, чтобы не спорить о памяти

Постмортем часто ломается не на техническом анализе, а на времени. В чате остаются фразы «примерно после деплоя» и «кажется, это началось ночью». Нужна одна временная шкала в UTC или в часовом поясе команды, но не смесь форматов.

Отдельно отмечайте гипотезы: «вероятно, исчерпан лимит соединений». Гипотеза не должна попадать в итог как факт, пока её не подтверждают журнал, метрика или воспроизводимая проверка.

Три режима работы и их цена

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

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

Что проверять после восстановления

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

• Проверить успешный запрос через тот же маршрут, которым пользуется клиент.
• Сравнить долю 4xx и 5xx с периодом до инцидента.
• Проверить задержку, очередь фоновых задач и число активных соединений.
• Убедиться, что не появились дубли платежей, потерянные задания или частичные записи.
• Зафиксировать, какие временные изменения были сделаны и как их убрать.

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

Постмортем без поиска виноватых

Хороший разбор отвечает на четыре вопроса: что увидел пользователь, как развивалась неисправность, почему защитные механизмы не остановили её и какое изменение снизит вероятность повторения. Вопрос «кто допустил ошибку» обычно слишком узок. Он приводит к ответу с именем, но не объясняет, почему система позволила одной ошибке пройти в прод.

Каркас документа

1. Краткое описание. Какой сервис и какая функция были затронуты.
2. Влияние. Какие пользователи или операции пострадали, сколько длилось ухудшение. Если точной оценки нет, так и напишите.
3. Хронология. Только события с источником и временем.
4. Причины. Отделите непосредственный триггер от условий, которые сделали сбой возможным.
5. Восстановление. Что сработало, что оказалось бесполезным и какие временные меры остались.
6. Действия. Конкретные задачи с владельцем, сроком и способом проверки результата.

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

Где процесс ломается

Нет единого владельца решения

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

Алерт сообщает о симптоме слишком поздно

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

В журнале нет контекста

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

План действий превращается в архив

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

Что делать дальше

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

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

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