Трансформация технологической платформы – ретроспектива за 12 минут

Меня зовут Андрей Никольский, я прошел в Банки.ру за 14 лет длинный путь от разработчика до техлида. Сейчас руковожу командой Платформы и лидирую наших девопсов.

Сегодня расскажу историю о том, как мы еще в 2017 году решили поменять инфраструктурную платформу. В основе статьи – мой доклад с DevOpsConf21, я много всего уточнил, переписал и дополнил с учетом опыта следующих четырех лет, прошедших после того выступления. 

8 лет назад у нас было 40 сред, 15 разработчиков, 2 монолита, 10 сервисов и свое железо в трех серверных стойках. С такими исходными данными мы решили полностью заменить систему управления конфигурацией: с Puppet на Ansible. Окружений много, потому что с 2010-го мы поставляли разработчикам и тестировщикам маленькие копии нашего приложения — это делало задачу еще интереснее.

Путь был непростой. О нем расскажу в хронологическом порядке, не забывая о косяках и ошибках. По ходу повествования я выделил инсайты, которые могли бы сильно помочь мне в прошлом. В конце оформил их в виде письма для себя образца 2017-го ?.  А если вы решитесь проделать нечто столь же безумное (ну там, не знаю, переехать с микросервисов на монолит, с linux на windows и так далее), надеюсь, мои заметки уберегут вас от сложностей, с которыми мы столкнулись.

Содержание для удобной навигации по статье:

– Почему решились на смену технологий. Предыстория.
– 2017 год
– 2018 год
– 2019 год
– 2020 год
– Итоги из 2025
– Рефлексия / Письмо самому себе в 2017-ый
– Эпилог

Почему решились на смену технологий. Предыстория.

С инфраструктурой, которую я кратко описал выше, были некоторые проблемы. 

• Добавление нового сервиса занимало около 40 часов.

• Среды разработки/тестирования периодически тормозили, вызывая недовольство разработчиков и тестировщиков.

• Внесение изменений в конфиги занимало длительное время…

• …и часто что-нибудь ломало в продакшене.

• Как раз вышел новый Puppet (конечно же, ни фига не совместимый со старым).

• Бизнес был недоволен темпами разработки и количеством поддержки непродуктовых сред 

• Часть систем крутилась на FreeBSD, и часто под неё не было всяких нужных разработчикам пакетов.

• Иногда в результате CV Driven Development разработчики ставили себе на площадку что-нибудь совершенно новое, тем самым ломая её полностью, а чтобы заново её пересоздать, нужно было потратить 3-4 дня.

Требовалось найти решение. Мы поштормили с командой, собрали идеи и решили попилотить самые перспективные. Тем более что некоторые предложения дополняли и пересекались друг с другом.

Для начала мы решили попробовать перенести наш стек в Docker, разворачивать контейнеры в docker-compose через Vagrant, чтобы в будущем полностью отказаться от площадок разработки.

Идея нравилась всем: разработчики хотели работать с Docker, бизнесу нужно было снизить расходы, нам — сократить время на поддержку. Поскольку крутить Puppet в докере бессмысленно, нужно было отказаться от него и использовать какую-нибудь другую систему управления конфигурацией, например, набиравший силу Ansible. И конечно, за компанию было бы здорово унифицировать и обновить базовую ОС. 

Звучит отлично, что делать — понятно, и, вроде, быстро?

Первый план миграции.

Перед началом работы я разбил проект на следующие этапы:

1. Пилотный проект на dev-среде.

2. Замена dev-сред.

3. Пилотный проект на test-среде.

4. Замена test-сред.

5. Пилотный проект на stage-среде.

6. Пилотный проект на production-среде.

7. Миграция. 
   a) Production
   b) Новый stage.

2017 год

Оценить эту задачу было довольно трудно. По моему опыту, оценивая новые масштабные задачи с множеством неизвестных, команды обычно тыкают пальцем в небо. С нами это тоже произошло. 

Зимой 2017 года мы приступили к первому этапу проекта — пилоту на dev-среде.

