company_banner

Как с помощью DevOps построить полноценную inhouse-разработку — опыт ВТБ

    Практики DevOps работают. Мы убедились в этом сами, когда сократили время установки релизов в 10 раз. В системе FIS Profile, которую мы используем в ВТБ, установка теперь занимает не 90 минут, а 10. Время сборки релиза снизилось с двух недель до двух дней. Число постоянных дефектов внедрения при этом упало почти до минимума. Чтобы уйти от «ручного труда» и устранить зависимость от вендора, нам пришлось пройти через работу с костылями и найти неожиданные решения. Под катом — подробная история о том, как мы построили полноценную внутреннюю разработку.


     

    Пролог: DevOps — это философия


    За минувший год с небольшим мы провели немалую работу по организации внутренней разработки и внедрения практик DevOps в ВТБ:

    • Выстроили процессы внутренней разработки по 12 системам;
    • Запустили 15 pipeline, четыре из которых довели до продуктива;
    • Автоматизировали 1445 сценариев тестирования;
    • Успешно внедрили ряд релизов, подготовленных инхаус-командами.

    Одной из самых сложных для организации inhouse-разработки и внедрения практик DevSecOps оказалась система FIS Profile — розничный продуктовый процессор на нереляционной СУБД. Тем не менее мы смогли построить разработку, запустить pipeline, выполнить установку на продуктив отдельных внерелизных пакетов и научились собирать релизы. Задача была непростая, но зато интересная и без явных ограничений в реализации: вот система — нужно построить inhouse-разработку. Единственное условие — использовать CD до продуктивной среды.

    Поначалу алгоритм реализации казался простым и понятным:

    • Нарабатываем начальную экспертизу разработки и добиваемся от команды кода приемлемого уровня качества без грубых дефектов;
    • Максимально встраиваемся в существующие процессы;
    • Для передачи кода между очевидными этапами пилим pipeline и упираем его одним из концов в прод.

    За это время команда разработчиков необходимой численности должна наработать скилы и повысить долю своего вклада в релизы до приемлемого уровня. И все, можно считать задачу выполненной.

    Казалось бы, вполне себе энергоэффективный путь к требуемому результату: вот DevOps, вот метрики производительности команды, вот набранная экспертиза… Но на практике мы получили очередное подтверждение того, что DevOps — это все-таки про философию, а не «прикрутить к процессу gitlab, ansible, nexus и далее по списку».

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

    С чего начинается inhouse-разработка 


    Работать предстояло с далеко не самой дружелюбной системой. Архитектурно она представляла собой одну большую нереляционную СУБД, состояла из множества отдельных исполняемых объектов (скриптов, процедур, батчей и т. д.), которые вызывались по необходимости, и работала по принципу черного ящика: получает запрос — выдает ответ. Среди других сложностей стоит отметить:

    • Экзотический язык (MUMPS);
    • Консольный интерфейс;
    • Отсутствие интеграции с популярными средствами автоматизации и фреймворками;
    • Объем данных в десятки терабайт;
    • Нагрузку свыше 2 млн операций в час;
    • Значимость — Business-Critical.

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

    • Изучили документацию и основы кодогенерации;
    • Проштудировали полученный от вендора краткий курс по разработке;
    • Освоили начальные скилы разработки;
    • Составили методичку для новых участников команды;
    • Договорились о включении команды в работу в «боевом» режиме;
    • Решили вопрос с контролем качества кода;
    • Организовали стенд для разработки.

    На наработку экспертизы и погружение в систему мы потратили три месяца, а уже с начала 2019 года inhouse-разработка начала свое движение навстречу светлому будущему, иногда со скрипом, но уверенно и целенаправленно.

    Миграция репозитория и автотесты


    Первая задача DevOps — репозиторий. О предоставлении доступа договорились быстро, но нужно было выполнить миграцию из текущего SVN с одной trunk-ветвью в целевой для нас Git с переходом на модель из нескольких ветвей и проработкой Git Flow. А еще у нас 2 команды со своей инфраструктурой плюс часть команды вендора за границей. Пришлось жить с двумя Git’ами и обеспечить синхронизацию. В такой ситуации это было меньшее из зол.

    Миграция репозитория неоднократно откладывалась, выполнили ее только к апрелю не без помощи коллег из фронт-линии. С Git Flow решили для начала не мудрить, остановились на классической схеме с hotfix, develop и release. От master (он же prod-like) решили отказаться. Ниже мы объясним, почему такой вариант оказался для нас оптимальным. В качестве рабочего использовали внешний репозиторий, принадлежащий вендору, единый для двух команд. Он синхронизировался с внутренним репозиторием по расписанию. Теперь с Git и Gitlab можно было заниматься автоматизацией процессов.

    Вопрос автотестов решился на удивление легко — нам предоставили готовый фреймворк. С учетом особенностей системы вызов отдельной операции представлял собой понятную часть бизнес-процесса и параллельно являлся unit-тестом. Оставалось подготовить тестовые данные и задать нужный порядок вызова сценариев с оценкой результатов. По мере наполнения перечня сценариев, сформированного на основе статистики выполнения операций, критичности процессов и существующей методики регресса, начали появляться автотесты. Теперь можно было начинать заниматься построением pipeline.

    Как было: модель до автоматизации


    Сложившаяся модель процесса внедрения — отдельная история. Каждая доработка вручную передавалась в виде самостоятельного инкрементального установочного пакета. Далее шла ручная регистрация в Jira и ручная установка на среды. Для отдельных пакетов все выглядело понятно, но с подготовкой релиза дела обстояли сложнее.

    Сборка выполнялась на уровне отдельных поставок, которые являлись самостоятельными объектами. Любое изменение — новая поставка. Помимо прочего, к 60–70 пакетам основного состава релиза добавлялось 10–15 технических — версий, полученных при добавлении или исключении чего-либо из релиза и отражении изменений прода внерелизами.

    Объекты внутри поставок пересекались между собой, особенно в части исполняемого кода, который был уникален менее чем наполовину. Было множество зависимостей как от уже поставленного кода, так и от того, установка которого только планировалась. 

    Для получения нужной версии кода требовалось строго соблюдать порядок установки, в ходе которой объекты многократно перезаписывались физически, некоторые по 10–12 раз.

    После установки партии пакетов приходилось вручную выполнять инструкции по инициализации настроечных параметров. Релиз собирал и устанавливал вендор. Состав релиза уточнялся практически до момента внедрения, что влекло за собой создание «развязочных» пакетов. В результате заметная часть поставок переезжала из релиза в релиз со своим хвостом «развязок».

    Теперь понятно, что при таком подходе — сборке релизного пазла на уровне пакетов — единая master-ветвь не имела практического смысла. Установка на прод занимала от полутора до двух часов ручного труда. Хорошо, что хотя бы на уровне установщика задавался порядок обработки объектов: поля и структуры заезжали раньше, чем данные для них и процедуры. Впрочем, это работало только в рамках отдельного пакета.

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

    Первые обновления: сборка по коммиту и доставка


    Автоматизацию начали с передачи кода через трубу по такому маршруту:

    • Забрать готовую поставку из хранилища;
    • Установить ее на выделенную среду;
    • Прогнать автотесты;
    • Оценить результат установки;
    • Вызвать следующий pipeline на стороне команды тестирования.

    Следующий pipeline должен зарегистрировать задачу в Jira и ожидать команды для разливки на выбранные контуры тестирования, которые зависят от сроков внедрения задачи. Триггер — письмо о готовности поставки на заданный адрес. Это, конечно, был явный костыль, но с чего-то нужно было начать. С мая 2019 началась передача кода с проверками на наших средах. Процесс пошел, осталось привести его в приличный вид:

    • Каждая доработка выполняется в отдельной ветви, которая соответствует установочному пакету и вливается в целевую мастер-ветвь;
    • Триггер запуска pipeline — появление нового коммита в мастер-ветви через merge request, который закрывают мейнтейнеры из команды инхаус;
    • Синхронизация репозиториев происходит раз в пять минут;
    • Запускается сборка установочного пакета — при помощи сборщика, полученного от вендора.

    После этого шли уже существующие шаги по проверке и передаче кода, по запуску трубы и сборке на нашей стороне.

    Данный вариант запустили в июле. Трудности перехода повлекли за собой некоторое недовольство вендора и фронт-линии, но за следующий месяц нам удалось убрать все шероховатости и наладить процесс в командах. У нас появилась сборка по коммиту и доставка.
    В августе удалось выполнить первую установку отдельного пакета на прод средствами нашего pipeline, а с сентября все без исключения установки отдельных внерелизных пакетов выполнялись через наше средство CD. Кроме того, нам удалось достичь доли inhouse задач в 40% состава релиза при меньшей по численности, чем у вендора, команде — это определенный успех. Оставалась самая серьезная задача — собрать и установить релиз.

    Финальное решение: кумулятивные установочные пакеты 


    Мы прекрасно понимали, что скриптовать инструкцию вендора — так себе автоматизация, нужно было переосмыслить сам процесс. Решение лежало на поверхности — собирать кумулятивную поставку из релизной ветви со всеми объектами нужных версий.

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

    Оставалось чуть больше месяца, собранные вручную поставки прозрачно намекали, что времени в обрез. Сборку решили делать из релизной ветви, но от чего ее отбранчевать? Prod-like у нас нет, а существующие ветви не годятся — много лишнего кода. Надо срочно пилить prod-like, а это свыше трех тысяч коммитов. Собирать руками — вообще не вариант. Набросали скрипт, который бежит по логу установки продуктива и набирает коммиты в ветвь. Раза с третьего он сработал корректно, и после «доработки напильником» ветвь была готова. 

    Сборщик установочного пакета написали свой, справились за неделю. Потом пришлось дорабатывать установщик из core-функциональности системы, благо она open-source. После ряда проверок и доработок результат признали успешным. Тем временем оформился состав релиза, для корректной установки которого пришлось выравнивать тестовый контур с продуктивом, написали для этого отдельный скрипт.

    Естественно, к первой установке было много замечаний, но в целом код «заехал». А уже примерно с третьей установки все стало неплохо смотреться. Контроль состава и версионность объектов отслеживали отдельно в ручном режиме, что на данном этапе было вполне оправданно.

    Дополнительная сложность заключалась в большом количестве внерелизов, которые приходилось учитывать. Но с Prod-like ветвью и Rebase задача стала прозрачной.

    С первого раза, быстро и без ошибок


    К моменту релиза мы подошли с оптимистичным настроем и более чем десятком успешных установок на разные контуры. Но буквально за сутки до срока оказалось, что вендор не выполнил работы по подготовке релиза к установке принятым способом. Если по каким-то причинам наша сборка не зайдет, то релиз будет сорван. Причем нашими стараниями, что особенно неприятно. Путей для отступления у нас не было. Поэтому мы продумали альтернативные варианты, подготовили планы действий и начали установку.

    Удивительно, но весь релиз, состоящий из 800 с лишним объектов, заехал корректно, с первого раза и всего за 10 минут. Целый час мы выверяли логи в поисках ошибок, но не нашли ни одной.

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

    Дополнительным эффектом от кумулятива оказалось повышение качества сборки и тестирования. За счет многократных установок полного релиза своевременно выявлялись дефекты сборки и ошибки развертывания. Тестирование в полных релизных конфигурациях позволило дополнительно выявлять дефекты взаимовлияния объектов, которые не проявлялись при инкрементальных установках. Это определенно был успех, особенно на фоне нашего вклада в релиз на уровне 57%.

    Итоги и выводы


    Менее чем за год нам удалось:

    • Построить полноценную внутреннюю разработку по экзотической системе;
    • Устранить критическую зависимость от вендора;
    • Запустить CI/CD для весьма недружелюбного legacy;
    • Поднять на новый технический уровень процессы внедрения;
    • Заметно сократить длительность развертывания;
    • Значительно уменьшить количество ошибок внедрения;
    • Уверенно заявить о себе как о ведущей экспертизе разработки.

    Разумеется, многое из описанного выглядит как откровенная костылизация, но таковы особенности системы и существующие в ней процессные ограничения. На данный момент изменения коснулись продуктов и сервисов ИС Profile (мастер-счета, пластиковые карты, накопительные счета, эскроу, кредит наличными), но потенциально подход можно применить к любой ИС, для которой поставлена задача внедрения практик DevOps. Кумулятивную модель можно смело тиражировать на последующие внедрения (в том числе внерелизные) из множества поставок.
    ВТБ
    Компания

    Комментарии 12

      +2
      DevOps, agile и другие модные штуки, а пароль в втб-онлайн как был только из цифр так и остался
        +2
        IVR на дух не переносит буквенную письменность, но прогресс неумолим, скоро на всех экранах страны!
        +2
        Надеюсь после ваших улучшений информация в личном кабинете на сайте ВТБ будет обновляться быстрее
          0

          Я б скорее надеялся, что ВТБ онлайн (банк клиент на телефон) перестанет писать регулярно, что система на обслуживании и попробуйте провести свой платеж попозже )

          +2
          Кумулятивную модель можно смело тиражировать на последующие внедрения (в том числе внерелизные) из множества поставок.
          Этим все сказано.
          В чем тут DevOps кроме самого слова? Вообще, статья показатель того «варева», которое происходит в ВТБ.
          Но на практике мы получили очередное подтверждение того, что DevOps — это все-таки про философию, а не «прикрутить к процессу gitlab, ansible, nexus и далее по списку».
          А по статье, именно этим вы и занимались.
            +2
            вот когда спрашивают что такое легаси ) вот надо вот на такие истории ссылку давать. По моему в банках самые страшные легаси.
              +1

              Термин продуктив коробит слух. Продакшн жеж. Так и не понял вывода о том, что в гит флоу мастер не нужен. Нафиг тогда вообще гит флоу в вашем случае?

                0
                С Git Flow решили для начала не мудрить, остановились на классической схеме с hotfix, develop и release.

                мастер переименовываем в develop — PROFIT :-) Вообще — да, интересно, как коллеги устроили политику наименования веток/тегов

                +1

                Херушки. Я так пробовал. В итоге написал свой git op.

                  +2

                  Автор конечно "молодец", что вынес на всеобщее обсуждение этот бардак.
                  В Сбере полный фарш сторонних скриптов, в ВТБ свой тернистый путь в космос… Интересно, банкиры чем руководствуются, собирая такие "эффективные" команды.

                    0

                    Посмотреть на это все можно было на митапе, который ВТБ организовывал буквально недавно, в Виворк на Белой площади.
                    отчет — https://habr.com/ru/company/vtb/blog/479082/
                    анонс — https://habr.com/ru/company/vtb/news/t/474752/
                    Видео с митапа мы так и не дождались

                      +1

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

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

                    Самое читаемое