Инцидент — первые минуты, ранбук и хронология

Q: В журнале sudo ничего нет

Изменение пришло не через sudo: вход под root, выкладка от имени службы, автоматизация (cron, ansible, обновления пакетов). Смотри время изменения файлов (stat, find -newermt) и весь журнал вокруг начала сбоя: journalctl --since '12:00' --until '12:05'.

Q: Время в журналах не сходится

journalctl печатает время в поясе машины, date -u — в UTC. На учебной машине это одно и то же. На машине с другим поясом сравнивай в одном: journalctl --utc, TZ=UTC date.

9 мин Ubuntu 24.04 · systemd 255 · sudo 1.9

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

Шпаргалка

7 команд Версия для печати

1. симптом глазами пользователя
curl -s -o /dev/null -w '%{http_code}\n' http://localhost/
2. хронология: строка на каждое действие, время UTC
mkdir -p ~/incident; cd ~/incident
echo "$(date -u +%T) алерт «сайт 502», подтвердил" >> timeline.txt
3. что изменилось последним
sudo journalctl -t sudo --since -1h | grep COMMAND кто что запускал
sudo find /etc /opt /srv -newermt '-1 hour' -type f свежие файлы
ls -lt /etc/nginx/sites-enabled/ | head
4. копия до отката — улика для разбора
sudo cp -a /etc/default/lab-app ~/incident/
5. проверка тем же запросом, время — в хронологию

Обзор

Инцидент — событие, когда сервис не делает для пользователей то, что должен: сайт отвечает 502, ответы идут секундами, доля ошибок съедает бюджет быстрее нормы (sli-slo). О нём сообщает алерт (alertmanager) или сам пользователь.

Работа с инцидентом — порядок действий, который сокращает простой: подтвердить симптом → восстановить сервис → понять причину → разобрать сбой (postmortem). Первые два шага делает дежурный (on-call) — тот, кто в эту смену отвечает на алерты.

Сначала восстановить

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

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

Обратимый — значит, шаг можно отменить и после него остаются улики. Перед откатом скопируй изменённый файл в ~/incident/ (cp -a сохраняет время и права). Перед перезапуском сохрани systemctl status и последние строки журнала службы: перезапуск стирает состояние процесса.

Что изменилось последним

Большая часть сбоев начинается после изменения: правки конфига, выкладки, обновления пакета. Где искать:

sudo journalctl -t sudo --since -1h — команды через sudo: кто, когда и что запустил;
sudo find /etc /opt /srv -newermt '-1 hour' -type f и ls -lt в каталоге конфигов — какие файлы менялись (find);
журнал выкладки и история репозитория конфигов (git);
journalctl -u <служба> --since -1h — когда служба перезапускалась;
/var/log/apt/history.log — какие пакеты обновлялись.

Строка sudo в журнале (разбита для ширины):

text

Oct 22 12:00:41 node1 sudo[1234]:   deploy : TTY=pts/0 ;
  PWD=/home/deploy ; USER=root ;
  COMMAND=/usr/bin/sed -i s/8000/8001/ /etc/default/lab-app

Пользователь deploy в 12:00:41 поменял порт в файле службы. Если сайт начал отвечать 502 в 12:00:43, это первый подозреваемый. Время изменения сравнивают с началом симптома: изменение за секунды или минуты до него — кандидат на откат.

Ранбук

Ранбук (runbook) — инструкция на один алерт: что он значит, какие команды выполнить первыми, как восстановить сервис и кого звать. Его пишут заранее, без спешки; в сбой дежурный выполняет шаги и не придумывает их на ходу.

markdown

# Ранбук: <алерт> — <что видит пользователь>
Что значит: <какой компонент сообщил, что сломано>.
### Первые 10 минут
1. Подтверди симптом: <одна команда>.
2. Начни хронологию: echo "$(date -u +%T) …" >> ~/incident/timeline.txt
3. Что изменилось последним за час: journalctl -t sudo,
   find -newermt, журнал выкладки.
4. Восстанови обратимо: копия в ~/incident/, откат,
   перезапуск или переключение.
5. Проверь тем же запросом, что в шаге 1; время — в хронологию.
6. Сообщи <куда>; не восстановил за 15 минут — зови <кого>.
### Потом, когда сервис работает
Причина — по хронологии и копиям; разбор — postmortem.md.

Ранбук лежит там, где его найдут во время сбоя: рядом со службой (/srv/runbooks/<алерт>.md), ссылкой в тексте алерта.

Хронология по ходу

Хронология — список событий сбоя по времени, строка на событие:

text

12:00:41 deploy: sed в /etc/default/lab-app — порт 8000 → 8001
12:00:43 lab-sitecheck: сайт отвечает 502 — начало сбоя
12:03:10 дежурный вернул порт 8000, перезапустил lab-app
12:03:11 lab-sitecheck: сайт 200 — конец сбоя

