Меняем подрядчика: как забрать инфраструктуру и не встать на месяц

MAATRIX

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

Три риска, которые превращают смену подрядчика в простой

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

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

Разберём каждый риск отдельно и дадим план перехода, который снимает все три одновременно.

Риск №1: документация есть только в голове старого подрядчика

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

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

Минимальный комплект документации, который стоит получить от старого подрядчика ещё до официального расставания:

• список серверов и облачных ресурсов с назначением каждого;
• схема сети и зависимостей между сервисами (что от чего требует, что бьётся при падении чего);
• расположение и формат бэкапов, дата последней проверки восстановления;
• список автоматизаций — cron, systemd-таймеры, CI/CD пайплайны, вебхуки;
• перечень интеграций со сторонними сервисами (платёжные системы, email-рассылки, аналитика, CDN);
• known issues — то, что работает не идеально, но «руки не дошли исправить».

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

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

Риск №2: инфраструктура прописана на чужой аккаунт

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

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

Что физически нужно перенести, а не просто «получить доступ»:

По домену стоит отдельно проверить текущего держателя записи, прежде чем что-то планировать:

whois yourdomain.com | grep -iE "registrar|registrant|updated"

Если регистрант — не ваша компания, transfer домена потребует EPP/auth-код от текущего держателя и подтверждения по email. Закладывайте на это несколько дней — transfer не мгновенный, а некоторые TLD держат домен «залоченным» первые 60 дней после регистрации. Отдельная неприятность — оставшиеся у регистратора NS-записи прошлого подрядчика уже после смены: разбор похожего случая есть в статье «У регистратора остались NS прошлого подрядчика».

Для облачных провайдеров процедура обычно называется billing transfer и инициируется из панели биллинга — у AWS это перенос через AWS Organizations, у GitHub — Settings → Transfer ownership. Общий принцип один: ищите не «поделиться доступом», а именно «передать владение» — это разные функции даже в интерфейсах, и путать их вредно.

Риск №3: провал между уходом старой команды и погружением новой

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

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

Практический план перехода: четыре шага

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

Шаг 1. Инвентаризация и документирование до официального расставания.

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

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

Шаг 2. Период параллельной работы.

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

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

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

Шаг 3. Перенос владения критичными аккаунтами на аккаунты заказчика.

Ключевой принцип: аккаунты переносятся не старому подрядчику и не новому, а самому заказчику. Новый подрядчик получает доступ к аккаунтам заказчика, а не создаёт (и тем более не приносит) свои. Это снимает риск зависимости от конкретного исполнителя и упрощает следующую смену подрядчика, если она понадобится.

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

Шаг 4. Явная контрольная точка готовности.

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

Контрольная точка: как зафиксировать готовность взять на себя ответственность

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

[ ] Полный список серверов и сервисов подтверждён новой командой
[ ] Схема зависимостей проверена — новая команда объясняет её своими словами
[ ] Доступ к мониторингу и алертам настроен и протестирован
[ ] Хотя бы один инцидент (реальный или учебный) отработан новой командой
[ ] Процедура бэкапа и восстановления проверена силами новой команды
[ ] Все критичные аккаунты переоформлены на заказчика, доступы у нового
    подрядчика подтверждены рабочими (не просто выданы, а протестированы)
[ ] Контакты старого подрядчика на случай вопроса зафиксированы на
    оговорённый срок (например, две-четыре недели платных консультаций)
[ ] Обе стороны (заказчик и новый подрядчик) письменно подтверждают
    переход ответственности

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

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

Если параллельный период организовать не получается

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

• зафиксируйте письменно (email, а не только устно) все попытки получить доступы и документацию;
• сразу инициируйте перенос владения всем, до чего можете дотянуться самостоятельно — домен, платёжные аккаунты, там, где заказчик формально уже владелец;
• новому подрядчику придётся начинать с полноценного разбора незнакомой системы, методично, а не с попытки угадать логику прежней команды;
• закладывайте больше времени и, вероятно, больше бюджета на первые недели — реконструкция знания задним числом дороже его прямой передачи, и это стоит заранее обсудить с новым подрядчиком.

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

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