Передача инфраструктуры от одной команды другой: план на две недели

MAATRIX

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

Чем передача между командами отличается от смены подрядчика

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

Передача между двумя внутренними командами устроена иначе, и именно эта разница создаёт специфический риск:

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

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

Неделя 1: погружение и инвентаризация, а не захват власти

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

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

Что входит в первую неделю:

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

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

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

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

Неделя 2: постепенная передача ответственности

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

Логика второй недели такая:

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

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

Финальная контрольная точка

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

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

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

Почему именно две недели — а не три дня и не полтора месяца

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

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

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

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

Главное правило: зафиксировать точный момент перехода

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

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

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

Табличная форма для дежурства на переходный период помогает снять двусмысленность лучше любых формулировок:

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

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