Практики SRE: SLO, инциденты, отказоустойчивость / Итоговая лаба

Смена дежурного

~50 мин

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

Ситуация

Ты принимаешь смену дежурного. Сайт заказов shop.lab.test работает на двух машинах. Пользователи открывают его по имени shop.lab.test — это плавающий адрес (VIP), его держит keepalived: основная машина — node1, резервная — node2. На node1 — балансировщик nginx и Prometheus, который собирает метрики обеих машин. На node2 — два backend'а приложения (службы lab-shop@8081 и lab-shop@8082), PostgreSQL с базой shop и отдельный том /var/log/shop для журналов приложения.

Вечером прошлая смена вносила изменения на обе машины. Несколько минут назад пошли жалобы: заказов на сайте не видно. Прошлый дежурный успел передать ещё две вещи: на node2 кончается место, а правило алерта, которое должно было об этом предупредить, в Prometheus так и не появилось. Ранбук по сайту — /srv/runbooks/shop-down.md на node1.

node1 — твой терминал. Команды на node2 выполняй через SSH: ssh node2 'команда' или войди в оболочку — ssh node2, назад — exit. sudo на обеих машинах работает без пароля. Браузера к машинам нет: сайт и Prometheus смотри из терминала — curl, jq, promtool.

Задача

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

Сайт http://shop.lab.test/ по плавающему адресу отдаёт список заказов из базы — на каждый запрос. Адрес, как и задумано, держит node1, keepalived работает на обеих машинах.
К базе shop подключается только приложение (роль shop). Это требование ввели вчера, и оно остаётся: роль report к базе shop не пускают.
Том /var/log/shop на node2 занят меньше чем на 80 %, а журнал приложения растёт так же, как до вечерних изменений.
Правило LogVolumeAlmostFull из /etc/prometheus/rules/ загружено в Prometheus.
В ~/postmortem.md на node1 — разбор сбоя, три раздела: - ## Хронология — не меньше трёх событий, по строке на событие: ЧЧ:ММ:СС что произошло (время машины, UTC, как в журналах). Среди них — момент, когда сайт перестал отдавать заказы; - ## Причина — что именно сломалось: каждая неисправность, которую ты нашёл; - ## Действия — что сделать, чтобы это не повторилось, хотя бы один пункт.

«Проверить» само делает 20 запросов к сайту по плавающему адресу и по 20 — к каждому backend'у на node2 (смотрит, на сколько вырос журнал приложения). Проверка занимает около 10 секунд.

Ограничения

Всё должно пережить перезагрузку обеих машин: службы включены, настройки лежат в файлах, а работающие службы перечитали эти файлы после правки.
Плавающий адрес не переноси на node2 и keepalived не выключай: резервная машина нужна на случай настоящей аварии.
/var/log/shop остаётся отдельным томом из /etc/fstab.

Интернета в лабе нет — только сеть между node1 и node2, всё нужное установлено. Время в журналах машин — UTC.

Цели лабы

0 из 5

Сайт http://shop.lab.test/ по плавающему адресу отдаёт заказы из базы на каждый из 20 запросов; адрес держит node1, keepalived работает на обеих машинах — ещё не проверялась
Приложение подключается к базе shop, а роль report получает отказ — база только у приложения; pg_hba.conf без ошибок и перечитан PostgreSQL — ещё не проверялась
Том /var/log/shop на node2 занят меньше чем на 80 %, журнал приложения растёт как до изменений, backend'ы работают с настройками из /etc/default/shop — ещё не проверялась
Правило LogVolumeAlmostFull загружено в Prometheus из файла, последняя перечитка конфигурации прошла — ещё не проверялась
В ~/postmortem.md на node1 — «Хронология» со временем начала сбоя по журналам, «Причина» с каждой найденной поломкой и «Действия» — ещё не проверялась

Подсказки

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

Подсказка 1

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

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

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

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

Службы и systemd · подобрано по лабе

nginx — веб-сервер и обратный прокси

Шпаргалка

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

