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

Сайт сломался после выкладки

~20 мин

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

Ситуация

Пришёл алерт: книжный магазин books.lab.test отвечает ошибкой 500. Главная, страницы каталога, даже файлы оформления — всё отдаёт 500. Посетители заходят на сайт прямо сейчас.

Сайт — статика на nginx. Его выкладывает CI: каждый релиз распаковывается в свой каталог /srv/books/releases/<версия>, а nginx отдаёт файлы из /srv/books/current.

Задача

Сначала верни сайт в строй, причину разберут потом.

Сайт снова работает на том релизе, который отдавал страницы до сбоя: /srv/books/current — ссылка на этот релиз.
Все адреса http://books.lab.test/ отвечают 200.
Посетители не теряют ни одного ответа: nginx не перезапускают и не останавливают.
Сбойный релиз остаётся в releases/ нетронутым — по нему будут разбирать сбой.

Ограничения

Конфигурацию nginx не меняй: сайт по-прежнему отдаётся из /srv/books/current.
Файлы релизов не правь.

Журналы nginx читаются через sudo. Интернета на машине нет.

Цели лабы

0 из 4

/srv/books/current — ссылка на релиз, который работал перед сбойной выкладкой — ещё не проверялась
Серия запросов к http://books.lab.test/ во время проверки — все ответы 200, страницы от этого релиза — ещё не проверялась
nginx не перезапускали и не останавливали — только перечитали; конфигурация сайта прежняя — ещё не проверялась
Сбойный релиз лежит в releases/ нетронутым — для разбора — ещё не проверялась

Подсказки

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

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

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