Мы сделали репозиторий, инвентори, шаблоны конфигов, основные роли, планы деплоя. На это ушло два месяца. Это решение было вполне пригодно к тиражированию. 

Закончив с первым этапом, мы предположили, что остальные пойдут быстрее (кроме продакшена).

Итого, суммарно на весь проект мы заложили год (включая пару месяцев на форс-мажоры).

После демо, на котором мы показали работающую dev-площадку, я озвучил эти сроки руководству и смежным подразделениям, получил добро на продолжение работ.

Этап второй: замена dev-сред — и его подводные камни

Мы хотели замотивировать пользователей быстрее переходить на новые среды и помогать нам с миграцией. Для этого нам нужно было предложить такие среды разработки и тестирования, которые будут полезнее и удобнее старых. 

Это значило: 

• более высокую скорость работы и развертывания;

• простоту и удобство поддержки;

• стабильность работы;

• комфорт для разработчиков.

Мы собрали тестовую группу из нескольких разработчиков, предоставили им площадки и начали собирать обратную связь. 

Некоторые сценарии использования оказались для нас неожиданными. Например, коллеги использовали xDebug и подключались к стендам напрямую из IDE – приходилось открывать порты на виртуалках. При этом на старых площадках так делали всегда, а специалисты, которые создавали эти площадки, перешли в другие места. Кто-то пересобирал приложение прямо на виртуалке и упирался сначала в права доступа, а потом и в ресурсы. На разбор некоторых мелких деталей мы тратили по две-три недели, иногда подолгу споря над самóй возможностью реализации. 

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

Для того чтобы облегчить себе задачу, мы начали перебирать все сторонние сервисы, которые не относятся непосредственно к площадкам, и переносить их в Ansible. В частности, было довольно удобно автоматизировать конфигурацию систем, которые под Puppet так и не успели затащить. 

Quick win здесь такой: меняем совсем старое легаси на нормальные вещи (без смс и даунтайма). Запишем эту идею в блокнот под №1 — пригодится.

2018 год

Через год, в январе 2018, я начал догадываться, что что-то пошло не так. Два этапа (пилотная дев-среда и попытка замены старых дев-сред) заняли всё отведенное на проект время. Самое печальное, что среды разработки так до конца и не доделали. Однако я, как оптимист, решил, что самое сложное позади: «Сейчас мы перепланируем немного и, пусть с опозданием на год, но всё же завершим замену платформы в течение 2018-го! Ура, товарищи!».

Так мы начали третий этап — пилотный проект на тестовых средах, который занял всего пару недель. А вот на следующем этапе мы наступили на те же грабли с поддержкой “старых” и “новых” сред. И первой из серьезных проблем стала скорость релиза на новые среды наших монолитов (~40 минут). Для тестеров это оказалось критично, поэтому они старались новыми средами не пользоваться (к сожалению, еще и умалчивали об этом). 

Разумеется, никто не отменял “вихрь неотложных дел” – мы оказались завалены поддержкой других проектов в разработке. Наши условные 30% времени, которые мы заложили на замену платформы, уменьшились почти до нуля. А в очереди задач стояли сразу несколько новых сервисов, которые мы просто не успевали реализовать в “старых” средах. 

Тут мы приняли важное стратегическое решение. Постановили, что новые микросервисы будем создавать только в “новых” средах. Собрали гибрид: старая площадка, управляемая Puppet, а рядом — виртуалка под управлением Ansible с новыми быстрыми микросервисами. Вся маршрутизация проходила через DNS (плоды идеи №1 – службу DNS мы сразу автоматизировали через Ansible и без проблем поддерживали весь зоопарк). Определенно стоит записать схему с гибридными средами в блокнот под №2.

Через полгода после запуска тестовых сред возникли сложности с ресурсами: команды разработки просили больше площадок, а нам негде было их размещать. Всего было только три новых тестовых “склянки”, а спрос был на все десять. Кроме того, поступали жалобы на медленную работу. Так вышло, что мы как раз изучали рынок облачных услуг: считали, во сколько нам обойдется переезд с железа в облако (и я сейчас не про канистру бензина, спасибо, не нужно!). Подумали, что подобный data-driven-подход можно применить и здесь. Уж что-то, а деньги я считать отлично умею!

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

