Чек-лист перед отпуском администратора: что передать и что автоматизировать

MAATRIX

За две недели до отпуска типичный администратор делает одно и то же: заводит коллеге аккаунт в панели, скидывает пароль от root в личку и говорит «звони, если что». Через три дня в отпуске звонят — потому что доступ есть, а понимания, что с ним делать, нет. Разница между «передал дела» и «коллега реально справится» — это не бумажка и не акт приёма-передачи, а проверяемая способность другого человека закрыть типичный инцидент без вас на связи. Ниже — чек-лист, который превращает формальную передачу в рабочую: что документировать, как раздавать доступы, куда переключить уведомления и как проверить готовность замещающего до того, как вы выключите телефон.

Почему «выдал доступ» и «коллега справится» — это разные вещи

Доступ — это необходимое, но не достаточное условие. У замещающего может быть root на сервере и полный список паролей, и при этом он не знает, что перезапуск контейнера с базой нужно делать в строго определённом порядке, потому что иначе приложение стартует раньше, чем поднимется база, и падает в crash loop. Это знание никогда не попадает в вики само по себе — оно живёт в голове администратора как рефлекс, наработанный за месяцы разбора одних и тех же грабель.

Формальная передача дел закрывает вопрос «может ли коллега технически войти на сервер». Реальная готовность отвечает на другой вопрос: «сможет ли коллега за 15 минут понять, что случилось, и исправить это без звонка вам». Между этими двумя состояниями обычно лежит разрыв в три вещи: документация, которая существует не только в голове, доступы, которые реально работают, а не просто выданы, и уведомления, которые доходят до живого человека, а не в чат, который никто не читает по выходным. Дальше — как закрыть каждую из них, и последний, самый важный пункт — как проверить, что закрыли, а не понадеяться.

Документируй то, что обычно держится в голове

Первый шаг — не техническая настройка, а инвентаризация. Задача — выгрузить из головы всё, что вы делаете по памяти, а не по инструкции. Практический способ понять, чего не хватает: попробуйте на минуту представить, что вы отвечаете коллеге текстом, а не голосом, и не можете уточнить контекст. Чего не хватит в вашем описании?

Минимальный набор документов, который должен появиться в вики (Outline, BookStack, Wiki.js — неважно, лишь бы не в личных заметках):

• Карта инфраструктуры. Какие серверы есть, что на каждом крутится, где какой домен, какая роль (прод, стейджинг, бэкап-хост). Достаточно таблицы на одну страницу.
• Runbook по типовым инцидентам. Не общее «если сайт не работает, разберись», а конкретные сценарии: диск заполнен на 95%, контейнер в рестарт-луп, сертификат просрочен, база не отвечает. Для каждого — команды диагностики и порядок действий.
• Список cron-задач и systemd-таймеров с объяснением, зачем они нужны. Выгрузите список и добавьте по строке комментария к каждому пункту, который не очевиден из названия:

crontab -l -u deploy
systemctl list-timers --all

• Порядок запуска и остановки сервисов, если он важен (база раньше приложения, кэш раньше базы). Одна строка в духе docker compose up -d db redis && sleep 15 && docker compose up -d app избавляет от догадок в момент, когда что-то уже упало.
• Контакты внешних зависимостей: хостинг-провайдер, регистратор домена, поддержка платёжной системы, если через неё идут алерты. С логинами (без паролей — пароли в отдельном менеджере, см. ниже) и способом связи.
• Что НЕ трогать без вас. Список операций, которые лучше отложить до вашего возвращения: миграции схемы БД, смена версии ядра, что угодно необратимое. Это не менее важно, чем инструкция «что делать» — часто самый безопасный ответ на нестандартную ситуацию — «подождать», и коллега должен знать, где эта граница.

Пример структуры runbook-страницы для одного инцидента, которая реально работает лучше абзаца текста:

Диск заполнен на сервере prod-1