sudo nginx -t проверить конфиг (только с sudo)
sudo systemctl reload nginx применить без обрыва соединений
sudo nginx -T | grep -n server_name какие сайты видит nginx
ls -l /etc/nginx/sites-enabled/ включённые сайты
curl -i -H 'Host: docs.lab.test' http://127.0.0.1/ кто ответит
sudo tail -n 5 /var/log/nginx/error.log почему 404, 403, 502
sudo tail -n 5 /var/log/nginx/access.log что спрашивали и код
sudo ss -tlnp | grep nginx на каких портах слушает

Раскладка Debian и Ubuntu:

/etc/nginx/nginx.conf — общие настройки, внизу include сайтов;
/etc/nginx/sites-available/ — файлы сайтов;
/etc/nginx/sites-enabled/ — ссылки на включённые сайты; nginx читает только их;
/var/log/nginx/access.log и error.log — журналы.

Включить сайт

bash

sudo ln -s /etc/nginx/sites-available/docs /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Файл в sites-available без ссылки в sites-enabled nginx не видит. Выключить сайт — удалить ссылку, файл остаётся.

nginx -t проверяет весь конфиг и называет файл и строку ошибки. reload перечитывает конфиг без обрыва соединений; с ошибкой в конфиге nginx оставляет старый. Команда systemctl reload возвращается сразу, а новые рабочие процессы берут соединения чуть позже: curl в той же строке может увидеть старое.

Журналы

access.log — строка на каждый запрос, error.log — почему запрос не удался и что сломалось при старте. Формат access.log по умолчанию — combined:

text

127.0.0.1 - - [20/Oct/2026:10:03:58 +0000] "POST / HTTP/1.1" 405 166 "-"

По полям: $remote_addr (адрес клиента), -, $remote_user, [$time_local], "$request" (метод, путь, версия), $status (код), $body_bytes_sent (размер тела), "$http_referer", "$http_user_agent" — в примере user-agent "curl/8.5.0" не поместился. Свой формат задаёт log_format — в файле сайта вне блока server:

nginx

log_format timed '$remote_addr [$time_local] "$request" '
                 '$status $body_bytes_sent $request_time';
access_log /var/log/nginx/app.log timed;

Код, который вернуло приложение за прокси, nginx передаёт как есть: 500 от приложения есть в access.log, а в error.log о нём ни строки — nginx свою работу сделал. Причину такой ошибки ищи в журнале самого приложения (journalctl). В error.log попадает то, что не удалось nginx: 502 и 504 ниже.

$request_time — сколько секунд nginx обрабатывал запрос. Файлы с .1 и .2.gz рядом с журналом — прошлые, их по расписанию отодвигает и сжимает logrotate (/etc/logrotate.d/nginx).

log_format действует только в контексте http: в файле сайта вне блока server или в /etc/nginx/conf.d/<имя>.conf. Имя формата заводят один раз на весь конфиг — второй log_format с тем же именем nginx -t не пропустит. Для SLI (sli-slo) в конец строки добавляют время ответа и время запроса в unix-времени ($msec):

nginx

log_format sre '$remote_addr - $remote_user [$time_local] "$request" '
               '$status $body_bytes_sent "$http_referer" '
               '"$http_user_agent" $request_time $msec';

За балансировщиком (nginx) полезны поля бэкенда:

Переменная	Что пишет
`$upstream_addr`	адрес копии, которая отвечала
`$upstream_status`	код ответа копии; отказ в соединении — `502`
`$upstream_response_time`	сколько секунд ждали копию

Если nginx повторил запрос на другой копии, эти поля — списки через запятую с пробелом: 127.0.0.1:8082, 127.0.0.1:8081 и 502, 200. У ответов, которые nginx отдал сам, без бэкенда, в полях -; если живых копий нет — имя группы upstream. В формате такие поля берут в кавычки, иначе номера полей awk поплывут.

Прокси: путь и заголовки

Есть ли URI после адреса в proxy_pass, решает, какой путь получит приложение:

`location /api/` и `proxy_pass`	Запрос `/api/x` уходит как
`http://127.0.0.1:3003`	`/api/x` — путь без изменений
`http://127.0.0.1:3003/`	`/x` — `/api/` заменено на `/`