Как выглядели мои расчеты?

Посчитал дев-среды, посчитал тест-среды. Там, где у виртуализации был интерфейс, я ходил туда. Из KVM данные тащил через консоль. В итоге правильно заполненные и рассортированные таблички показали нам всю правду. Умножив 40 окружений на среднюю аллокацию, получили 1000 ядер и терабайт RAM – а на гипервизорах в сумме было гораздо меньше. То есть наши непродуктовые среды пытались потребить от 200% до 300% всех наличных ресурсов! Понятно, почему площадки нестабильны, а каждая авария так больно бьет по разработке.

Особенно эти таблицы хороши кристальной понятностью для бизнеса – тот же язык. Вычтя стоимость простоя команды из цены железа, я получив трезвую оценку, и довольно быстро согласовал финансирование. В общем, считать ресурсы — это полезно, стоит записать под №3.

2019 год

Напомню, что прошло уже два года. У нас были такие промежуточные итоги:

• Мы завершили пилотные этапы с дев- и тест-площадками.

• Устали от двойной поддержки. В какой-то момент психанули, приняли волевое решение удалить все старые дев-площадки, а разработчиков одним днем перевести на новые. И все прошло на удивление гладко: пару дней побурчали в чатиках, но прекрасно перешли на новые площадки. 

• На этом этапе мы поняли, что стоит идти на разумные компромиссы в соответствии тестовых сред продакшену. 

• Наняли еще несколько инженеров (потому что все эти годы трафик, выручка и инфраструктура тоже изрядно росли).

Осталось всего ничего:

• Сделать тестовые среды и связанные с ними процессы удобнее и быстрее.

• Придумать какую-нибудь классную фичу новых площадок.

Подводные камни

Как-то неожиданно выяснилось, что у нас распух второй монолит, который по плану должен был быть поджарым и эффективным.

Когда мы начали разбираться с его пайплайнами CI/CD, выяснилось, что на каждый коммит запускается сборка — бэкенда и фронтенда (composer & npm). Кроме того, запускаются юнит-тесты с 5–6 планами, каждый из которых тоже требует сборки. В итоге одна и та же версия приложения собиралась минимум 7 раз на каждый пуш в репозиторий (а в некоторых случаях – десятки раз).

Всё это происходило прямо на тестовых машинах, из-за чего пользоваться тестовой средой во время выкладки было практически невозможно. Тесты же, в свою очередь, собирались на Бамбе (зачастую на 1-2 агентах из 5 доступных) и ощутимо воевали за серверные ресурсы, а также перегружали репозиторий. Очевидным решением стало простое приведение пайплайнов к лучшим практикам: вынести процесс сборки из деплоя, сохранять результаты как артефакты и переиспользовать их и для релизов, и для тестов.

Поиск узких мест позволил нам сделать несколько важных метрик вроде “средней скорости подготовки тестовой среды”. Оказывается, если контролировать метрики, можно узнать много интересного! Так мы провели около недели в поисках других “бутылочных горлышек”. К примеру, выяснили, что из-за старого легаси у нас были сборочные агенты, очень близкие к разным частям старого продакшена (еще puppet/freeBSD). Они были одновременно и сложными для поддержки, и почти незагруженными (но исправно требовали лимита лицензий). Мы переделали сборочный конвейер на универсальные агенты, и процесс пошёл значительно быстрее (раз так в десять). Запишу под №4: иногда просто наклонировать юнитов – хороший план.

Миграция продакшена.

На этом этапе мы решили, что приводить среды к общему знаменателю можно с двух сторон, и приступили к миграции продакшена (этап 7). Разбирать инциденты между FreeBSD и Centos 6 надоело, а постепенное увеличение количества бэкэндов начало напрягать пожилой puppet-сервер. К тому же с масштабированием там были врожденные сложности.

Внезапно оказалось, что продакшен мигрировать гораздо проще. В том числе потому, что можно включать зеркалирование трафика и по статусам ответов сразу понимать, работает у тебя сервис или нет. Балансировка позволяет вводить или выводить новые инстансы: ввел, посмотрел, не работает — вывел.