Симптомы: алерт "disk usage > 90%" в Telegram, сайт может начать отдавать 500 при записи логов.

1. Проверить, что растёт:

du -sh /var/log/* /var/lib/docker/* 2>/dev/null | sort -rh | head -20

1. Если это docker-логи — обрезать без даунтайма:

truncate -s 0 /var/lib/docker/containers/*/*-json.log

1. Если это старые бэкапы — см. политику ротации в /etc/borgmatic/config.yaml,

удалять руками нельзя, только через borgmatic prune.

1. Если причина не ясна за 10 минут — НЕ удалять файлы наугад,

написать в чат "Отпуск-дежурство" и ждать.

Такой формат снимает главный риск любого инцидента без документации — что человек начнёт делать что-то необратимое от растерянности.

Передай доступы замещающему — но не общие, а именные

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

Правильный порядок — именной доступ с ограничением ровно на то, что нужно:

# на сервере: создать пользователя для замещающего
adduser ivan_backup
usermod -aG sudo ivan_backup   # или docker, если задача только с контейнерами

# на стороне ivan: сгенерировать ключ и передать публичную часть
ssh-keygen -t ed25519 -C "ivan-vacation-cover"

Публичный ключ добавляется в ~/.ssh/authorized_keys пользователя, приватный остаётся у коллеги — вы его не видите и не пересылаете. Если у вас уже настроен единый вход через Authelia, Authentik или Keycloak — заведите коллеге отдельную учётку с ролью на нужные сервисы, а не делитесь своей.

Что обязательно нужно передать, помимо SSH:

Если тема доступов для команды в принципе не выстроена — это отдельная и более широкая задача, которую стоит закрыть не за день до отпуска, а заранее; общий подход к разграничению прав без раздачи root разобран в статье как раздать доступ команде без выдачи root.

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

Настрой уведомления о критичных событиях на второго человека

Самая частая ошибка — отпуск наступает, а все алерты по-прежнему идут в личный Telegram-чат администратора, который либо выключил телефон, либо не проверяет рабочие уведомления намеренно. Формально мониторинг работает, реально — никто не видит алерт до возвращения.

Что нужно сделать заранее, а не в последний день:

1. Завести отдельный канал или групповой чат для дежурства, куда добавлены и вы, и замещающий, и в идеале ещё один человек про запас. Личные чаты для этого не годятся — уведомление, отправленное лично вам, замещающий физически не увидит.
2. Перенастроить маршрутизацию алертов на этот канал на время отпуска. Если используете Alertmanager — это отдельный route с исключением по времени или простое временное изменение receiver в конфиге:

route:
  receiver: 'vacation-oncall'
  routes:
    - match:
        severity: critical
      receiver: 'vacation-oncall'
receivers:
  - name: 'vacation-oncall'
    telegram_configs:
      - chat_id: -1001234567890
        bot_token: '${TG_BOT_TOKEN}'

Если стек проще — Uptime Kuma или Zabbix с ботом в Telegram — обычно достаточно временно поменять chat_id получателя в настройках уведомлений или добавить второй канал получателем в дополнение к вашему личному. Подробно про то, как поднять бота для уведомлений с нуля, если его ещё нет, — в статье бот для уведомлений о событиях на сервере.

1. Разделить severity. Замещающему не нужны все алерты — ему нужны только те, что требуют действия прямо сейчас. Если вперемешку с критичными алертами идёт шум («CPU 80% на пять минут», который сам проходит), коллега либо начнёт их игнорировать, либо будет дёргать вас по мелочам. Практика показать: если у вас алерты и так вызывают усталость от постоянного шума, отпуск — хороший повод наконец развести пороги по важности, а не откладывать это на потом.
2. Поставить дату окончания на временную маршрутизацию. Забытый вечный редирект алертов на чужой номер — обычная находка при следующем аудите конфигурации.

