Пара 25: Game day: выпуск с аварией

90 минут · 3 курс, ML.

Содержание и результат

Работать по ролям, сохранить факты, восстановить сервис и написать разбор инцидента.

План занятия

0–10: контекст и исходная задача. 10–40: устройство и механизмы. 40–55: демонстрация команд. 55–80: лабораторная работа. 80–90: разбор результата и фиксация исправлений.

Практика выполняется в своей учебной папке и на localhost. Подготовка окружения описана в lab/README.md.

Роли уменьшают хаос

Один координирует, другой проверяет, третий фиксирует.

Команда из 2–3 человек распределяет роли: координатор формулирует симптом и следующий шаг, оператор выполняет адресные действия, наблюдатель ведёт временную линию. Если участников двое, координатор ведёт журнал. Никто не «чинит всё» параллельно без согласования, иначе теряется причинность. Область эксперимента — собственный Compose project на localhost; production-сервер курса не является полигоном. Перед стартом есть backup, исходная версия и smoke. Цель — восстановить пользовательский путь и показать доказательства, а не угадать тайную команду преподавателя.

Аналогия: пожарная команда делит задачи, а не все бегут к одному вентилю.

Восстановление раньше большого рефакторинга

Уменьшаем воздействие обратимым изменением.

Если причина связана с новым выпуском и есть проверенный v1, возврат может быть быстрее исправления сложного кода. Сначала сохраняем достаточные факты, чтобы не потерять возможность расследования, затем возвращаем сервис. Нельзя удалять volume, менять весь firewall или переустанавливать Docker в ответ на локальный отказ. После восстановления повторяем исходный пользовательский запрос, проверяем версию, ошибки и данные. Коренная причина может потребовать отдельной работы; не заявляем её устранённой, если выполнен только rollback.

Аналогия: сначала останавливаем течь, потом меняем конструкцию водопровода.

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

Объясняем, как условия позволили ошибке пройти.

Postmortem содержит воздействие, временную линию, подтверждённую причину, восстановление и улучшения с владельцем. Пишем «проверка не покрывала неверный MODEL_PATH», а не «Петя невнимательный». Для каждого улучшения нужна связь с причиной: тест конфигурации, smoke после выпуска, точная версия, restore-check. Не перечисляем десять абстрактных best practices. Оцениваем ход рассуждения и честность доказательств. Если причину не нашли полностью, укажите, какая гипотеза осталась и какие данные нужны.

Аналогия: расследование аварии улучшает систему, а не только находит фамилию.

Команды и наблюдения

Окружение: Ubuntu / Bash, lab; преподаватель выбирает один сценарий.

bash scripts/smoke.sh
# Scenario: missing model artifact on the next launch
MODEL_PATH=/app/models/missing.json docker compose up -d --force-recreate app
docker compose ps
docker compose logs --tail 30 app
MODEL_PATH=/app/models/model.json docker compose up -d --force-recreate app
bash scripts/smoke.sh

Сценарий проводится только в учебном lab. Перед началом остановите конфликтующие ручные запуски и подготовьте backup.

Ожидаемый результат: app не проходит запуск с отсутствующим артефактом; журнал называет причину; корректный путь восстанавливает пользовательский запрос.

Вариант для macOS

Game day выполняется в своём Docker/Compose project. Для native Mac используйте lsof вместо ss; системные службы macOS и личные данные не затрагиваются.

docker compose ps
docker compose logs --tail 30 app
bash scripts/smoke.sh

Практика: Командная аварийная тренировка

  1. За 5 минут запишите baseline: версия, healthz, predict, число событий.
  2. Преподаватель выбирает неверный порт клиента, отсутствующий артефакт, DELAY_MS=1000 или остановку app.
  3. За 20 минут восстановите сервис по runbook, фиксируя команды и время.
  4. За 15 минут напишите postmortem и предложите одну профилактику, затем поменяйтесь ролями и повторите короткий сценарий.

Результат: incident-report.md с доказанным восстановлением и одним улучшением.

Проверка: Изменения ограничены своим lab; исходный volume сохранён; все настройки вернулись к baseline.

Неисправность для разбора: Устранив симптом, команда заявляет, что коренная причина доказана без журнала и проверки.

Решение и диагностика

Ключ сценариев: порт — сверить URL и ss/docker compose ps; артефакт — проверить MODEL_PATH и журнал раннего отказа; задержка — сравнить latency и конфигурацию, вернуть DELAY_MS=0; остановка — start app и smoke. Не внедряйте настоящую потерю данных. Если команда застряла, подсказка первого уровня — выбрать слой DNS/TCP/HTTP/process/config, второго — показать релевантный лог, третьего — предложить обратимое восстановление.

Основные выводы

Самостоятельная работа

Подготовить итоговую демонстрацию и проверить все инструкции на чистом окружении.

Источники