Гибридный деплой было сделать совсем просто. К старым планам деплоя мы просто добавили еще одну зависимость. За счет общих точек балансировки (api gateway, load balancer) мы без проблем могли разливать трафик между старыми и новыми нодами в любых пропорциях.

2020 год

Трудный год для всего человечества, но конкретно наша компания в технологическом плане достигла большого прогресса. Наверное, массовая удаленка и 2-3 часа для жизни, которые больше не приходилось тратить на дорогу, помогли :)

Во-первых, появилась небольшая команда «Платформы», начавшая компетентно и вдумчиво решать и разбирать “ничейные” проблемы, которые было сложно отнести к какому-то конкретному бизнес-сервису (и на которые поэтому никогда не было времени у продуктовых команд).

Во-вторых, в 2019 году Atlassian зарелизил Bamboo 6.9, выкатив вторую версию yaml-пайплайнов, а также пофиксив кучу багов в реализации java specs. Я был в полнейшем восторге и за несколько ночей написал оркестратор планов деплоя на Java-спеках, а для приложений предложил концепцию хранения пайплайнов внутри репозитория сервиса. Идея всем понравилась, и примерно за год мы отдали управление сборками самим разработчикам. 

В-третьих, мы еще раз повторили идею с клонированием юнитов и добавили десяток новых сборочных агентов, сильно ускорив все процессы. По моим расчетам, годовая лицензия окупилась за пару недель чисто за счет сокращения времени на тестирование.

В-четвертых, к нам еще до пандемии пришли солидные дядьки в костюмах, предлагали за кучу денег сделать систему приготовления снэпшотов баз данных для тестов. Мы взвесили все за и против и сделали свою систему “Золотых образов” на базе Бармана, мощного колдунства и фишек файловой системы.

Поскольку все нововведения работали только на новых площадках, коллеги всё чаще сами просили переделать им тестовые среды на новые, и к концу года мы почти всех перевезли. Пишем в блокнот под №5: полезно найти активных и деятельных союзников.

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

Так что начале 2021-го мы успешно перешли на новый stage и торжественно погасили Puppet-сервер (даже заказали в офис вкуснях, чтобы отметить). С наслаждением разобрали, пропатчили и заапдейтили старые гипервизоры, на которых потом развернули новые “склянки” заждавшимся командам.

Итоги из 2025

Приятно, что многие цели, которые казались невыполнимыми, удалось реализовать и даже немножко перевыполнить.

Хотели и получили:

• Одна ОС

• Одна система виртуализации

• Новый сервис за короткий срок. Начинали с нескольких часов, сейчас умеем делать менее чем за 10 минут.

• Включили разработчиков в девопс-процессы. Они начали контрибьютить в репозиторий с конфигами и самостоятельно вносить изменения в пайплайны своих сервисов.

А еще:

• Уменьшили время развертывания монолитов с 40 минут до 11 минут.

  • И начали это время измерять

  • А потом (уже в 24-25-м) избавились от монолитов!

• Отделили билд-планы от деплоя и вынесли в репозитории сервисов.

  • А потом научились шаблонизировать и управлять централизованно

• Создали гибридную среду: VM + K8S. 

• Сократили во много раз оверхед на поставку БД.

• Сделали настоящую платформу для роста количества микросервисов.

  • По 30-40 новых сервисов в месяц

• Обновили технологический стек.

  • И готовы повторить.

За 4 года трансформации технологической платформы наш департамент вырос раза в 4, а количество виртуалок – в 10. За следующие 4 года мы выросли еще вдвое, а в количестве сервисов – почти впятеро. Ну, и языков программирования в стеке прибавилось, вот как-то так:

Рефлексия / Письмо самому себе в 2017-ый

Ох, если бы у нас была возможность вернуть наш 2017 и все сделать по-другому! Давайте откроем наши заметки и напишем записку себе в прошлое?

«Привет, я – это ты, пишу тебе из будущего. У тебя всё получится, но будет гораздо легче, если ты последуешь моим рекомендациям.

Первое. Полезные советы 

