3.6 Модернизация унаследованных систем

Обзор и мотивация

Унаследованные системы это системы, на которых держится мир. Основные банковские книги, налоговые и пенсионные движки, системы воздушного движения и обороны, администрирование страховых полисов и государственные реестры, от которых зависят общества, зачастую имеют десятилетия. Многие написаны на COBOL (Common Business-Oriented Language) или других старых технологиях и всё ещё обрабатывают большинство критических транзакций. «Унаследованный» не оскорбление. Это значит, что система достаточно ценна, чтобы выжить, достаточно критична, чтобы её отказ был катастрофическим, и достаточно стара, чтобы безопасно менять её было трудно. Модернизация унаследованных систем это дисциплина улучшения, миграции или замены этих систем без разрушения существенных услуг, которые они предоставляют.

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

Эта глава охватывает постепенные паттерны модернизации, которые действительно работают («душащая фига» и ветвление через абстракцию), как оценивать и приоритизировать риск наследия, управление хозяйствами мейнфреймов и COBOL, дисциплину миграции данных и параллельной работы и прежде всего как противостоять соблазну большого переписывания. Центральное убеждение: успешная модернизация почти всегда постепенна, основана на свидетельствах и непрерывно приносит ценность. Это никогда не многолетний «большой взрыв».

Ключевые принципы

Унаследованный значит ценный и основополагающий, а не просто старый. Уважайте то, что делает система, прежде чем её трогать; она кодирует десятилетия с трудом добытых бизнес-правил.
Постепенное почти всегда побеждает «большой взрыв». Заменяйте кусок за куском за стабильным интерфейсом; поставляйте ценность непрерывно и держите риск малым.
Большое переписывание это умолчательный режим отказа. Полные переписывания регулярно превышают сроки, недодают и отменяются; относитесь к этому порыву с глубоким подозрением.
Нельзя модернизировать то, чего не понимаешь. Обратно разработайте и документируйте поведение (включая недокументированные правила), прежде чем его заменять.
Миграция данных это место, где проекты умирают. Данные старше, грязнее и запутаннее, чем кто-либо ожидает; планируйте её как первоклассное усилие.
Запускайте старое и новое параллельно, чтобы выстроить уверенность. Параллельная работа и сравнение ловят расхождения до переключения.
Приоритизируйте по риску и ценности, а не по возрасту. Модернизируйте самое рискованное и самое ценное первым, а не просто самое старое.
Держите свет включённым, пока меняете двигатель. Сервис должен продолжать работать на всём протяжении; для критичных систем граждан или финансов приемлемого простоя нет.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
«Душащая фига» (постепенно)	Непрерывная ценность, низкий риск, обратимость, сервис остаётся работающим	Более долгий общий срок, нужно параллельно вести две системы, накладные расходы на интеграцию
Переписывание «большим взрывом»	Чистый лист, нет ограничений наследия в новом коде	Очень высокая доля провалов, нет ценности до конца, огромная стоимость, потеря бизнес-правил
Инкапсуляция (обёртка API)	Быстро, низкий риск, модернизирует доступ, не трогая ядро	Ядро остаётся унаследованным; откладывает, а не решает лежащий в основе риск
Оставить как есть (управление)	Нет риска проекта; дешевле всего в краткосрочной перспективе	Риск знаний и платформы продолжает накапливаться; в итоге вынужденное действие

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

Вопросы для обсуждения с командой

