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

MAATRIX

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

Почему быстрая передача «на бумаге» дороже, чем кажется

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

Типичный сценарий: новый администратор технически грамотен, но не знает, что на сервере есть cron-задача, которая раз в месяц чистит логи нестандартным скриптом, потому что стандартный logrotate когда-то не подошёл под конкретную нагрузку. Или что резервная копия базы данных технически создаётся, но никто два года не проверял, что из неё можно восстановиться. Или что у DNS-зоны есть второй, менее очевидный NS-провайдер, добавленный после инцидента три года назад, — и его тоже нужно поддерживать в актуальном состоянии.

Ни один из этих фактов не всплывает в акте приёма-передачи. Они всплывают в момент инцидента — обычно через несколько недель после того, как прежний администратор уже недоступен.

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

День 1: обзорная сессия и карта инфраструктуры

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

Формат — совместная сессия за одним экраном (или в видеозвонке с шарингом экрана, если работа удалённая), а не документ, присланный на почту. На словах и по ходу дела всплывает то, что не попадает в письменные инструкции.

Что нужно закрыть за день:

• Инвентаризация серверов и сервисов. Таблица или список: какие машины есть, где физически или у какого провайдера, для чего каждая нужна.
• Схема зависимостей. Что от чего зависит: например, приложение падает без Redis, Redis падает без диска на конкретном разделе, бэкапы идут на отдельный сервер хранения.
• Точки единого отказа. Есть ли компоненты, при выходе которых из строя ложится всё сразу — часто это единственный сервер БД без реплики или единственный NAT-шлюз для внутренней сети.
• Внешние зависимости. Домены, регистратор, DNS-провайдер, центр сертификации, платёжные и почтовые шлюзы, сторонние API.
• Кто ещё в курсе. Есть ли коллеги, подрядчики или прежние сотрудники, к которым можно обратиться по конкретным вопросам, если прежний администратор уже недоступен.

Практический инструмент — таблица инвентаризации, которую заполняют вместе прямо на сессии:

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

Дни 2-3: детальный разбор каждого критичного компонента

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

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

• Где лежит код и конфигурация (репозиторий, путь на диске, кто и как его правит).
• Как устроен деплой — через CI/CD или руками, и если руками, то какими именно командами.
• Как и куда делаются резервные копии, по какому расписанию, кто и когда последний раз проверял, что из бэкапа реально можно восстановиться.
• Какой мониторинг настроен, какие пороги считаются тревожными, куда падают алерты.
• Какие у компонента известные «грабли» — то, что один раз уже ломалось, и решение, до которого пришлось доходить методом проб и ошибок.

Последний пункт — самое ценное, что можно получить от прежнего администратора, и то, что почти никогда не записано ни в одной инструкции. Формулировка вроде «этот сервис нельзя перезапускать в рабочее время, потому что прогрев кэша занимает 20 минут, и первые пользователи попадают на холодный кэш» — типичный пример знания, которое живёт только в голове человека, который это один раз пережил.

Разбор эффективнее проводить не по описанию, а на реальной системе — вместе зайти по SSH, вместе выполнить типовые операции:

# посмотреть, как реально запущен сервис
systemctl status myapp
systemctl cat myapp

# посмотреть, где лежат актуальные конфиги, а не то, что "должно быть"
find /etc -name "*.conf" -newer /etc/hostname 2>/dev/null

# пройтись по крону — там часто живут забытые задачи
crontab -l
ls /etc/cron.d/

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

Имеет смысл записывать эти сессии на видео (экран плюс голосовой комментарий) — новый администратор физически не запомнит всё с первого раза, а запись позволяет вернуться к конкретному моменту через две недели, когда возникнет похожая ситуация. Держите записи в той же папке, где лежит остальная документация проекта, а не в личных файлах кого-то из участников.

День 4: полная передача доступов и документации

Четвёртый день — формальная, но важная часть: нужно собрать полный перечень всех точек входа в инфраструктуру и провести передачу каждой из них так, чтобы новый администратор получил собственные, а не «одолженные» у прежнего учётные данные.

Минимальный список того, что нужно перебрать:

• SSH-доступ ко всем серверам (свой ключ, а не переиспользование чужого).
• Учётные записи в панелях управления хостингом и облачных консолях.
• Доступ к регистратору доменов и DNS-провайдеру, включая контакты для восстановления доступа.
• Учётка в системе выпуска SSL-сертификатов, если используется не только Let's Encrypt через автоматизацию.
• Менеджер паролей или хранилище секретов команды — со своим аккаунтом, а не через общий логин.
• Мониторинг и алертинг — кому приходят уведомления, кто в дежурном списке.
• CI/CD и репозитории кода.
• VPN и доступ к внутренней сети.
• Биллинг и платёжные аккаунты у провайдеров — как минимум просмотр, если полное управление не требуется по роли.

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

# добавляем ключ нового администратора
echo "ssh-ed25519 AAAA...новый-ключ admin-new@laptop" >> ~/.ssh/authorized_keys

# ключ прежнего администратора удаляем отдельной строкой,
# а не оставляем "на всякий случай"
sed -i '/admin-old@laptop/d' ~/.ssh/authorized_keys

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

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

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

Дни 5-6: новый администратор у руля, старый — на подхвате

Здесь происходит главная проверка того, насколько передача была реальной, а не формальной: новый администратор выполняет текущую работу сам, а прежний наблюдает и подключается только тогда, когда его действительно зовут — не садится за клавиатуру «чтобы было быстрее».

Практически это выглядит так:

• Все плановые задачи двух дней (обновления, деплой, рутинное обслуживание) выполняет новый администратор.
• Прежний администратор доступен для вопросов, но отвечает словами и подсказками, а не решает проблему за коллегу руками.
• Ведётся общий список открытых вопросов — не решённых с ходу, а требующих проверки или уточнения — и в конце каждого дня список разбирается вместе.

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

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

День 7: финальная проверка готовности и точка отсечения

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

• Новый администратор может самостоятельно выполнить ключевые операции (деплой, откат изменений, восстановление из бэкапа хотя бы для одного компонента) — без подсказок, только по документации и памяти.
• Все доступы, заведённые в четвёртый день, реально работают — это стоит проверить явно, а не полагаться на то, что «наверное, всё сработало».
• Общие или одолженные учётные данные заменены на персональные везде, где это было возможно.
• Список открытых вопросов из пятого-шестого дня закрыт или переведён в задачи с понятным следующим шагом.
• Доступы прежнего администратора запланированы к отзыву — сразу или в оговорённый короткий срок, но не бессрочно «на всякий случай».

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

Отдельно стоит сказать про случай, когда прежнего администратора увольняют не по его инициативе и доверия к нему в моменте уже нет — тогда логика частично меняется: доступы отзываются немедленно, в первые же минуты, а не в конце недели, и уже без него команда разбирается с пробелами в знаниях постфактум. Порядок действий для такого сценария — в статье про отзыв доступов уволенного сотрудника в первые 30 минут. Схема на неделю из этой статьи рассчитана на штатную, доброжелательную передачу — когда обе стороны заинтересованы, чтобы новый человек реально разобрался, а не просто расписался.

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