Практики SRE: SLO, инциденты, отказоустойчивость / Ступень 5 из 8 · шаг 5 из 6

Приём событий встал, а перезапускать нельзя

~30 мин

Не запущена Запускается обычно ~20 с

Ситуация

Служба lab-ingest принимает события от витрин магазина — по пять в секунду, без перерыва. Принятые события она держит в памяти и каждые две секунды сохраняет пачкой на свой том /srv/ingest (каталог spool/), а каждое событие записывает в журнал /srv/ingest/log/ingest.log.

Алерт: curl localhost:8090/healthz отвечает 503, события перестали ложиться на диск и копятся в памяти. Дежурный до тебя уже «почистил» том, но место так и не появилось.

Перезапускать lab-ingest нельзя: события, которые ждут в памяти, при перезапуске пропадут.

Задача

На томе /srv/ingest снова есть место: занято меньше половины. Том тот же — не расширяй его и не подменяй.
Служба работает тем же процессом, что и во время сбоя.
Приём событий в строю: новые события принимаются (202), очередь из памяти легла на диск.
Служба пишет журнал в /srv/ingest/log/ingest.log, и на томе нет удалённых, но открытых файлов.
Журнал больше не съест том: правило logrotate ротирует ingest.log, как только он больше 10 МиБ, хранит не больше трёх архивов, и после ротации служба без перезапуска пишет в новый файл. logrotate на этой машине запускается каждый час.

Ограничения

lab-ingest и lab-clients не перезапускай и не останавливай, их программы и юниты не меняй.

Часть фактов видна только через sudo. Интернета на машине нет.

Цели лабы

0 из 5

На томе /srv/ingest снова есть место — занято меньше половины, том прежний — ещё не проверялась
Службу lab-ingest не перезапускали — работает тот же процесс, что и во время сбоя — ещё не проверялась
Приём событий в строю — события проверки приняты, очередь из памяти легла на диск — ещё не проверялась
Служба пишет журнал в /srv/ingest/log/ingest.log, удалённых открытых файлов на томе нет — ещё не проверялась
Правило logrotate ротирует ingest.log по размеру (не больше 10 МиБ, не больше 3 архивов), и после ротации служба без перезапуска пишет в новый файл — ещё не проверялась

Подсказки

открыто 0 из 3 · открываются по одной

Подсказка 1

Показать решение после 3 неудачных проверок

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

SRE · подобрано по лабе

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

Шпаргалка

$_ — вставить в терминал

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. проверка тем же запросом, время — в хронологию

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

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/ занимает секунды.

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

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