Есть ли у вас место, куда поставить слой маршрутизации перед унаследованной системой, и если нет, что потребовалось бы, чтобы его создать? «Душащая фига» зависит от шва: API-шлюза, фасада или прокси, через который можно перенаправлять одну возможность за раз на новую реализацию. У многих старых систем такого шва нет, поэтому первое приращение модернизации часто просто построение точки перехвата, и эту работу легко недооценить. Принесите текущую карту интеграций и спросите, где можно перехватывать трафик по возможностям без переключения «большим взрывом». Если негде, начальным ходом может быть ветвление через абстракцию на внутреннем шве. Без слоя маршрутизации у вас нет постепенного пути, а именно так организации откатывает обратно к переписыванию, которое обычно проваливается.
Нанесли ли вы своё хозяйство на сетку «риск против ценности» или ваша дорожная карта определяется тем, какая система кажется самой старой? Глава настаивает, что модернизировать нужно сначала то, что одновременно рискованно и ценно, и намеренно оставлять в покое стабильные, редко меняемые, хорошо понятные системы, даже древние. Без явной сетки внимание течёт к самой громкой жалобе или наименее модной технологии, а подлинные бомбы замедленного действия (критичная система с двумя сопровождающими, близкими к пенсии) ждут. Оцените каждую систему по критичности для бизнеса, техническому риску, частоте изменений и риску знаний, затем идите по порядку от верхнего правого угла. Принесите эту сетку на встречу как общую карту. Риск знаний заслуживает наибольшего веса, потому что это единственный вход, который лишь ухудшается и не может быть выкуплен после ухода людей.
Когда вы переключаетесь, как вы докажете, что ни одна запись не потеряна и не изменена, и кто подписывает это свидетельство? Миграция данных то место, где эти проекты умирают, а уверенность приходит от сверки: счётчиков строк, контрольных сумм и бизнес-контрольных итогов, совпадающих между старым и новым, плюс параллельной работы, сравнивающей выходные данные на одних и тех же входных, пока они не совпадут с высоким порогом. Для системы пособий или главной книги расхождение это недоплаченный гражданин или потерянная копейка, поэтому свидетельство должно удовлетворять аудитора, а не только инженера. Решите сейчас, какие итоги вы будете сверять, какой порог уверенности запускает переключение и как долго вы будете вести старое и новое параллельно. Сохраняйте откат доступным на всём протяжении и переключайтесь срезами, а не всё сразу. Расхождения, которые вы найдёте при параллельной работе, обычно недокументированные унаследованные правила, которые вы должны сохранить, поэтому воспринимайте каждое как открытие, а не просто дефект.
Какие из ваших унаследованных систем вы ведёте на управлении, а какие активно заменяете и кто решил, какая из них какая? Глава проводит намеренную черту между системами, которые стоит стабилизировать на месте (документирование правил, добавление характеризующих тестов, перекрёстное обучение сопровождающих), и системами, которые стоит постепенно заменять, и эти два пути требуют очень разного финансирования и штата. Для большой организации опасность в дрейфе: система, помеченная «управляем пока», тихо становится «управляем вечно», пока последний сопровождающий не уйдёт на пенсию, и выбор не будет сделан за вас в кризисе. Противоположные соображения это стоимость управления и устаревание платформы с одной стороны против риска и потрясений замены с другой, а риск знаний должен склонять чашу весов, потому что только ухудшается. Принесите сетку «риск против ценности», число сопровождающих и горизонт их выхода на пенсию по каждой системе и явного владельца решения «управлять или заменять». В корпоративных и государственных хозяйствах назовите периодичность пересмотра и ответственное должностное лицо по каждой системе, потому что классификация, которую никто не пересматривает, решение, которое никто не принимает.
Когда руководство просит полное переписывание, каков ваш стандартный ответ и можете ли вы показать, что постепенный путь поставит в первые три месяца? Переписывание «большим взрывом» умолчательный режим отказа, однако его продолжают финансировать, потому что чистый лист легко продать, а «душащую фигу» нет. Большой команде нужен отрепетированный ответ, чтобы спор выигрывался свидетельствами, а не тем, кто старше в комнате. Подлинное напряжение в том, что некоторые платформы действительно неустойчивы и переписывание оправдано, поэтому ответ не может быть общим отказом: он должен взвешивать, остались ли постепенные швы, против настоящей цены поддержания старой платформы живой. Принесите ценность, которую поставило бы первое постепенное приращение, историческую долю провалов сопоставимых переписываний и декомпозицию любого предлагаемого переписывания на независимо поставляемые части. В государстве, где отменённая многолетняя программа сжигает общественные деньги на глазах у всех, настаивайте, чтобы любое переписывание ставило ценность рано и переживало остановку на полпути без полной потери.
Как вы захватите бизнес-правила, запертые в вашем самом старом коде, до ухода людей, которые их понимают? Большая часть ценности унаследованной системы это недокументированное поведение, накопленное десятилетиями крайних случаев, норм и совместимых с ошибками исправлений, и оно живёт в сокращающемся пуле уходящих специалистов, а не в какой-либо письменной записи. Для большой организации это единственный риск, который нельзя выкупить после ухода людей, поэтому он заслуживает финансирования раньше более заметной работы над платформой. Противоположное тяготение в том, что захват знаний (документация, характеризующие тесты, обратная разработка, перекрёстное обучение) ощущается накладными расходами, ничего не выпускающими, и именно поэтому откладывается. Принесите опись того, кто держит критические знания, как близко они к уходу и какое покрытие тестами фиксирует текущее поведение сегодня. В регулируемой и государственной среде воспринимайте установленные законом правила, закодированные в старом коде, как актив соответствия: их тихая потеря не технический долг, а юридический риск.