Время первым и в UTC (date -u +%T), дальше — факт: что увидели или сделали и кто, ролью. Оценок в строке нет. Пишут по ходу, дописывая >> в файл: в стрессе время и порядок шагов забываются, а разбору нужны оба. Тот, кто подключился позже, читает хронологию и видит, что уже сделано. Как собрать хронологию из журналов после сбоя — postmortem.

Роли

Когда инцидент тянется дольше нескольких минут или в нём больше одного человека, роли делят:

Роль	Что делает
ведущий (incident commander)	решает, что делать, раздаёт задачи, сам не чинит
связной	сообщает пользователям и руководству, что происходит
исполнители	чинят по задачам ведущего и пишут в хронологию

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

Когда инцидент закончен

Сервис отвечает на тот же запрос, которым подтвердили симптом, и время записано в хронологию. Если восстановление временное (откат, ручной перезапуск), заводят задачу на настоящее исправление. Дальше — разбор сбоя (postmortem).

Рецепты

Подтвердить симптом серией запросов

bash

for i in $(seq 20); do
  curl -s -o /dev/null -w '%{http_code}\n' http://localhost/
done | sort | uniq -c

Один curl может попасть в удачный момент: при одном мёртвом бэкенде из двух падает часть запросов. Серия покажет долю ошибок.

Свежие изменения одним списком

bash

sudo journalctl -t sudo --since -1h -o short-iso | grep COMMAND
sudo find /etc /opt /srv -newermt '-1 hour' -type f \
  -printf '%TT %p\n' | sort

Первая команда — действия людей через sudo, вторая — файлы со временем изменения (с долями секунды) по порядку. -newermt понимает и точное время: -newermt '2026-10-22 12:00'.

Откатить правку конфига

bash

sudo cp -a /etc/nginx/sites-available/site ~/incident/site.bad
sudo cp -a /root/site.bak /etc/nginx/sites-available/site
sudo nginx -t && sudo systemctl reload nginx
echo "$(date -u +%T) откатил конфиг сайта" >> ~/incident/timeline.txt

Плохая версия сохранена для разбора, проверенный конфиг применён reload без обрыва соединений (nginx). Конфиги в git откатываются git checkout <прошлый коммит> -- <файл>. Откат релиза переключением симлинка — ln.

Неполадки

Откатил — не помогло

Откатил не то изменение: сверь время начала сбоя по журналу запросов и проверке сайта с временем изменений.
Служба не перечитала конфиг: нужен reload или restart.
Изменений было несколько: верни по одному, проверяя после каждого.
Сбой начался раньше изменения — ищи другую причину: диск, память, сеть, зависимость (база, соседний сервис).

Перезапуск помог, но сбой вернулся

Перезапуск убрал симптом, причина осталась: утечка памяти, растущий журнал, исчерпанные соединения. Сохрани systemctl status, журнал службы и free -m до следующего перезапуска — по ним видно, что копится.

В журнале sudo ничего нет

Изменение пришло не через sudo: вход под root, выкладка от имени службы, автоматизация (cron, ansible, обновления пакетов). Смотри время изменения файлов (stat, find -newermt) и весь журнал вокруг начала сбоя: journalctl --since '12:00' --until '12:05'.

Время в журналах не сходится

journalctl печатает время в поясе машины, date -u — в UTC. На учебной машине это одно и то же. На машине с другим поясом сравнивай в одном: journalctl --utc, TZ=UTC date.

Опасно

Чинить без копии

Правка на месте, удаление «битого» файла, перезапуск без снятого журнала стирают улики. Разбор потом строится на догадках, и тот же сбой повторяется. Копия в ~/incident/ занимает секунды.

Несколько правок разом

Три изменения подряд без проверки между ними: сервис ожил, но неясно, какое помогло, а два других могли добавить новую поломку. Одно изменение — одна проверка — одна строка в хронологии.

Термины

инцидент incident: Сбой, который видят пользователи: сайт отвечает ошибками, ответы идут секундами, бюджет ошибок тает быстрее нормы. Сервис сначала восстанавливают, причину ищут потом. Ещё встречается в: Постмортем, journalctl, Балансировка нагрузки
ранбук (runbook): Инструкция на один алерт: что он значит, какие команды выполнить первыми, как восстановить сервис и кого звать. Пишется заранее, в сбой по ней действуют. Ещё встречается в: Постмортем
дежурный (on-call): Тот, кто в эту смену отвечает на алерты: подтверждает сбой, восстанавливает сервис по ранбуку и ведёт хронологию. Ещё встречается в: Alertmanager: кому и сколько раз уходят алерты, Постмортем, SLI и SLO

См. также

postmortem — разбор сбоя без поиска виноватых.
sli-slo — бюджет ошибок и скорость его расхода.
journalctl — --since, -t, -u.
alertmanager — откуда приходит алерт.
find — поиск по времени изменения.
git — история конфигов.
ln — откат релиза симлинком.
systemctl — status, reload, restart.

Есть неточность? Сообщить об ошибке в статье