Смена подрядчика по инфраструктуре: как уйти без простоя и скандала

MAATRIX

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

Два риска, которые определяют качество смены подрядчика

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

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

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

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

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

Когда и как уведомить старого подрядчика

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

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

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

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

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

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

Параллельная подготовка с новым подрядчиком, пока старый ещё на связи

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

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

Параллельная работа на этапе подготовки означает конкретно следующее:

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

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

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

Точка перехода ответственности: где заканчивается неопределённость

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

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

Практический формат — короткое письмо-подтверждение по итогам финального созвона трёх сторон (или переписки, если созвон организовать не удаётся):

Дата и время перехода ответственности: [дата, время, часовой пояс]

До этого момента: инциденты обрабатывает [старый подрядчик],
контакт для эскалации — [телефон/канал].

После этого момента: инциденты обрабатывает [новый подрядчик],
контакт для эскалации — [телефон/канал].

Старый подрядчик подтверждает готовность передать систему.
Новый подрядчик подтверждает готовность принять систему.
Заказчик подтверждает согласие с датой перехода.

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

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

Как не допустить простоя в момент переключения

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

В контексте смены подрядчика на практике это обычно выглядит так:

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

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

Профессиональная этика расставания и почему она технически выгодна

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

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

Несколько практических принципов, которые снижают риск конфликта:

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

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

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