Взгляд по секторам

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

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

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

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

Примеры

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

Крупная организация. Крупный страховщик ведёт администрирование полисов на мейнфрейме с COBOL, надёжном, но дорогом для изменений и сопровождаемом горсткой инженеров, близких к пенсии. Вместо переписывания страховщик оборачивает мейнфрейм современными API и применяет «душащую фигу»: новые возможности расчёта и покупки и самообслуживания строятся на современной платформе и направляются через фасад, пока основные записи полисов остаются на мейнфрейме. Параллельно команда документирует бизнес-правила и добавляет характеризующие тесты вокруг COBOL. За несколько лет возможность за возможностью уходит с мейнфрейма, каждый выпуск приносит ценность, пока оставшееся ядро не будет выведено на условиях страховщика, а не в кризисе.

Государственный сектор. Агентство социального обеспечения должно модернизировать десятилетнюю систему расчёта пособий, платящую миллионам граждан и не допускающую ни прерывания, ни неверной выплаты. Изучив сопоставимые проваленные программы, оно отвергает замену «большим взрывом». Вместо этого оно профилирует и очищает данные, строит автоматизированную миграцию с полной сверкой по контрольным итогам и ведёт новый движок пособий параллельно со старым много месяцев, подавая обоим одни и те же заявления и сравнивая каждый расчёт, расследуя каждое расхождение (часто обнаруживая недокументированные унаследованные правила, которые нужно сохранить). Только когда новая система совпадает со старой с очень высокой уверенностью, оно переключается вид пособия за видом, сохраняя откат на всём протяжении. Фасад «душащей фиги» позволяет гражданам видеть одну непрерывную услугу через переход.

Бизнес-обоснование: мотивы, ROI и TCO

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

Обосновывайте руководству, переформулируя выбор. Вопрос не в том «модернизировать или нет». Он в том «модернизировать постепенно сейчас или платить растущие издержки управления и столкнуться с вынужденной более рискованной модернизацией позже, в кризисе». Количественно оцените TCO статус-кво (стоимость платформ и лицензий, надбавка за дефицитные навыки, взвешенная по риску стоимость невосстановимого сбоя) и сопоставьте с поэтапной программой, снижающей риск и стоимость с каждым приращением, пока сервис продолжает работать. Принципиально настаивайте, чтобы любое предлагаемое переписывание было структурировано для ранней и частой поставки ценности. Программа, не приносящая ничего три года и способная быть отменённой с полной потерей, не вложение, а азартная игра. Самый сильный аргумент ROI в пользу подхода «душащей фиги» вариативность: ценность поставляется непрерывно, и организация может скорректировать курс в любой момент.

Антипаттерны и ловушки

Переписывание «большим взрывом». Многолетняя замена «всё или ничего», не приносящая ценности до конца и часто отменяемая с огромными потерями.
Переписывание без понимания. Замена кода, чьи бизнес-правила никогда не документировались, с молчаливым отбрасыванием крайних случаев, от которых зависят реальные пользователи и законы.
Недооценка данных. Воспринимание миграции данных как запоздалой мысли, хотя это самая трудная и рискованная часть проекта.
Пропуск параллельной работы. Переключение на новую систему без параллельного сравнения и обнаружение расхождений только после того, как они затронули реальных людей.
Автоматическая трансляция как решение. Машинная трансляция COBOL в современный язык с уверенностью, что работа сделана, порождающая непонятный код, дословно воспроизводящий старую логику.
Модернизация по возрасту, а не по риску. Трата усилий на старые, но стабильные системы, пока высокорисковые, часто меняемые системы ждут.
Потеря знаний. Позволять последним сопровождающим уйти на пенсию, не захватив бизнес-правила и не добавив характеризующие тесты.
Нет отката. Переключение без пути назад, когда новая система ведёт себя плохо под реальной нагрузкой и реальными данными.

