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

Ранбук и первые 10 минут

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

Шаг 6 из 7 · лаба · 20 мин

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

Книжный магазин после очередной выкладки отвечает ошибкой 500 на любой адрес. Верни сайт на прежний рабочий релиз так, чтобы посетители не заметили переключения, и сохрани сбойный релиз для разбора.

Ситуация

Пришёл алерт: книжный магазин 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/ нетронутым — для разбора — ещё не выполнена

Ctrl+Enter

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

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

Подсказки

0 из 3

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

Цели лабы

0 из 4

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

node1 Ubuntu 24.04

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

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

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

Цели лабы

0 из 4

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

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

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

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