Устранение инцидента на сервере приёма платежей billing-02

1. Ситуация

«Пятый склад» хранит товары интернет-магазинов и доставляет их покупателям: 14 складов в Северогорске и области, 600 курьеров, около 9 000 отправлений в день. Клиенты оформляют доставку на сайте и в приложении, оплату принимает собственный сервис billing, обращения клиентов разбирает отдел поддержки в сервисе helpdesk.

23 человека: разработка, группа эксплуатации (5 инженеров) и служба информационной безопасности. Внутренние сервисы работают на серверах Ubuntu 24.04 в собственной серверной. Группа эксплуатации устанавливает сервисы по стандарту, следит за их работой и закрывает доступ уволенным сотрудникам. С октября 2026 года в группе эксплуатации проходят производственную практику практиканты колледжа. Они работают парами, получают заявки из очереди группы и сдают работу наставнику. Изменения на рабочих серверах вносит дежурный инженер по отчёту и журналу работ пары.

Группа эксплуатации обслуживает три сервера: helpdesk-01 — сервис заявок отдела поддержки; billing-02 — приём платежей и ночная сверка с банком; ops-03 — сервер группы эксплуатации: скрипты выкладки магазина, общие папки, документы бухгалтерии. Это задание относится к серверу billing-02. Работа ведётся по регламентам компании ПЖ-03 «Политика журналов и хранения данных», РИ-04 «Регламент инцидентов», ПР-06 «Порядок работы группы эксплуатации»; выдержки из них — в Приложении Б.

1.1. Заявка

Работа начинается с заявки в очереди группы эксплуатации. Её текст приводится полностью.

1.2. Хронология и участники

События до выдачи задания и после него расположены по времени. Ниже — сотрудники, которых касается задание; их учётные записи используются в работе так, как они записаны в таблице.

1.3. Что есть на сервере

На копии сервера, которую разворачивает стенд, находятся файлы и программы из таблицы. С них начинается осмотр сервера.

Из заявки и обстановки на сервере следует задача пары. Она описана в части 2 как перечень требований: каждое требование проверяется при приёмке.

2. Задача

Результат работы описывается пятью целями:

1. Записать симптомы инцидента числами до любых изменений и найти все его причины.
2. Освободить раздел журналов по политике хранения ПЖ-03, не потеряв бизнес-данные бухгалтерии.
3. Вернуть нормальную работу процессов, не останавливая приём платежей.
4. Закрыть файл настроек с паролем базы от посторонних пользователей.
5. Получить скрипт профилактики cleanup-logs.sh и postmortem, по которым инцидент не повторится.

Схема показывает части работы и порядок, в котором они связаны. Номер в блоке — раздел задания, где эта часть описана.

Требования ниже сгруппированы по тем же частям. Слова «должен» и «обязательно» обозначают требование, которое проверяется при приёмке. Номер требования записывается в журнал работ рядом с командами, которые его выполняют. Если требование и регламент расходятся, выполняется требование.

2.1. Диагностика

1. 2.1.1
   Симптомы записаны числами до любых изменений: заполнение раздела, что занимает место, нагрузка, самые загруженные процессы.
2. 2.1.2
   Найден процесс, который заполняет журнал, и настройка, из-за которой это происходит.

2.2. Место на диске

1. 2.2.1
   Раздел журналов заполнен не больше чем на 50 %.
2. 2.2.2
   Политика хранения: журналы старше 7 дней удаляются. Аварийные дампы памяти core.* на сервере не хранятся.
3. 2.2.3
   Выгрузки для бухгалтерии — данные, не журналы. Удалять их нельзя. Они перенесены в /var/lib/billing/exports с прежним владельцем, целостность подтверждена контрольной суммой sha256sum до и после переноса, параметр EXPORT_DIR исправлен.

2.3. Процессы

1. 2.3.1
   Приём платежей не останавливается дольше чем на несколько секунд. Супервизор billingd не останавливать.
2. 2.3.2
   Отладочный уровень журнала выключен (LOG_LEVEL=info), billing-api перезапущен через супервизор и работает с новым уровнем.
3. 2.3.3
   Сверка billing-report остановлена вместе со всеми рабочими процессами. Перезапускать её не нужно: это сделает разработчик после исправления.

2.4. Безопасность

1. 2.4.1
   В billing.conf лежит пароль базы, а файл открыт всем на запись. Владелец — root, группа — billing, остальным доступа нет. Служба после этого запускается.

2.5. Профилактика

1. 2.5.1
   Скрипт cleanup-logs.sh: печатает журналы старше 7 дней и дампы core.* в /var/log/billing и удаляет их только с ключом --apply. Выгрузки скрипт не трогает ни при каком расположении.

2.6. Задачи по выбору

Эти задачи выполняются после основных требований и дают дополнительные баллы. Файлы кладутся в папку optional/; при приёмке пара запускает скрипт на стенде или показывает документ.

Требования выполняются на копии сервера, вдвоём, в течение 14 дней. Как устроены стенд, работа в паре и этапы, описано в части 3.

3. Порядок работы

3.1. Копия сервера