По умолчанию приложение видит Host: 127.0.0.1:3003 — адрес из proxy_pass. Имя сайта и адрес клиента передают заголовками:

nginx

proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Балансировка: upstream

Несколько копий приложения за одним адресом — блок upstream в контексте http (в файле сайта вне server), proxy_pass указывает на его имя. Зачем и как это работает — load-balancing.

nginx

upstream app {
    server 127.0.0.1:8081 max_fails=2 fail_timeout=10s;
    server 127.0.0.1:8082 max_fails=2 fail_timeout=10s;
}
server {
    listen 80;
    location / {
        proxy_pass http://app;
        proxy_next_upstream error timeout http_500 http_502 http_503;
        proxy_connect_timeout 2s;
        proxy_read_timeout 3s;
    }
}

Параметры строки server в upstream:

Параметр	По умолчанию	Что делает
`max_fails=N`	1	неудач за `fail_timeout`, после которых копия выключается; 0 — не считать
`fail_timeout=T`	10s	окно подсчёта неудач и время, на которое копия выключается
`weight=N`	1	доля запросов копии
`backup`	—	копия получает запросы, только когда остальные выключены
`down`	—	копия выключена руками

Директивы в location рядом с proxy_pass:

Директива	По умолчанию	Что делает
`proxy_next_upstream`	`error timeout`	что считать неудачей и повторять на другой копии; `http_500` и др. добавляют коды
`proxy_next_upstream_tries`	0 (без предела)	сколько копий пробовать на один запрос
`proxy_connect_timeout`	60s	сколько ждать соединения с копией
`proxy_read_timeout`	60s	сколько ждать ответа копии

Что видно на машине (nginx 1.24, одна копия из двух не слушает порт): клиент получает 200 — nginx повторяет запрос на живой копии; в error.log одна строка connect() failed (111: Connection refused) раз в fail_timeout, пока копия выключена. Копия отвечает 500 сама — клиент получает 500 через раз, пока в proxy_next_upstream нет http_500. На машине с одним ядром nginx запускает один рабочий процесс, и круговой порядок строгий: 8081, 8082, 8081…

HTTPS и перенаправление с HTTP

nginx

server {
    listen 443 ssl;
    server_name shop.lab.test;
    ssl_certificate     /etc/nginx/tls/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/shop.key;
    root /var/www/shop;
}
server {
    listen 80;
    server_name shop.lab.test;
    return 301 https://$host$request_uri;
}

ssl_certificate — файл цепочки: сначала сертификат сайта, за ним промежуточный. $request_uri — путь вместе с запросом после ?: http://shop.lab.test/x?y=1 уводит на https://shop.lab.test/x?y=1. Сертификаты и их проверка — openssl-tls.

Кто ответит на имя

bash

curl -i -H 'Host: docs.lab.test' http://127.0.0.1/
sudo nginx -T | grep -n 'server_name\|listen'

Первая команда — ответ глазами клиента, вторая — какие listen и server_name nginx на самом деле прочитал, в порядке файлов.

Найти, где сломан прокси

bash

curl -s -o /dev/null -w '%{http_code}\n' http://app.lab.test/
sudo tail -n 1 /var/log/nginx/error.log
curl -i http://127.0.0.1:3000/        # приложение напрямую

Строка error.log называет upstream — куда nginx шёл. Приложение напрямую отвечает — дело в proxy_pass или правах; не отвечает — в приложении.

Отвечает чужой сайт

Host запроса не совпал ни с одним server_name — ответил сервер по умолчанию. Проверь имя в server_name и что ссылка на сайт есть в sites-enabled: sudo nginx -T | grep server_name. Имя верное, а отвечает default — сравни listen: блок с адресом машины не видит запросов на другой адрес, например на VIP (nginx).

404 Not Found

В error.log — путь, который собрал nginx: open() "/var/www/portal/nope.html" failed (2: No such file or directory). Сравни его с настоящим путём файла: обычно ошибка в root или alias.

403 Forbidden