Проверьте, что канал реально работает, а не выглядит настроенным: отправьте тестовый алерт (например, временно занизьте порог диска на тестовом сервере) и убедитесь, что сообщение действительно дошло до замещающего, а не потерялось из-за неверного chat_id или лимита бота.

Проверь, что замещающий реально может — а не просто получил доступ

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

Практический способ проверить — не спросить «всё понятно?» (на этот вопрос всегда отвечают «да»), а дать замещающему выполнить реальную операцию до вашего отъезда, пока вы рядом и можете подстраховать:

• Попросите его самостоятельно, только по документации, перезапустить один из некритичных сервисов. Засеките, сколько времени это заняло и сколько раз он обращался к вам за подсказкой. Каждое обращение — это пробел в runbook, который нужно закрыть до отъезда, а не во время него.
• Смоделируйте один типовой инцидент из вашего runbook. Например, заполните диск на тестовом или менее критичном сервере до 95% и попросите коллегу пройти сценарий из документации целиком, от получения алерта до подтверждения, что проблема решена.
• Проверьте, что он умеет откатить неудачный деплой или контейнер, если это в принципе может понадобиться за время вашего отсутствия:

docker compose ps
docker compose logs --tail=100 app
docker compose restart app
# если не помогло — откат на предыдущий образ
docker compose pull app:previous-tag && docker compose up -d app

• Убедитесь, что он знает границу своей компетенции — то есть реально остановится и напишет в чат, а не будет импровизировать, столкнувшись со сценарием, которого нет в документации. Это стоит проговорить прямо: «если ситуация не из списка — не гадай, подожди или звони», и убедиться, что он с этим согласен, а не воспримет как формальность.

Если на этом шаге выясняется, что коллега теряется даже в тестовом сценарии — лучше узнать это за неделю до отпуска, а не в первый день, когда лежит прод. Разница между формальной передачей и реальной готовностью проверяется ровно так: не документом, а тем, довёл ли человек тестовый инцидент до конца без вашей помощи.

Финальный чек-лист: за неделю и за день до отъезда

Разнесите подготовку по времени — попытка сделать всё в последний рабочий день гарантированно оставит пробелы.

За одну-две недели:

• Runbook по 4-5 типовым инцидентам написан и лежит в общей вики, не в личных заметках.
• Заведён отдельный пользователь для замещающего на всех серверах, куда нужен доступ.
• Пароли от панелей и сервисов лежат в общем сейфе менеджера паролей, а не в личном.
• Проведён тестовый прогон — замещающий самостоятельно закрыл хотя бы один смоделированный инцидент.

За 2-3 дня:

• Уведомления переключены на дежурный канал, тестовый алерт дошёл и подтверждён.
• В календаре и статусах (Slack/Telegram) стоит явная отметка об отпуске с датами и контактом на замещение.
• Отложены любые операции, которые лучше не начинать прямо перед отъездом: крупные миграции, обновление мажорной версии ядра или базы, смена сертификационного центра. Если что-то из этого не терпит — сделайте заранее, оставив время на откат, а не в последний день.
• Проверено, что автоматические бэкапы реально идут и реально восстановимы, а не просто запускаются по расписанию. Быстрый тест — восстановить последний бэкап на тестовый сервер и убедиться, что данные читаются:

# пример для borgmatic
borgmatic list
borgmatic extract --archive latest --path /tmp/restore-test

В последний рабочий день:

• Короткая финальная сверка с замещающим: где искать документацию, куда пишет мониторинг, какая граница «звонить/не звонить».
• Отправлено сообщение в дежурный чат с датами отпуска, ссылкой на runbook и явным указанием, кто первый контакт по критичным инцидентам.
• Ваш личный телефон убран из списка получателей критичных алертов — если он там останется «на всякий случай», уведомления будут приходить и вам, размывая ответственность и создавая ложное чувство, что кто-то один точно среагирует.

Частые вопросы