Изменения на рабочем сервере billing-02 вносит дежурный инженер по отчёту пары. Пара работает на копии сервера: её разворачивает скрипт стенда в виртуальной машине с Ubuntu 24.04 из занятия 1. У каждого практиканта своя машина и свой стенд; нужно не меньше 2 ГБ свободного места и 2 ГБ памяти.

Перед первым запуском стенда в VirtualBox создаётся снимок состояния машины: к нему возвращаются, если машина перестала загружаться или потерян доступ к sudo. Стенд создаёт и удаляет учётные записи, правила sudo и каталоги служб, поэтому запускается только в виртуальной машине. Повторный запуск возвращает копию сервера в исходное состояние.

cd ~/Downloads
wget https://algorthimization-course-vvodnoe.vercel.app/op05-operacionnye-sistemy-i-sredy/proekty/ekspluataciya-servera/materials/billing-stand.sh
wget https://algorthimization-course-vvodnoe.vercel.app/op05-operacionnye-sistemy-i-sredy/proekty/ekspluataciya-servera/materials/billing-acceptance.sh
sudo bash billing-stand.sh

Раздел журналов на стенде — файл-образ на 170 МБ, подключённый к /var/log/billing. После перезагрузки виртуальной машины стенд разворачивают заново.

Скрипт приёмки ничего не изменяет: он проверяет копию сервера и печатает OK или FAIL по каждому из 12 пунктов. Пункт FAIL показывает, какое требование не выполнено; перевод пунктов — в Приложении А. Подгонять сервер под скрипт в обход требований запрещено.

sudo bash ~/Downloads/billing-acceptance.sh | tee acceptance.txt

3.2. Работа в паре

Работа делится на две части, общую часть пара выполняет вместе. Кто из пары практикант 1 и кто практикант 2, записывается в README.md. При приёмке каждый отвечает и за свою часть, и за часть напарника.

У пары один репозиторий — tz-02-billing: его создаёт практикант 1 и добавляет напарника в Settings → Collaborators. Каждый работает в своей ветке (part-1, part-2) и открывает Pull Request в main. Напарник повторяет команды на своём стенде, оставляет замечания и одобряет слияние. Журнал работ runbook.md общий: время, кто из пары, команда, результат, номер требования; ошибки и откаты тоже записываются.

3.3. Этапы

День 0 — дата выдачи задания. К концу каждого этапа результат загружен в репозиторий, наставник может проверить его без предупреждения.

3.4. Материалы

В работе используются методичка (порядок работы, частые сообщения об ошибках, Git в паре), справочник команд, шаблоны документов и каркасы скриптов и лекции занятий 3–8. Что изучить по каждой задаче, сказано в разделе «Куда смотреть» в конце страницы. PDF этого ТЗ содержит лист согласования и акт сдачи-приёмки.

Работа заканчивается сдачей репозитория и проверкой в присутствии пары. Что сдаётся и как выставляются баллы, описано в части 4.

4. Сдача и проверка

4.1. Что сдаётся

Работа сдаётся одной ссылкой на репозиторий GitHub. README.md начинается с таблицы: практикант 1 и практикант 2, за что отвечает каждый, итог приёмки «N из 12»; ниже — команды стенда, решения и приёмки по порядку. В конце две строки: «Не получилось: ___» и «Нейросеть использовалась для: ___».

tz-02-billing/
├── README.md            состав пары, кто за что отвечает, итог приёмки
├── server-passport.md   паспорт сервера до изменений
├── runbook.md           журнал работ
├── postmortem.md        postmortem
├── cleanup-logs.sh      скрипт повторяемости
├── acceptance.txt       вывод приёмки после финального прогона
├── optional/            задачи по выбору
└── screenshots/         снимки из таблицы ниже

Шаблоны README.md, журнала работ, паспорта сервера и документа «postmortem», а также каркас скрипта cleanup-logs.sh — в архиве шаблонов. Команды и их вывод в документах — только с вашей виртуальной машины.

4.2. Проверка

Проверка проходит в присутствии обоих практикантов и состоит из пяти испытаний. Пара заранее открывает виртуальную машину со снимком, репозиторий и журнал работ. Если испытание не пройдено, пара один раз устраняет замечания в течение 3 дней.

4.3. Оценка

Работа оценивается в 30 баллов. Оценку получает пара, вклад каждого виден по коммитам, Pull Request и журналу работ.

Работа не принимается, если решение не воспроизводится на стенде, развёрнутом заново, нет журнала работ или права ослаблены ради запуска службы или пункта приёмки.

Куда смотреть

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

Приложение А. Пункты скрипта приёмки

Скрипт billing-acceptance.sh печатает пункты на английском языке, сгруппированные по частям. В таблице — что означает каждый пункт и какое требование части 2 он проверяет. Требования, которые скрипт проверить не может, проверяются по документам и на испытаниях части 4.

Приложение Б. Выдержки из регламентов

Регламенты ИТ-отдела ООО «Пятый склад», которые относятся к этому заданию. Полные тексты хранятся во внутренней базе знаний группы эксплуатации.