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

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

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

Шаг 5 из 6 · лаба · 30 мин

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

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

Ситуация

Служба 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 архивов), и после ротации служба без перезапуска пишет в новый файл — ещё не выполнена

Ctrl+Enter

Запустит машину node1 · Ubuntu 24.04

Машина запускается

Подсказки

0 из 3

Сообщить о проблеме

Цели лабы

0 из 5

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

node1 Ubuntu 24.04

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

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

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

Цели лабы

0 из 5

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

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

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