ViktorStyle
New member
Привет, форумчане. Хочу поделиться опытом одной из самых нервных историй в моей карьере: мы за полгода вынесли ядро бизнеса из монолита в микросервисы, причём резали не по чуть-чуть, а одним большим куском. Да, тем самым big bang, которого все умные статьи советуют избегать. Рассказываю честно, что сработало, что почти нас убило и что я бы сделал иначе.
Сначала контекст. У нас был монолит на восемь лет истории, три команды, которые боялись деплоить по пятницам, и релизный цикл в две недели. Бизнес поставил условие: не останавливать продажи ни на минуту и уложиться в квартальный бюджет. Постепенная миграция через паттерн душащего дерева выглядела правильной, но у нас не было времени строить инфраструктуру для долгого сосуществования двух миров. Поэтому мы осознанно выбрали big bang и построили вокруг него кучу страховки.
Главное, что я понял ещё на этапе подготовки: big bang проваливается не в момент переключения, а задолго до него. Мы потратили полтора месяца только на инвентаризацию. Расписали все доменные сущности, все неочевидные связи через общие таблицы, все фоновые задачи, которые кто-то запускал кроном и забыл. Отдельно составили контрактные тесты на границы сервисов. Эта скучная бумажная работа спасла нас позже не раз.
Второй по важности пункт — наблюдаемость и переключатели. Мы заранее подняли сквозную трассировку, метрики на каждый сервис и фича-флаги для всех новых путей. У нас был теневой трафик: реальные запросы шли в оба контура, а ответы монолита считались эталоном. Две недели мы сверяли расхождения, и это позволило выловить десятки багов до того, как их увидели клиенты.
Самым тяжёлым оказались не сервисы, а данные. Разделить базу на восемь независимых хранилищ — это боль, потому что в монолите почти всё было связано через внешние ключи и транзакции на три таблицы. Мы сделали двойную запись, потом сверку, потом переключение чтения, и только потом отключили старую запись. Правило простое: база мигрирует последней и живёт в переходном режиме дольше всего.
В ночь переключения мы всё равно получили сюрприз. Один сервис платежей упёрся в лимит соединений, потому что в монолите был общий пул, а теперь каждый держал свой. Хорошо, что рядом дежурила вся команда и у нас был готовый план отката. Мы не откатились, добавили пул и подняли лимиты за сорок минут. Урок: держите путь назад открытым до последнего и репетируйте откат так же серьёзно, как сам релиз.
Через полгода после переключения могу сказать, что игра стоило свеч. Релизы сократились с двух недель до одного дня, команды перестали блокировать друг друга, а инциденты стали локальными, а не общеплатформенными. Но я бы не советовал big bang всем подряд. Если у вас нет сильной инженерной культуры, тестов и людей, готовых ночевать на дежурстве, выбирайте постепенную миграцию.
Что бы я рекомендовал читателям: не начинайте с кода, начинайте с карты доменов и контрактов; вкладывайтесь в наблюдаемость до первого сплита; репетируйте переключение и откат на стейдже минимум дважды; держите бизнес в курсе реалистичных сроков, а не удобных. И обязательно оставьте в команде человека, который помнит монолит, иначе первые месяцы после переключения будут очень грустными.
А теперь вопрос к вам: доводилось ли вам участвовать в большой миграции, и какой неочевидный урок вы вынесли из неё? Делитесь историями, вместе мы точно переживём любую миграцию веселее!
Сначала контекст. У нас был монолит на восемь лет истории, три команды, которые боялись деплоить по пятницам, и релизный цикл в две недели. Бизнес поставил условие: не останавливать продажи ни на минуту и уложиться в квартальный бюджет. Постепенная миграция через паттерн душащего дерева выглядела правильной, но у нас не было времени строить инфраструктуру для долгого сосуществования двух миров. Поэтому мы осознанно выбрали big bang и построили вокруг него кучу страховки.
Главное, что я понял ещё на этапе подготовки: big bang проваливается не в момент переключения, а задолго до него. Мы потратили полтора месяца только на инвентаризацию. Расписали все доменные сущности, все неочевидные связи через общие таблицы, все фоновые задачи, которые кто-то запускал кроном и забыл. Отдельно составили контрактные тесты на границы сервисов. Эта скучная бумажная работа спасла нас позже не раз.
Второй по важности пункт — наблюдаемость и переключатели. Мы заранее подняли сквозную трассировку, метрики на каждый сервис и фича-флаги для всех новых путей. У нас был теневой трафик: реальные запросы шли в оба контура, а ответы монолита считались эталоном. Две недели мы сверяли расхождения, и это позволило выловить десятки багов до того, как их увидели клиенты.
Самым тяжёлым оказались не сервисы, а данные. Разделить базу на восемь независимых хранилищ — это боль, потому что в монолите почти всё было связано через внешние ключи и транзакции на три таблицы. Мы сделали двойную запись, потом сверку, потом переключение чтения, и только потом отключили старую запись. Правило простое: база мигрирует последней и живёт в переходном режиме дольше всего.
В ночь переключения мы всё равно получили сюрприз. Один сервис платежей упёрся в лимит соединений, потому что в монолите был общий пул, а теперь каждый держал свой. Хорошо, что рядом дежурила вся команда и у нас был готовый план отката. Мы не откатились, добавили пул и подняли лимиты за сорок минут. Урок: держите путь назад открытым до последнего и репетируйте откат так же серьёзно, как сам релиз.
Через полгода после переключения могу сказать, что игра стоило свеч. Релизы сократились с двух недель до одного дня, команды перестали блокировать друг друга, а инциденты стали локальными, а не общеплатформенными. Но я бы не советовал big bang всем подряд. Если у вас нет сильной инженерной культуры, тестов и людей, готовых ночевать на дежурстве, выбирайте постепенную миграцию.
Что бы я рекомендовал читателям: не начинайте с кода, начинайте с карты доменов и контрактов; вкладывайтесь в наблюдаемость до первого сплита; репетируйте переключение и откат на стейдже минимум дважды; держите бизнес в курсе реалистичных сроков, а не удобных. И обязательно оставьте в команде человека, который помнит монолит, иначе первые месяцы после переключения будут очень грустными.
А теперь вопрос к вам: доводилось ли вам участвовать в большой миграции, и какой неочевидный урок вы вынесли из неё? Делитесь историями, вместе мы точно переживём любую миграцию веселее!