1) Ищи “быстрые победы” для пилота новой парадигмы.
Не надо начинать переделывать виртуалки или мигрировать базы, лучше посмотри, где есть какие-то болезненные проблемы, и реши их. 

2) Не получится быстро переехать на другую платформу: сразу обдумывай “гибридную схему”.
– Как будешь жить с двумя системами (кластерами, ДЦ)?
– Как будешь их синхронизировать?

3) Считай!
– "Медленно" — понятие субъективное. Нестабильно – тоже. Измеряй!
– Посчитай железо.
– Посчитай людей. И себя, кстати, тоже. “Вихрь неотложных дел” обязательно сдвинет сроки, вопрос – насколько?

4) Если проблему можно решить/отложить ресурсами в моменте – просто делай. Клонировать и масштабировать – ровно то, зачем мы вообще полезли в SOA! 

5) Найди себе союзников, которые будут помогать.
Создай рабочую группу, гильдию, клуб "по пропушиванию" изменений.

Второе. Как планировать технологическую миграцию?

Не забудь этапы тестирования и доработок после каждого пилота. Их стоит оценивать как х2-3 от времени разработки: всегда будут сложные, новые, ранее невиданные проблемы. Готовься, что пилотов будет несколько, на разных средах. 

Расставь приоритеты правильно: production – самая важная среда, источник истины. Попробуй начать смену платформы “сверху” – дальше нагрузка будет только больше, а риски – выше. Продавать новые среды тестировщикам с рекламой “они точнее повторяют прод” – ощутимо проще.

Старый план распечатай на мягкой бумаге, в 20-м пригодится.

Третье. Как лучше пилотировать новшества?

1) Рисуй схемы, собирай экспериментальные стенды;

2) Понаблюдай за реальными разработчиками. Возможно, получится еще на этапе пилота решить какую-то серьезную боль;

3) Если есть проблемы, ищи root cause, не плоди “костыли”. Тебе же с ними жить. Скрытые баги “кусают” за мягкие места всегда не вовремя (а еще срывают сроки и портят репутацию команды);

4) Бизнес любит схемы и таблицы и не верит ощущениям. Помни про совет № 3!

5) Не будь перфекционистом, ты стартапер: важно быстро запустить MVP и собрать фидбек. 

Четвертое. Как это всё внедрить?

1) Введи измеримые метрики;

2) Продолжай наблюдать за стейкхолдерами и их реальной работой;

3) Если ты еще не выбил себе разработчика или хотя бы его ресурс в команду – сделай это, очень поможет;

4) Не жди удобного момента для дня Х (переключить что-нибудь куда-нибудь). Его не будет никогда. Согласуй ночные работы, подключайся в выходные – за это еще и платят больше!

5) Коммуникация! Совет № 5 не сработает, если не инвестировать время и фантазию в ликбез для коллег. Проводи обучения, демо, выступай с внутренними докладами – что сделали, что планируете;

6) Выдели дежурный саппорт – всякую текучку пусть кто-то один разбирает по жребию или расписанию;

7) Общайся с интеграторами. Ходи на конференции, ищи идеи, они витают в воздухе!

8) Старайся не называть необдуманных сроков – давай регулярный статус, так всем будет лучше.

Всё, с приветом из будущего, покупай биткоин, пока!»

Эпилог

Что хотелось бы добавить. Мы работаем с технологиями в некотором симбиозе, и, как правило, это отношения “по любви”. Нельзя написать ничего хорошего на языке, который ты ненавидишь. Если тебя бесит инструмент, с которым ты работаешь, то и результаты будут так себе. Поэтому великие приложения написаны фанатами своего дела, которые пишут код как симфонию.

Иногда бывает так, что ранее классная технология перестает быть “твоей”, и надо “разводиться”. Как у нас с puppet’ом. Тогда наступает время технологической трансформации. Это будет неизбежно, дорого, долго, больно, очень интересно и, надеюсь, не стыдно. Выберите любые все + бонусом какую-нибудь неприятную неожиданность. 

Слушайте себя, доверяйте честным цифрам и не бойтесь пробовать новое!