Модель зрелости

Уровень 1: Начальный. Унаследованных систем боятся, и они заморожены; изменений избегают. Нет ни описи, ни оценки рисков. Модернизация, если вообще пробуется, стихийное переписывание «всё или ничего», движимое разочарованием. Знания живут в нескольких уходящих головах, и ничего не записано.
Уровень 2: Развитие. У некоторых команд есть опись и приблизительное ощущение риска, а несколько унаследованных систем обёрнуты API для доступа. Постепенные шаблоны известны, но применяются неравномерно, и мысль всё ещё дрейфует к переписываниям «большим взрывом». Миграцию данных пробуют, но недооценивают, а практика сильно различается от команды к команде.
Уровень 3: Стандартизация. Системы приоритизируются по риску и ценности по документированному методу всей организации. Постепенные шаблоны («душащая фига», ветвление через абстракцию) обеспечиваемое умолчание, и каждая модернизация следует стандартному плейбуку. Миграция данных это запланированное, сверяемое усилие с параллельной работой перед переключением, а захват знаний и характеризующие тесты обязательная практика, а не необязательная.
Уровень 4: Управление. Модернизация измеряется и контролируется данными. Хозяйство несёт базовые значения: число сопровождающих и горизонт выхода на пенсию по системе, охват характеризующими тестами, доли прохождения сверки миграции, число расхождений при параллельной работе и ценность, поставленная за приращение, всё отслеживается относительно целевых значений. Решения «управлять или заменять» и решения «идти или не идти» о переключении принимаются на этих свидетельствах, а система, уходящая за порог риска знаний, запускает действие, а не ждёт кризиса.
Уровень 5: Оркестрация. Модернизация непрерывна, интегрирована с бизнес-планированием и планированием рисков и адаптивна. Портфель перебалансируется относительно траектории риска (особенно риска знаний) по мере её смещения, постепенная замена рутинна и малодраматична, каждое приращение приносит ценность и обратимо, а организация намеренно управляет темпом. Уроки каждой миграции возвращаются в общий плейбук, так что всё хозяйство со временем улучшается.

Идеи для обсуждения

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

Главные выводы

Унаследованный значит ценный и основополагающий; уважайте и понимайте систему, прежде чем её менять.
Модернизируйте постепенно «душащей фигой» и ветвлением через абстракцию, поставляя ценность непрерывно и держа каждое изменение малым и обратимым.
Воспринимайте переписывание «большим взрывом» как умолчательный режим отказа; резервируйте его для действительно неустойчивых платформ и даже тогда раскладывайте на части.
Приоритизируйте по риску и ценности (особенно по риску знаний), а не по возрасту; некоторые старые системы лучше вести на управлении, а не заменять.
Миграция данных и параллельная работа сердце усилия; профилируйте, сверяйте, запускайте параллельно и сохраняйте откат.
Самое сильное бизнес-обоснование вариативность: постепенная модернизация превращает одну крупную рискованную ставку в множество малых, возвращающих ценность.

Источники и дополнительное чтение

Michael Feathers, Working Effectively with Legacy Code
Martin Fowler, “StranglerFigApplication” and “BranchByAbstraction”
Sam Newman, Monolith to Microservices
Nicholas Carr / industry studies on mainframe and COBOL dependency (context on the scale of legacy estates)
Robert Annett, Working with Legacy Systems
Eric Evans, Domain-Driven Design (anti-corruption layer)
Gregor Hohpe, Enterprise Integration Patterns and The Software Architect Elevator
Standish Group CHAOS Report (evidence on large project and rewrite failure rates)

3.6 Модернизация унаследованных систем

Обзор и мотивация

Ключевые принципы

Рекомендации

Модернизируйте постепенно шаблоном «душащая фига»

Используйте ветвление через абстракцию для внутренних швов

Оценивайте и приоритизируйте риск наследия намеренно

Управляйте хозяйством мейнфреймов и COBOL, а не просто заменяйте его

Воспринимайте миграцию данных и параллельную работу как ядро проекта

Управляйте соблазном большого переписывания