Менять подрядчика у работающей веб-системы — не то же самое, что передавать новый проект. Пока команды разбираются с кодом и доступами, через систему продолжают идти заказы, заявки, платежи и документы. Поставить её на паузу на неделю, чтобы новая команда освоилась, бизнес не может.
Код при этом можно передать за день. Настоящие проблемы обнаруживаются позже: во время первого сбоя, срочной доработки, продления сертификата или восстановления базы данных. Если без прежнего подрядчика новая команда не может собрать релиз, найти причину ошибки и вернуть систему в рабочее состояние, передача существует только на бумаге.
Начинать нужно с критичных процессов
В одной веб-системе могут одновременно работать оформление заказов, личный кабинет, внутренние справочники и отчётность. Но последствия сбоя у них разные. Если перестали оформляться заказы, компания сразу теряет выручку. Обновление внутреннего отчёта во многих случаях может подождать несколько часов или дней.
Поэтому до передачи определяют, какие пользовательские действия нельзя останавливать и какие модули, интеграции, фоновые задания и внешние сервисы обеспечивают их работу. Заодно договариваются, сколько может продлиться простой и какой объём данных допустимо потерять. В ИТ-документации эти ограничения обычно обозначают как RTO (время восстановления) и RPO (допустимый период потери данных).
Назначать одно значение для всей системы не верно. Заказы, платежи и уведомления могут требовать восстановления за минуты, а внутренняя статистика — за часы. Такая расстановка приоритетов особенно важна в первые недели: при сбое новая команда сразу понимает, какой процесс возвращать в работу первым.
Как выбрать сценарий передачи
Параллельная работа команд — самый надёжный вариант для критичной системы. На первом этапе новая команда наблюдает, как выпускаются обновления и разбираются инциденты, затем делает это сама под контролем прежней. Здесь важно заранее разделить ответственность. У каждого релиза и инцидента должен быть один владелец, иначе обе команды будут ждать действий друг от друга.
Поэтапная передача подходит, если систему можно разделить на относительно самостоятельные части. Например, сначала передать личный кабинет, затем интеграционный модуль и административную панель. Вместе с каждым модулем передают его зависимости, мониторинг и порядок поддержки. Один только код не поможет, если новая команда не видит, как модуль обменивается данными с соседними системами.
Экстренный переход приходится проводить, когда прежний подрядчик недоступен или есть риск потерять контроль над инфраструктурой. В этом случае сначала получают административные доступы, фиксируют текущее состояние системы, подключают мониторинг и проверяют резервные копии. Новые функции временно отходят на второй план: главная задача — вернуть систему под контроль.
Если в этот момент уже произошёл сбой, порядок ещё жёстче: сначала тушат пожар — локализуют проблему, восстанавливают критичный процесс и ограничивают ущерб. Полное обследование архитектуры и разбор причин проводят после стабилизации. Иначе время, потраченное на изучение системы, превращается в прямой убыток для заказчика.
При любом сценарии нужен отдельный план перехода. Дата окончания договора сама по себе ничего не говорит о готовности новой команды.
Вернуть заказчику контроль над системой
Самые неприятные сюрпризы часто находятся не в репозитории. Домен может быть зарегистрирован на сотрудника подрядчика, уведомления об ошибках — приходить только в его мессенджер, а сборка приложения — зависеть от файла на ноутбуке конкретного разработчика. Формально код уже у заказчика, но управлять системой без прежней команды он всё ещё не может.
Чтобы увидеть такие зависимости, составляют общий список ресурсов, от которых зависит система. В него входят репозитории, серверы и облачные аккаунты, домены и настройки DNS, базы данных, хранилища, сертификаты, лицензии, почтовые и СМС-сервисы. Для каждого ресурса указывают владельца, администраторов, способ восстановления доступа и срок оплаты или действия сертификата. Это может быть обычная таблица — сложная система учёта здесь не нужна.
Отдельно проверяют технические доступы: SSH-ключи, токены системы автоматической сборки и развёртывания (CI/CD), API-ключи и доступы к внешним сервисам. Новой команде выдают собственные права и проверяют, что они работают. Только после этого доступы прежнего подрядчика отзывают, а известные ему пароли, токены и ключи заменяют. Обратный порядок опасен: можно остановить интеграцию или лишиться единственного рабочего способа развернуть приложение.
Сам по себе список доступов ещё ничего не гарантирует. Новая команда должна собрать приложение в чистом окружении, развернуть тестовую версию, выпустить небольшое обновление и при необходимости вернуться к предыдущей версии. Такая проверка быстро находит то, чего нет в инструкциях: локальные файлы, закрытые библиотеки, ручные операции и пропущенные настройки.
То же относится к мониторингу и резервным копиям. Оповещения должны приходить новой команде. И команда должна уметь в них видеть не только техническую ошибку, но и её последствие: перестали создаваться заказы, не формируются документы, не обновляются статусы доставки. Резервной копии тоже нельзя доверять, пока данные из неё не восстановили в отдельной среде и не проверили. Заодно становится понятно реальное время восстановления, а не цифра из регламента.
Документацию нужно проверять в работе
Схема архитектуры и подробная инструкция полезны, но сами по себе ничего не доказывают. Документ может быть устаревшим, а важная операция — держаться на памяти одного специалиста. Поэтому знания передают через конкретные действия: новая команда пытается совершить действие и в случае проблем обращается к предыдущей.
Минимальная практическая проверка — разобраться со сбоем интеграции по логам, выпустить небольшое изменение, выполнить откат и восстановить данные из резервной копии. После каждого действия корректируют рабочую инструкцию: где начинать диагностику, какие показатели смотреть, кому сообщать о проблеме и когда принимать решение об откате.
Если прежний подрядчик в передаче не участвует, устройство системы приходится восстанавливать по истории изменений и задач, настройкам CI/CD, тестам, логам и прошлым инцидентам. До принятия обычных обязательств по поддержке новая команда проводит обследование и честно фиксирует, за что уже может отвечать, а где пока остаются неизвестные зависимости.
Но речь идёт о плановом переходе. Если критичная ситуация уже случилась, нельзя откладывать восстановление до момента полного понимания устройства системы. Сначала решают проблему, фиксирую предпринятые для восстановления шаги. Причину сбоя и устройство затронутых компонентов подробно разбирают уже после того, как ситуация перестала приносить бизнесу убытки.
Первый релиз новой команды
После обследования почти всегда появляется длинный список накопившихся проблем: устаревшие зависимости, ручные операции, нехватка тестов, пробелы в документации. Возникает желание сразу всё исправить. Для переходного периода это плохая стратегия: чем больше изменений вносится одновременно, тем труднее понять причину нового сбоя.
Сначала устраняют то, что угрожает данным и непрерывности работы: активные уязвимости, отсутствие резервного копирования, невозможность собрать или развернуть систему, отсутствие мониторинга и рабочего плана отката. Рефакторинг и архитектурные улучшения можно запланировать после стабилизации.
Первый релиз лучше сделать небольшим, но полноценным. Команда меняет код, проводит тестирование, выпускает обновление, проверяет его в рабочей среде и при необходимости откатывает. При этом задача не должна быть крупной, чтобы возможная ошибка не повлияла на работу всей системы.
Где переход чаще всего срывается
Чаще всего проблемы возникают из-за спешки. Договор с прежней командой уже завершён, а новая ещё не успела проверить, как система ведёт себя в работе. На переходном этапе новой команде не стоит сразу перестраивать систему и обещать прежний уровень поддержки. Крупные изменения усложнят поиск причин возможных сбоев, а гарантировать прежний уровень сервиса можно только после проверки всех процессов.
Поэтому передачу ответственности лучше отделить от больших изменений и предусмотреть время на стабилизацию. Это не означает, что развитие системы нужно полностью остановить. На переходном этапе можно выпускать небольшие изменения. Но крупные доработки, перестройку архитектуры и обновление ключевых компонентов лучше отложить. Если после них возникнет сбой, новой команде будет сложнее понять, связан он со старой проблемой или с внесёнными изменениями.
Нередко проблемы случаются из-за отсутствия плана и четкой фиксации детальных фактов передачи. Здесь новая команда может говорить, что она уже все приняла и эксплуатирует, а на деле оказывается, что некоторые компоненты системы не были должным образом приняты: артефакты по ним не были получены, детали не были уточнены и выяснены. Бизнес может не понимать, что для стабильной работы системы и снижения рисков требуется потратить достаточно времени и уделить достаточно внимания процессу передачи. Желание бизнеса поскорее поставить точку может обернуться спешкой на уровне технической эксплуатации и невнимательностью, что в итоге создает риски.
Когда переход действительно завершён
Окончание договора и фактическая передача системы редко совпадают день в день. Для критичной системы ориентироваться лучше не на дату в календаре, а на несколько проверяемых признаков:
— компания контролирует код, инфраструктуру, домены, данные и внешние сервисы;
— новая команда получает оповещения и может самостоятельно найти причину сбоя;
— проверены сборка, выпуск обновления и откат;
— данные успешно восстановлены из резервной копии, а время восстановления измерено;
— критичные пользовательские сценарии и интеграции работают;
— известные риски, временные ограничения и ответственные за них зафиксированы.
Если для диагностики, релиза или восстановления по-прежнему нужен специалист прежнего подрядчика, переход ещё не закончен. Подписанный акт этого не меняет.
Передача заканчивается не в момент получения архива с кодом и документацией. Она заканчивается тогда, когда новая команда может самостоятельно поддерживать систему, а бизнес больше не зависит от знаний, доступов и решений прежнего подрядчика.
