Что произошло
Переход на отечественный стек — базы данных, операционные системы, платформы виртуализации, прикладные системы — из отдельных проектов превратился в поток. Сроки заданы: для значимых объектов КИИ — 1 января 2028 года, для остальных категорий — внутренними планами и требованиями отраслевых регуляторов.
Планы упираются в два ограничителя, которые в бюджетах и дорожных картах обычно не видны. Первый — люди. Миграция требует инженеров с конкретными компетенциями, и этих инженеров на рынке меньше, чем открытых позиций. Второй — реальная стоимость переноса, которая складывается не из лицензий, а из переписывания, тестирования, параллельной эксплуатации и нагрузочных испытаний. Оба ограничителя связаны: недооценка стоимости переноса — это, как правило, недооценка человеко-месяцев, а человеко-месяцы негде взять.
По нашему опыту проектов, срывы миграций редко происходят из-за технологий. Отечественные СУБД и платформы работают. Срывы происходят из-за того, что в нужный момент нет человека с нужной компетенцией, или из-за того, что первый серьёзный нагрузочный тест проводится на продуктиве.
Анатомия проблемы
Какие компетенции в дефиците
Дефицит неравномерный. Разработчиков общего профиля на рынке достаточно. Не хватает тех, кто умеет делать конкретные вещи, которые при миграции критичны.
| Компетенция | Что требуется при миграции | Почему в дефиците |
|---|---|---|
| PostgreSQL | Перенос схем и хранимого кода с Oracle и MS SQL, репликация, секционирование, оптимизация запросов под другой планировщик | Опыт эксплуатации под высокой нагрузкой нарабатывается годами, а спрос вырос за короткий срок |
| Архитекторы 1С | Проектирование кластера, перенос на PostgreSQL, оптимизация конфигураций, интеграции при большом числе пользователей | Большинство специалистов 1С — прикладные разработчики, а не архитекторы |
| Интеграции | Перенос обменов между системами, шины, Kafka, API, форматы, гарантии доставки | Требуется понимание нескольких систем одновременно, а не одной |
| DevOps и инфраструктура | Linux, отечественные ОС, контейнеризация, CI/CD, мониторинг, инфраструктура как код | Спрос от всех отраслей одновременно, конкуренция с продуктовыми компаниями |
| Миграция данных | Конвертация, выверка, сверка на объёмах, откат | Компетенция проектная, вне миграций не востребована, поэтому не накапливается |
| Нагрузочное тестирование | Сценарии, генерация нагрузки, профилирование, интерпретация результатов | Отдельная дисциплина, в штате большинства компаний отсутствует |
Особенность в том, что миграции нужны все эти компетенции в определённой последовательности и на ограниченное время. Компании нужен архитектор PostgreSQL на этапе проектирования и на этапе нагрузочных испытаний, а между ними — нет. Держать его в штате круглый год дорого, нанять на два месяца — невозможно.
Почему найм не решает
Найм — естественная первая реакция, и она не работает по четырём причинам.
Время закрытия позиции по дефицитным специальностям измеряется месяцами. После выхода специалист адаптируется к ландшафту — ещё месяцы до полной продуктивности. Если миграция запланирована на год, найм съедает половину срока.
Вторая причина — профиль потребности. На пике миграции нужно несколько специалистов одной компетенции, после миграции — один или ни одного. Нанимать под пик означает после пика содержать людей, для которых нет работы, или увольнять их.
Третья — конкуренция: все компании, попадающие под одни и те же сроки, ищут одних и тех же инженеров одновременно, что поднимает зарплатные ожидания и снижает вероятность найма для каждого.
Четвёртая — риск концентрации. Один нанятый архитектор — это один человек, который может заболеть, уйти или ошибиться. Без дублирования компетенции проект зависит от его присутствия.
Из чего складывается стоимость миграции
В бюджет обычно попадают лицензии, оборудование и договор с подрядчиком. Не попадает то, что определяет реальную стоимость:
- Переписывание хранимого кода. Процедуры, триггеры, пакеты, написанные под одну СУБД, не переносятся автоматически. Их надо переписать и проверить на эквивалентность результата.
- Тестирование. Функциональное — всех сценариев, которые затрагивает система. Регрессионное — после каждого исправления. Нагрузочное — на объёмах и профиле продуктива.
- Параллельная эксплуатация. Период, когда работают обе системы, данные сверяются, а расхождения разбираются. Это удвоенная нагрузка на эксплуатацию.
- Конвертация и выверка данных. Объёмы, накопленные за годы, содержат аномалии, о которых никто не помнит. Каждая — задержка.
- Знание старой системы. Люди, которые понимают, почему она устроена именно так, часто уже не в компании. Восстановление этого знания — работа.
Каждый из этих пунктов — человеко-месяцы. Их сумма обычно в разы больше оценки, полученной по аналогии с «установкой новой версии».
Пилоты и нагрузочные испытания
Отечественный стек ведёт себя иначе, чем замещаемый, — не хуже, а иначе. Планировщик запросов PostgreSQL принимает другие решения, чем планировщик Oracle. Кластер 1С на PostgreSQL требует других настроек, чем на MS SQL. Отечественная ОС имеет другие настройки по умолчанию. Всё это проявляется под нагрузкой, а не на тестовых данных.
Пилот — миграция ограниченного, но реального фрагмента: одна подсистема, реальные данные, реальные пользователи, реальные интеграции. Его цель — не доказать, что миграция возможна, а найти, где она ломается, пока это дёшево. Критерии выхода из пилота формулируются заранее: время отклика ключевых операций, корректность сверки, отсутствие блокирующих дефектов.
Нагрузочные испытания — воспроизведение продуктивного профиля на целевом стенде: число пользователей, объём данных, пиковые периоды, фоновые задания. Без них первый пик нагрузки — закрытие месяца, отчётная дата, сезон продаж — становится испытанием на продуктиве.
Оба этапа требуют людей — и оба в планах, составленных «по бюджету», обычно ужимаются первыми.
Усиление команды внешними инженерами
Альтернатива найму — не классический аутсорсинг с передачей проекта наружу, а усиление своей команды инженерами, которые работают в процессах заказчика. При аутсорсинге результат приходит снаружи, а знание остаётся у подрядчика; при усилении инженер работает в контуре заказчика, в его задачах и с его командой, и знание оседает внутри.
Три механизма, которые делают такую модель рабочей:
- Время и материалы в процессах заказчика. Инженер включён в команду заказчика, участвует в планировании, работает по его регламентам и в его инструментах. Оплата — по фактическому времени. Заказчик управляет приоритетами, а не согласует техническое задание.
- Дублирование компетенций. На каждую критичную роль — два человека, один из которых может быть внешним, а второй — сотрудник заказчика, который перенимает практику. Уход любого из них не останавливает проект.
- Центр компетенций за инженером. Внешний инженер не один: за ним команда, к которой он обращается с нестандартными задачами. Заказчик получает не одного человека, а доступ к накопленному опыту, при этом платит за одного.
Ключевое условие — результат работы остаётся у заказчика: код, конфигурации, документация, обученные люди. Если этого условия нет, усиление превращается в зависимость.
Миграция планируется не по бюджету и не по датам, а по людям: кто именно, с какой компетенцией и в какие недели будет доступен.
Как это выглядит на практике
Производственная компания, миграция с Oracle на PostgreSQL. План был составлен по датам, с расчётом на штатных администраторов баз данных, которые знали Oracle, а PostgreSQL — по курсам. Вскоре после старта стало ясно, что переписывание хранимого кода идёт в разы медленнее плана, а опыта оптимизации запросов под новый планировщик нет. Позицию архитектора PostgreSQL открыли, за квартал закрыть не удалось. Проект перепланировали: внешний архитектор вошёл в команду на условиях времени и материалов, штатные администраторы работали с ним в паре. Миграцию завершили с задержкой, но с командой, которая после этого сопровождала систему самостоятельно.
Банк из первой сотни, кластер 1С. Перенос на PostgreSQL с обязательными нагрузочными испытаниями по внутреннему регламенту. Специалистов по нагрузочному тестированию в штате не было, подрядчик по 1С предложил «протестировать на реальных пользователях в выходные». Банк привлёк внешних инженеров на несколько недель: они построили стенд и сценарии и обучили сотрудников их поддерживать. Испытания выявили проблему с блокировками, которая на продуктиве проявилась бы в первую отчётную дату.
Сеть клиник, интеграции. Замена медицинской информационной системы затронула обмены с лабораториями, страховыми и порталом записи, а интеграционных инженеров, знакомых с этими форматами, в штате не было. Команду усилили внешним интеграционным инженером в паре со штатным разработчиком, а интеграции вынесли в отдельный слой на стандартных протоколах, чтобы следующая замена не требовала повторной работы.
Что это значит для российской компании
Сроки фиксированы, и ждать, пока рынок насытится специалистами, не получится. Компании, которые начнут поиск людей за год до дедлайна, будут конкурировать со всеми остальными, кто начнёт в то же время.
Закрытый контур — требование, а не пожелание. Инженеры, которые усиливают команду, работают внутри периметра: с доступом по регламенту заказчика, на его рабочих местах или через защищённые виртуальные рабочие столы, без выноса данных. Это сужает выбор подрядчиков, но защищает заказчика: результат физически остаётся у него.
Распределённые команды — реальность рынка: инженеры с нужными компетенциями работают из России, Армении, Казахстана. Это расширяет доступный пул людей, но требует организационных решений: правила доступа для работающих из-за пределов страны, соответствие 152-ФЗ при обработке персональных данных, требования по допуску к изолированным сетям для субъектов КИИ. По нашему опыту, рабочая схема — распределённая команда для проектирования, разработки и тестирования на обезличенных данных, и сотрудники внутри контура для работы с продуктивом. Схему нужно согласовать с безопасностью до старта, а не в момент, когда инженер уже нужен.
Кадровый вопрос имеет и долгосрочную сторону: после миграции систему нужно сопровождать. Если все компетенции по ней у внешних людей, компания меняет зависимость от иностранного вендора на зависимость от подрядчика. Поэтому усиление команды с первого дня включает передачу знаний: пары, документацию, участие штатных сотрудников в каждом этапе.
Что делать: пошагово
- Составьте перечень систем и разбейте на волны. По срокам, по зависимостям, по критичности. Для каждой волны — перечень работ: проектирование, перенос, тестирование, нагрузочные испытания, параллельная эксплуатация, передача в сопровождение.
- Составьте карту компетенций по волнам. Для каждой работы — какие компетенции нужны и в каком объёме, в человеко-неделях. Не «команда разработки», а «архитектор PostgreSQL — четыре недели на проектирование, три недели на нагрузочные испытания».
- Заполните карту поимённо. Напротив каждой компетенции — конкретный человек и даты его доступности. Не «найдём», а фамилия. Пустые ячейки — это и есть ваш реальный план.
- Проведите анализ разрывов. Где пусто, где один человек на две волны одновременно, где критичная роль без дублёра. Это точки, в которых миграция сорвётся, если ничего не изменить.
- Закройте разрывы тремя способами параллельно. Обучение своих сотрудников с прицелом на сопровождение, усиление внешними инженерами на пиковые периоды, дублирование критичных ролей парой «внешний плюс штатный».
- Включите пилот и нагрузочные испытания в план как обязательные этапы. С людьми, стендом, критериями выхода и датами. Их нельзя сокращать при отставании графика — они и есть защита от срыва.
- Заложите резерв по людям. На любой миграции возникает работа, которой не было в плане: аномалии в данных, недокументированные интеграции, устаревшие зависимости.
- Зафиксируйте передачу знаний как результат. Документация, обученные сотрудники, воспроизводимое развёртывание — в критериях приёмки каждого этапа, а не в конце проекта.
Форма, с которой мы начинаем планирование, выглядит просто:
| Волна | Работа | Компетенция | Объём, недели | Кто | Даты | Дублёр |
|---|---|---|---|---|---|---|
| 1 | Проектирование целевой схемы | Архитектор PostgreSQL | по оценке | фамилия или пусто | с — по | фамилия или пусто |
| 1 | Нагрузочные испытания | Инженер по нагрузке | по оценке | фамилия или пусто | с — по | фамилия или пусто |
Число пустых ячеек в столбцах «Кто» и «Дублёр» — единственная честная оценка готовности к миграции.
Типичные ошибки
- План по бюджету и датам без людей. Почему плохо: бюджет и даты не выполняют работу. Что вместо: поимённый план с датами доступности, пустые ячейки — как риски в реестре проекта.
- Расчёт на найм под пик. Почему плохо: позиции закрываются месяцами, после пика люди не нужны. Что вместо: штат — под сопровождение, усиление — под пик.
- Аутсорсинг миграции целиком. Почему плохо: знание остаётся у подрядчика, а сопровождать систему придётся вам. Что вместо: усиление своей команды в своих процессах с передачей знаний.
- Сокращение нагрузочных испытаний при отставании. Почему плохо: первый пик нагрузки на продуктиве обойдётся дороже любого испытания. Что вместо: сокращать объём волны, а не проверки.
- Один человек на критичную компетенцию. Почему плохо: его отсутствие останавливает проект. Что вместо: дублирование парой, участие штатного сотрудника.
Как понять, что вы на верном пути
- Для каждой волны миграции существует поимённый список людей с датами и компетенциями, и он пересматривается ежемесячно.
- Каждая критичная роль дублирована, и как минимум один из пары — сотрудник компании.
- Пилот на реальных данных проведён до основной миграции, и его результаты изменили план.
- Нагрузочные испытания проведены на профиле продуктива, и их критерии выхода выполнены.
- Внешние инженеры работают в ваших процессах, инструментах и репозиториях, а не присылают результат.
- Штатные сотрудники могут объяснить, как устроена мигрированная система, без обращения к подрядчику.
- Правила работы распределённой команды согласованы с безопасностью до старта.
Вопросы, которые нам задают
Не дороже ли внешние инженеры, чем свои сотрудники? В расчёте на час — дороже. В расчёте на проект — обычно нет: внешний инженер нужен на пиковые недели, а штатный — на весь год, включая месяцы без задач по этой компетенции. Кроме того, внешний инженер с опытом нескольких миграций проходит типовые проблемы быстрее.
Как не попасть в зависимость от подрядчика? Три условия в договоре: работа в ваших репозиториях и инструментах, обязательная пара со штатным сотрудником на каждой критичной роли, передача знаний как критерий приёмки этапа. Если подрядчик не готов их принять, это ответ на вопрос о зависимости.
Можно ли использовать распределённую команду для субъекта КИИ? Для работ с продуктивом и изолированными сетями — нет, там требуется допуск и работа в контуре. Для проектирования, разработки и тестирования на обезличенных данных — как правило, да, при согласовании с безопасностью и соблюдении 152-ФЗ. Разделение работ на две зоны нужно спроектировать до формирования команды.
Начните с таблицы: волны, работы, компетенции, фамилии, даты. Заполните её честно, с пустыми ячейками там, где людей нет. Количество пустых ячеек — это и есть срок, на который сдвинется миграция, если не начать закрывать их сейчас.