Что спросить у прошлого админа, пока он ещё отвечает на сообщения

MAATRIX

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

Почему это окно закрывается быстрее, чем кажется

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

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

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

Нестандартные настройки: спрашивайте не «что», а «почему не как обычно»

Самая ценная информация — не список сервисов (его можно восстановить самому за час-два), а причины отклонений от стандартной конфигурации. За каждым нестандартным решением обычно стоит инцидент, ограничение хостинга или требование клиента, которое новому человеку неочевидно, и он рискует «починить» то, что на самом деле было исправлением, а не багом.

Конкретные вопросы для этого блока:

• «Есть ли места, где вы сознательно отошли от дефолтной конфигурации — и почему?» Например, нестандартный SSH-порт, отключённый systemd-юнит, изменённые лимиты в sysctl.conf, кастомный nginx.conf вместо конфига из коробки панели.
• «Правило в firewall/iptables, назначение которого не читается из комментария — зачем оно?» Часто такие правила добавляют под конкретный инцидент (DDoS с определённой подсети, сбойный клиент API) и забывают закомментировать причину.
• «Есть ли cron-задачи или systemd-таймеры, которые выглядят избыточными, но на самом деле критичны?» Скрипт, который перезапускает сервис раз в ночь — это костыль под утечку памяти или что-то другое?
• «Почему выбран именно этот стек/версия ПО, а не более свежая или более распространённая?» Иногда версия зафиксирована из-за несовместимости с внешней интеграцией, и апгрейд без понимания причины сломает что-то незаметное.
• «Есть ли переменные окружения или флаги в конфигах приложения, которые включают нестандартное поведение?» Например, отключённая валидация на конкретном эндпоинте — временное решение под нагрузку, о котором все забыли.
• «Какие изменения вы вносили под конкретного клиента или заказчика вручную, в обход общего процесса деплоя?» Ручные правки в проде — самая частая причина расхождения между тем, что в git, и тем, что реально работает.

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

Контакты сторонних сервисов и особые договорённости

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

Что стоит спросить:

• «С какими провайдерами и сервисами вы взаимодействовали напрямую — не через тикет-систему, а лично?» Часто это регистратор домена, CDN, платёжный шлюз, SMS-агрегатор.
• «Есть ли у кого-то из провайдеров персональные договорённости — скидка, отсрочка оплаты, приоритетная поддержка — которые привязаны к вам лично, а не к юрлицу?» Такие договорённости иногда исчезают вместе с уходом человека, если о них никто не знает и не переоформляет.
• «На кого зарегистрированы аккаунты у сторонних сервисов — на компанию, на вас лично или на старый email, к которому уже нет доступа?» Это критично для доменов, SSL-сертификатов, аккаунтов в панелях мониторинга.
• «Кому вы звонили или писали в первую очередь при инциденте — саппорту по SLA или конкретному человеку в обход очереди?» Личный контакт инженера поддержки — не всегда воспроизводимая вещь, но полезно знать, что он существовал.
• «Есть ли активные NDA, договоры или устные договорённости с подрядчиками, о которых стоит знать преемнику?» Особенно если через администратора проходили доступы третьих лиц — фрилансеров, аутсорс-команд.
• «Какие сервисы оплачиваются с личной карты или личного аккаунта администратора, а не с корпоративного?» Это неприятный, но частый случай — SaaS-подписка на 5-10 долларов в месяц, заведённая «на скорую руку» и так и оставшаяся личной.

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

Известные, но не решённые проблемы — технический долг из первых уст

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

Вопросы, которые стоит задать:

• «Что из списка "давно пора починить" вы бы назвали в первую очередь?» Открытый, но конкретный вопрос — без него список может не появиться вообще, люди редко вспоминают техдолг сами по себе.
• «Есть ли сервисы или серверы, которые работают на версиях ПО с истёкшей поддержкой?» Это прямой риск безопасности, и часто он висит годами именно потому, что обновление ломает что-то ещё.
• «Какие компоненты держатся на честном слове — без резервирования, без мониторинга, без алертов?» Один сервер без реплики, один cron без логирования падений — то, что работает, пока не сломается.
• «Были ли инциденты, которые не попали в постмортем или вообще нигде не зафиксированы?» Устная история инцидентов — часто единственный источник понимания, почему система ведёт себя именно так.
• «Что вы бы сделали иначе, если бы начинали проект заново?» Формулировка провоцирует честный ответ лучше, чем прямой вопрос «в чём вы накосячили».
• «Есть ли зависимости от конкретных людей — "если Х заболеет, никто не знает, как перезапустить Y"?» Это не техническая, а организационная брешь, но её тоже стоит закрыть.

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

Где лежит то, что не видно с первого взгляда

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

Вопросы для этого блока:

• «Где физически или логически хранятся бэкапы — все, включая те, что не по основному регламенту?» Частый случай: официальный бэкап настроен на один сервис, а ещё есть ручной архив на личном облаке или отдельном диске, о котором знает только сам администратор.
• «Есть ли тестовые или staging-окружения, которые не значатся в общем списке серверов?» Заброшенный тестовый VPS, который когда-то подняли под конкретную задачу и забыли выключить — типичная находка при аудите.
• «Использовались ли снапшоты или образы дисков как форма бэкапа, и где они хранятся?» Снапшот на стороне провайдера — это не то же самое, что резервная копия в отдельном хранилище, и про это стоит знать явно.
• «Есть ли доступы, которые не входят в общий список — например, аккаунт у другого хостинга, оставшийся с предыдущего этапа проекта?» После миграций часто остаются "хвосты" у старого провайдера, за которые продолжают тихо списывать деньги.
• «Где хранятся секреты — API-ключи, сертификаты, мастер-пароли — если не в общем менеджере паролей?» Личный менеджер паролей, файл на рабочем столе, заметка в телефоне — реальные, хоть и не идеальные, места хранения.
• «Есть ли документация, которая существует, но не в общем хранилище — личные заметки, черновики схем, переписка с провайдером с деталями настройки?» Даже неструктурированные заметки лучше, чем ничего, если знать, что их искать.

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

Формат разговора: структурированный созвон вместо «расскажи всё, что знаешь»

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

Практический подход:

1. Подготовьте список вопросов заранее, по блокам из этой статьи — не более 15-20 пунктов на один созвон, иначе разговор растянется и устанет обе стороны.
2. Назначьте конкретное время на 45-60 минут, а не «как будет свободная минутка» — открытая формулировка обычно означает, что минутка не найдётся никогда.
3. Запишите звонок (с согласия собеседника) или ведите текстовый протокол прямо во время разговора — потом легко забыть детали, особенно технические.
4. Идите по списку последовательно, но не бойтесь отклоняться, если ответ порождает новый уточняющий вопрос — самые ценные детали часто всплывают именно в отступлениях от плана.
5. Если созвон невозможен (человек уже недоступен голосом, только текст) — задавайте вопросы по одному блоку в сообщении, а не всё разом одним полотном текста: на короткое сообщение отвечают быстрее и подробнее.
6. После разговора пришлите короткое резюме — «правильно ли я понял, что...» — это не формальность, а способ поймать ошибки интерпретации, пока человек ещё готов поправить.

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

Тон разговора: вежливость окупается даже при неидеальном расставании

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

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

Практически это означает:

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

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

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