Как передать IT-проект новому подрядчику без остановки бизнеса
Передача проекта новому подрядчику возможна без остановки бизнеса, если заранее провести инвентаризацию артефактов, документировать текущее состояние, выстроить доступы и канал коммуникации, прогнать контролируемые тестовые переходы и зафиксировать SLA/критерии приёма. Ключ — план перехода с контрольными точками, резервным сопровождением и ясными критериями приёма работ, а также четкое распределение ответственности.
Почему смена подрядчика — это не просто “копировать код”
Смена подрядчика — это не только передача репозитория. На риске простоя сказываются отсутствие документации, незакрытые права доступа, различия в процессах CI/CD, и незнакомая операционная модель. Часто существенная часть знаний живёт в голове команды исполнителя, а не в артефактах. Успешный переход снижает эти риски за счёт систематической подготовки, постепенной передачи полномочий и тестовых «шагов», которые проверяют обслуживание в реальных условиях.
Основные этапы передачи проекта
- Подготовка и аудит состояния проекта
- Инвентаризация артефактов и прав доступа
- План перехода с контрольными точками (cutover plan)
- Тестовый переход и работа в параллели
- Приёмка и закрытие перехода
Ниже — подробная разбивка по шагам и практические шаблоны.
Что собрать перед передачей — таблица инвентаря артефактов
| Категория | Что включить | Ответственный |
|---|---|---|
| Код и версии | Репозитории, ветки, инструкции по релизам, версии зависимостей | Текущий подрядчик |
| CI/CD и сборки | Скрипты сборки, пайплайны, аккаунты CI, переменные окружения | DevOps |
| Инфраструктура | IaC (Terraform/CloudFormation), схемы, доступы к облаку/VM | Инфраструктурный инженер |
| Документация | Архитектурные схемы, архитектурные решения, открытые баги, backlog | Тимлид/PO |
| Безопасность | Секреты, ключи, политики доступа, аудит логов | IT‑безопасность |
| Контракты и SLA | Текущие SLA, обязательства при поддержке, лицензии | Юр./PM |
Эта таблица — минимальный чеклист; для сложных систем нужно расширять.
Как выстроить доступы и права
Практическая стратегия:
- Создать временные аккаунты с минимально достаточными правами; поэтапно повышать привилегии.
- Передать доступы через централизованный менеджер секретов (Vault, AWS Secrets Manager) вместо пересылки ключей по почте.
- Протоколировать изменения в IAM и держать аудит доступа.
Техническое требование: обеспечить отображаемость изменений в CI/CD и инфраструктуре, чтобы можно было откатиться и восстановить предыдущую конфигурацию.
План перехода (cutover plan) — ключевые контрольные точки
| Фаза | Длительность (пример) | Контрольные точки |
|---|---|---|
| Подготовка | 1–2 недели | Полный инвентарь, временные доступы созданы |
| Параллельная эксплуатация | 2–4 недели | Новый подрядчик выполняет инциденты, тестовые релизы |
| Тестовый cutover | 1 день (выход в окно) | Релиз в тестовую среду, нагрузочное тестирование |
| Производственный cutover | окно 0–6 часов | Переключение трафика, мониторинг, быстрый откат |
| Приёмка и закрытие | 1 неделя | Финальные проверки, передача знаний, закрытие прав |
Продолжительность зависит от масштаба проекта; таблица служит как шаблон для адаптации.
Роли и обязанности при переходе
- Заказчик (Business Owner): утверждение окон переключения и критериев доступности.
- Текущий подрядчик: передача знаний, сопровождение в ранний период.
- Новый подрядчик: настройка окружений, тесты, приёмка.
- DevOps/Infra: организация CI/CD, мониторинга, организации отката.
- Команда безопасности: проверка секретов и соответствия политик.
Чёткое разграничение ответственности снижает неоднозначности в критические часы.
Решение о параллельной работе vs. "big bang" — таблица сравнения
| Критерий | Параллельная работа | "Big bang" (одна миграция) |
|---|---|---|
| Риск простоя | Низкий — постепенная передача | Высокий — одно окно риска |
| Требования ресурсов | Выше — работа двух команд | Ниже — одна миграция |
| Время на обучение | Позволяет наработать опыт | Требует подготовки заранее |
| Сложность координации | Высокая (синхронизация) | Меньше на координацию, но больше на планирование |
| Подходит для | Критичных сервисов, низкой терпимости к простоям | Небольших модулей, слабо нагруженных систем |
Торговля между безопасностью и скоростью — ключ при выборе стратегии.
Практический чеклист для передачи (решающее руководство)
- Провести полный аудит артефактов и зависимостей.
- Составить матрицу доступов и инициировать временные учётные записи.
- Зафиксировать SLA, RTO/RPO, уровни приоритетов инцидентов.
- Подготовить тестовую среду, отражающую production (или схему Canary).
- Провести серию тестовых релизов новым подрядчиком в тестовом окружении.
- Организовать пару «остановочных окон» для учётных переключений.
- Выполнить production cutover с мониторингом и планом отката.
- Формализовать приёмку с подписями и закрыть старые доступы.
- Провести ретроспективу и документировать найденные проблемы.
Этот чеклист применим в большинстве реалистичных сценариев; при необходимости его расширяют под специфику проекта.
Гипотетический пример (реалистичный и четко обозначенный как гипотетический)
Компания A поддерживает интернет-магазин и решает сменить подрядчика на этапе масштабирования. Текущее окружение: микросервисы в Kubernetes, GitLab CI, PostgreSQL в облаке.
План передачи:
- Неделя 0–1: Инвентаризация репозиториев, пайплайнов, секретов; создание временных read-only аккаунтов для нового подрядчика.
- Неделя 2–3: Новый подрядчик разворачивает стенд, прогоняет интеграционные тесты, выполняет статический анализ кода и смоделированные релизы.
- Неделя 4: Параллельная эксплуатация — новый подрядчик берёт на себя обработку инцидентов класса P3, текущий подрядчик остаётся на связи.
- Образцовый cutover: окно 02:00–04:00, переключение трафика на новую версию через Kubernetes ingress + изменение DNS с коротким TTL; мониторинг метрик и алерты на 30 минут без ухудшения SLA.
- Пост‑cutover: 72 часа сопровождения новым подрядчиком; по истечении — закрытие старых доступов.
Преимущества: минимальный риск простоя, время на накопление знаний у нового подрядчика. Торговля: дополнительные временные затраты на параллельную работу и расходы на поддержание двух окружений.
Контроль качества и критерии приёма
Критерии приёма должны быть количественными и реализуемыми:
- Успешный прогон smoke tests в production‑парадигме.
- Удержание ключевых показателей (латентность, error rate) в пределах допустимых значений.
- Отсутствие регресcий в критичных функциональностях.
- Передача документации и закрытие открытых задач по миграции.
Фиксируйте критерии в контракте и подпишите акт приёма.
CTA (контекстный призыв к действию)
Если вам нужна помощь с аудитом и планированием безопасного перехода подрядчика, рассмотрите варианты сотрудничества и консультации — начните с просмотра услуги Piplos Media или примеров выполненных работ в портфолио Piplos Media.
FAQ
Q: Сколько времени обычно занимает передача проекта? A: Зависит от масштаба и зрелости проекта. Небольшие проекты — от нескольких недель; крупные системы с критичными SLA — месяцы. Главное — качество подготовки, а не скорость.
Q: Нужно ли сохранять старого подрядчика в роли консультанта после передачи? A: В большинстве случаев разумно иметь период трансферного сопровождения (2–8 недель) для передачи tacit knowledge. Это снижает риск и помогает ускорить адаптацию.
Q: Как организовать откат при неудачном cutover? A: План отката должен быть заранее отрепетирован: сохраненные образы/бэкапы, шаги переключения DNS или балансировщика, механизм автоматизированного деплоя предыдущей версии. Отработка отката в тестовой среде критична.
Q: Какие ошибки чаще всего приводят к простоям при передаче? A: Отсутствие актуальной документации, незадокументированные секреты/доступы, недостаточное тестирование в приближенном к production окружении и отсутствие чёткой ответственности.
