Миграция «Ы» и другие приключения бизнеса
НазадКак пройти через миграцию, не останавливая операционную деятельность? Почему нужно следовать технике малых шагов, зачем нужны контрольные точки и в каком случае жать пресловутую "красную кнопку"? Эксперты крупных ИТ-компаний поделились с IT-World рецептами гладкой миграции.
Еще Лев Толстой в солдатской песне описал ситуацию, когда «гладко было на бумаге, да забыли про овраги». На фронтах ИТ эти «овраги» имеют свойство обрушивать продажи, останавливать заводы и превращать финансовую отчетность в лотерею. Миграция корпоративных систем перестала быть просто техническим мероприятием. Теперь это хирургическая операция на работающем организме, где каждое неверное движение может отправить бизнес в кому.
Если раньше вопрос ставился «как бы это сделать быстро», то теперь более актуален вопрос «как бы это сделать безопасно». И эта смена приоритетов меняет все. Начиная с выбора стратегии и заканчивая распределением бюджетов. За последние два десятилетия российский бизнес пережил несколько волн миграций, но каждая новая оказывается сложнее предыдущей. Почему?
Меж двух огней
Главная дилемма любой миграции состоит в поиске компромисса в неразрешимом противоречии между скоростью и безопасностью. Руководство хочет «быстро и дешево», ИТ-службе подавай «безопасно и надежно», а реальность требует «и то, и другое, и чтобы вчера».
Классический «большой взрыв», как иногда описывают одномоментный переход на новую систему, сегодня считается неприемлемым для большинства проектов. Этот подход, по мнению экспертов, можно оправдывать либо безумством храбрых, либо наивностью.
Эксперт предлагает альтернативный подход с параллельным запуском, или так называемый Greenfield, предполагающий создание новой инфраструктуры «с нуля», работающей бок о бок со старой. Этот подход минимизирует риски, но в то же время требует удвоенных ресурсов и может растягиваться на годы. Успех здесь напрямую зависит от того, насколько близки по своей сути технологии старой и новой систем. Переезд с Windows на Linux, например, означает, что привычные автоматические механизмы, такие как балансировка, дедупликация, управление памятью, придется настраивать заново. Причем вручную.
Третий путь предполагает поэтапную миграцию по функциональным блокам, когда на новую систему переводится, например, бухгалтерия, потом склад, затем продажи. Это позволяет быстрее увидеть результаты, но порождает проблему стыковки решений. Пока одни процессы работают в новой системе, другие остаются в старой, и интерфейсы между ними приходится дорабатывать на лету.
Ключевая ошибка здесь состоит в выборе непроверенной стратегии без предварительного аудита. Многие компании начинают с выбора новой платформы, хотя должны начинать с инвентаризации того, что уже есть.
Невидимая инфраструктура
Одна из самых коварных ловушек миграции, по словам экспертов, — это так называемые «невидимые» компоненты, которые годами накапливались в старой системе и стали для бизнеса воздухом. Их не видно, но они жизненно необходимы для нормальной работы. Это автоматические балансировщики, встроенные механизмы дедупликации, кастомные скрипты мониторинга, недокументированные интеграции между подразделениями.
В новой системе всего этого нет. И внезапно выясняется, что привычные процессы либо замедляются, либо требуют ручного труда.
Особенно остро эта проблема стоит при смене технологического стека. То, что в старой ОС работало автоматически, в новой требует настройки, тестирования и постоянного мониторинга. Эти работы практически никогда не закладываются в бюджет миграции. Их обнаруживают уже в процессе, когда время и деньги на исходе.
По мнению Максима, привычные ранее компоненты ИТ-инфраструктур содержат значительное количество автоматизированных встроенных компонентов, отсутствие которых в новых решениях приводит к потере управляемости.
Человеческий фактор
Технические проблемы миграции, по словам экспертов, — это лишь половина беды. Вторую половину составляет уже пресловутый человеческий фактор. Попросту говоря, те самые люди, которые эту миграцию делают. И те самые человеки, которые будут работать в новой системе. Более того, некоторые эксперты считают, что большинство срывов происходит не из-за технических ошибок, а из-за управленческих.
В качестве одного из двух наиболее типичных сценариев провала эксперты приводят ситуацию, когда руководителем проекта со стороны заказчика назначают начальника ИТ-отдела без освобождения от текущих задач. На практике это приводит к тому, что он одновременно тушит пожары в работающей системе и руководит сложнейшим проектом миграции. Результатом может стать выгорание, больничный, потеря фокуса и остановка проекта.
Во втором типичном сценарии провала к большим проблемам приводит размытая ответственность за данные. В старых системах данные живут своей жизнью. Кто-то их создавал, кто-то правил, кто-то удалял. При миграции выясняется, что владельцев данных либо нет, либо они не помнят, что означают те или иные поля. Без их участия невозможно принять решение о том, какие данные переносить, какие чистить, а какие удалять.
Качество данных
Еще одна весьма серьезная проблема миграции может скрываться в низком качестве данных в исходной системе. Эти данные можно рассматривать как фундамент, на котором держится все остальное. И если этот фундамент никуда не годится, новый дом рухнет в первый же месяц.
Один из экспертов заметил, что деградация данных происходит незаметно. По его словам, в течение пяти-семи лет эксплуатации в системе могут накопиться дубли контрагентов, расхождения в складских остатках между учетной системой и физическим складом, незакрытые документы за прошлые периоды, справочники с устаревшими или некорректными значениями.
Владимир Малах из «ФТО» привел драматические цифры одного из проектов, где «при выгрузке нормативно-справочной информации было 12 000 задублированных контрагентов и расхождение складских остатков на 18 млн рублей. Очистка данных заняла 4 месяца вместо планового 1 месяца. И это не единичный случай — такие цифры типичны для компаний, которые годами не проводили инвентаризацию своих данных».
В старой системе эти «артефакты» могут даже не мешать работе. Но при попытке перенести данные в новую, более жесткую структуру все эти ошибки могут вылезти наружу и потребовать ручной очистки.
При этом далеко не все из старой системы нужно переводить в новую. В одном из проектов у заказчика было 130 тысяч записей номенклатуры, но только треть реально использовалась в операционной деятельности. Для того чтобы решить, что нужно, а что нет, требуется предварительная инвентаризация, дедубликация и маркировка «на удаление». Все это может занять месяцы работы, которые никто не хочет закладывать в бюджет.
По словам Максима Сердюкова, заказчикам нужно сместить фокус с вопроса «что переносить» на вопрос «как переносить»: «Вопрос не в очередности, а во взаимосвязанности автоматизированных систем между собой». Правильный вопрос — не «какой модуль перенести сначала», а «как устроены связи между модулями и где в этих связях скрыты риски». И ответ часто один: связи не документированы, а данные не очищены.
Складывается парадоксальная ситуация, когда компании годами экономят на поддержке качества данных, а затем тратят в разы больше на их очистку в рамках миграционного проекта. Это как копить хлам в квартире пять лет, а потом нанимать отдельную бригаду, чтобы вывезти ненужное перед переездом.
Формальные контрольные точки
Миграция без контрольных точек недопустима. Без них проект превращается в что-то вроде эксперимента. Миграция либо состоится успешно, либо провалится. Фифти-фифти. В общем, контрольные точки нужны, и точка. Но когда они, как это часто бывает, превращаются в формальность, галочку для отчетности, а не в реальный инструмент управления рисками, это может стать проблемой.
Эффективная контрольная точка должна давать право сказать «стоп» без потери лица, и для этого должны быть заранее определены четкие критерии. Например, расхождения в данных не более X%, время отклика не ниже N мс. Иными словами, это должна быть удобная возможность откатиться немного назад или пересмотреть план без фатальных последствий для бизнеса.
Практика показывает, что эффективная миграция разбивается на три крупных шага: аудит, планирование с пилотом и непосредственно выполнение. Как говорит Максим Сердюков, при использовании контрольных точек «результатом является подтверждение рабочих гипотез и корректировка плана». Иными словами, контрольная точка не всегда такая, что «проверили и пошли дальше», а зачастую это «проверили, поняли, что ошибались, и переписали план». Другой эксперт даже предлагает отказаться от культа «точно в срок» в пользу большей стабильности.
При этом готовность системы к следующему шагу определяется не только техническими тестами, но и тем, насколько владельцы данных понимают и принимают правила трансформации. Если владелец данных подтверждает, что ему понятны правила сопоставления, то это хороший сигнал. Если нет, то надо останавливаться и пересматривать подход. Человеческий фактор в контрольных точках не менее важен, чем технический.
Иллюзорная «красная кнопка»
Почти в каждом проекте миграции закладывают сценарий отката. Но в реальности большинство компаний не имеют работающего плана возврата. Вместо этого у них есть лишь общее понимание «если что, вернемся назад». А когда «если что» случается, выясняется, что план отката существует только в головах уволившихся сотрудников, а его тестирование никто не проводил.
По мнению независимого IT-эксперта Романа Мезенцева, сбой при миграции может привести к катастрофе. По его словам, план отката должен включать не только технические шаги, но и каналы коммуникации, матрицу эскалации и временные рамки. Отсутствие тестирования этого плана приводит к задержкам в принятии решений, незапланированным простоям и перерасходу бюджета.
Прагматичный подход состоит в том, чтобы заранее определить измеримые критерии, при которых решение об откате принимается автоматически. Это могут быть расхождения в данных, недоступность критических отчетов, падение производительности ниже заданного порога. Все критерии должны быть согласованы с бизнесом еще до начала промышленного запуска. «Красная кнопка» нужна не для того, чтобы ударить по ней в приступе паники. Нет! Для ее нажатия нужен заранее оговоренный триггер.
Относительно аспекта кибербезопасности эксперты напоминают, что во время изменений система может стать более уязвимой для внешних угроз, поскольку все внимание команды сосредоточено на внутренних проблемах.
В целом же главный парадокс «красной кнопки» состоит в том, что все хотят ее иметь, но никто не хочет нажимать. Это своего рода психологическая ловушка, где нажатие красной кнопки воспринимается как поражение. Для ЛПР это как признать, что план был плох, а подготовка недостаточной. В итоге кнопка превращается в декорацию, а откат — в героический поступок, на который решаются уже после того, как сгорели все мосты. Настоящая зрелость проекта измеряется не тем, как часто нажимают красную кнопку, а тем, насколько спокойно и безболезненно это делают.
Топ-5 типичных ошибок
Если обобщить опыт экспертов в виде промежуточного итога, то на основе их реальной практики можно выделить пять самых частых провалов, которые превращают миграцию в долгострой.
Накопление и использование некачественных данных. Ошибки в остатках, дубли в справочниках, незакрытые документы за годы. В старой системе они не видны, в новой вылезают все сразу.
Недооценка функционального объема и кастомизаций. Компании годами дорабатывали старую систему, а при переходе не инвентаризируют весь этот код. Количество доработок вырастает в разы уже в середине проекта.
Выделение недостаточного количества ресурсов. Ключевые пользователи совмещают проект с основной работой. Один специалист пытается вести масштабную миграцию. Резерв на непредвиденное не закладывается.
Слабое управление изменениями. Пользователей обучают за два дня до старта. Нет ролевых инструкций и тестовой среды. Первые недели работы превращаются в хаос.
Игнорирование реестра рисков. Команда не собирается заранее и не разбирает, что именно может пойти не так. Озвученные опасения не фиксируются, но внезапно становятся реальными проблемами на более поздних этапах.
Миграция как управленческая задача
За всеми стратегиями, контрольными точками и красными кнопками скрывается простая, но неудобная истина, которая заключается в том, что миграция давно перестала быть технологической задачей и стала задачей управленческой и человеческой.
Бывалый из «Операции Ы», в попытке повысить «гонорар» за рискованное предприятие, с сомнением произносит: «Дело для нас новое, неосвоенное». Так и многие интеграторы сегодня повышают ставки в уверенности, что заказчики готовы инвестировать, предупреждая их, что миграция в современном ландшафте — это такая неосвоенная территория, где старые карты не работают, а каждый шаг может привести к неожиданным последствиям.
Технические проблемы, такие как несовместимость версий, ошибки переноса, сбои интеграций, — это лишь вершина айсберга. Под водой же скрывается размытая ответственность, недокументированные процессы, устаревшие данные, выгоревшие команды и надежда на «авось». Компании годами копят технический долг, а затем удивляются, что миграция превращается в ад.
Эксперты обращают внимание заказчиков на качество данных, ресурсы и владельцев, а компании все равно экономят на аудите, назначают ответственных по совместительству и надеются, что «пронесет». И когда не проносит — начинается хаос, который обходится в месяцы простоя, напрасно растраченные бюджеты и уволившиеся команды.
Можно долго рассуждать и теоретизировать про все эти «малые шаги» и «контрольные точки». Но на самом деле это лишь умозрительная попытка обуздать хаос, который компании создали сами, годами закрывая глаза на дубли в справочниках и отсутствие документации. Успешной считается не та миграция, которая завершилась в срок, а та, в ходе которой никто не уволился со скандалом, а пользователи не кроют новую систему матом. А это возможно только в том случае, когда к миграции тщательно готовятся. Потому что миграция в любом случае дело рискованное. А риск, как известно, дело благородное, но только когда он просчитан до копейки и подкреплен работающим сценарием отката. В противном случае он называется просто «авантюрой».
Обсудить
проект
Расскажите о своей проблеме. Мы предложим лучшее решение и сориентируем по срокам и стоимости.