(13: Permission denied) — www-data не может прочитать файл или войти в каталог по пути; права по всему пути покажет namei -l. directory index of "…" is forbidden — в каталоге нет файла из index.

502 Bad Gateway

nginx не открыл соединение с бэкендом. Причину называет строка error.log:

В error.log	Что значит
`(111: Connection refused)`	никто не слушает адрес или сокет
`(13: Permission denied)`	у `www-data` нет права на сокет
`(2: No such file or directory)`	нет файла сокета по этому пути
`upstream prematurely closed connection`	соединение было, но приложение закрыло его, не дослав ответ: упало на этом запросе

Полностью: connect() failed (111: Connection refused) while connecting to upstream, … upstream: "http://127.0.0.1:3001/". Для сокета — connect() to unix:/run/app/app.sock failed (13: Permission denied). Ошибки 13 и 2 nginx пишет с уровнем [crit], 111 — [error]: поиск только по [error] их пропустит. Сокет остался после остановки приложения — тоже 111. Права и пути сокетов — в статье unix-sockets.

504 Gateway Time-out

Соединение есть, ответа нет: upstream timed out (110: Connection timed out) while reading response header from upstream. Приложение зависло или отвечает дольше proxy_read_timeout (по умолчанию 60 с).

no live upstreams

no live upstreams while connecting to upstream, … upstream: "http://app/" и 502 у клиента: все копии группы upstream выключены после неудач (max_fails), пробовать некого. В $upstream_addr вместо адреса — имя группы. Почини хотя бы одну копию; через fail_timeout nginx попробует их снова (load-balancing).

duplicate "log_format" name

[emerg] duplicate "log_format" name "sre" in … — формат с этим именем уже заведён в другом файле. Найти оба: sudo nginx -T | grep -n 'log_format'. Оставь один, сайты пишут им через access_log … sre;.

Cannot assign requested address

bind() to 10.0.0.100:80 failed (99: Cannot assign requested address) — в listen адрес, которого на машине сейчас нет: плавающий адрес живёт на другой машине (keepalived). Слушай listen 80 и различай сайты по server_name, или разреши привязку к чужому адресу: sysctl net.ipv4.ip_nonlocal_bind=1.

nginx -t: test failed

unexpected "}" in …:5 — в строке перед } нет ;;
a duplicate default server for 0.0.0.0:80 — default_server стоит в двух блоках одного порта;
open() "/run/nginx.pid" failed (13: Permission denied) — nginx -t запущен без sudo.

conflicting server name

[warn] conflicting server name "docs.lab.test" on 0.0.0.0:80, ignored — одно имя стоит в двух блоках одного порта. Проверку это не роняет, но запросы с этим именем получает блок, загруженный первым, а второй его не получает никогда. Найти оба:

bash

grep -n 'docs.lab.test' /etc/nginx/sites-enabled/*

grep -r по каталогу здесь не годится: ссылки в sites-enabled он пропускает.

key values mismatch

SSL_CTX_use_PrivateKey(…) failed (… key values mismatch) — первый сертификат в файле ssl_certificate не пара ключу. Либо ключ чужой, либо в файле цепочки первым стоит промежуточный сертификат. Сертификат сайта — первым.

Новый сертификат не виден

nginx читает сертификаты при старте и reload. Заменил файл — sudo nginx -t && sudo systemctl reload nginx, проверяй через секунду.

Служба не стартует: порт занят

sudo ss -tlnp | grep ':80 ' покажет, кто держит порт. Останови его или смени listen.

Новый listen не применился

Смена адреса на том же порту (listen 80 → listen 127.0.0.1:80) через reload не проходит: systemctl reload возвращает 0, nginx остаётся на старых сокетах, а в error.log — bind() to 127.0.0.1:80 failed (98: Address already in use). Такую правку применяет только sudo systemctl restart nginx; что слушается на самом деле — sudo ss -tlnp | grep nginx.

restart с ошибкой в конфиге

reload при ошибке оставляет работать старый конфиг, restart — останавливает nginx и не может запустить: все сайты на машине лежат. Перед любым применением — sudo nginx -t.