Практики DevOps работают. Мы убедились в этом сами, когда сократили время установки релизов в 10 раз. В системе FIS Profile, которую мы используем в ВТБ, установка теперь занимает не 90 минут, а 10. Время сборки релиза снизилось с двух недель до двух дней. Число постоянных дефектов внедрения при этом упало почти до минимума. Чтобы уйти от «ручного труда» и устранить зависимость от вендора, нам пришлось пройти через работу с костылями и найти неожиданные решения. Под катом — подробная история о том, как мы построили полноценную внутреннюю разработку.
За минувший год с небольшим мы провели немалую работу по организации внутренней разработки и внедрения практик DevOps в ВТБ:
Одной из самых сложных для организации inhouse-разработки и внедрения практик DevSecOps оказалась система FIS Profile — розничный продуктовый процессор на нереляционной СУБД. Тем не менее мы смогли построить разработку, запустить pipeline, выполнить установку на продуктив отдельных внерелизных пакетов и научились собирать релизы. Задача была непростая, но зато интересная и без явных ограничений в реализации: вот система — нужно построить inhouse-разработку. Единственное условие — использовать CD до продуктивной среды.
Поначалу алгоритм реализации казался простым и понятным:
За это время команда разработчиков необходимой численности должна наработать скилы и повысить долю своего вклада в релизы до приемлемого уровня. И все, можно считать задачу выполненной.
Казалось бы, вполне себе энергоэффективный путь к требуемому результату: вот DevOps, вот метрики производительности команды, вот набранная экспертиза… Но на практике мы получили очередное подтверждение того, что DevOps — это все-таки про философию, а не «прикрутить к процессу gitlab, ansible, nexus и далее по списку».
В очередной раз проанализировав план действий, мы поняли, что строим внутри себя некий аутсорс вендора. Поэтому в описанный выше алгоритм добавили реинжиниринг процессов, а также наработку экспертизы по всему маршруту разработки для достижения ведущей роли в этом процессе. Не самый простой вариант, но таков путь идеологически правильной разработки.
Работать предстояло с далеко не самой дружелюбной системой. Архитектурно она представляла собой одну большую нереляционную СУБД, состояла из множества отдельных исполняемых объектов (скриптов, процедур, батчей и т. д.), которые вызывались по необходимости, и работала по принципу черного ящика: получает запрос — выдает ответ. Среди других сложностей стоит отметить:
При этом репозиторий исходного кода на нашей стороне отсутствовал. Совсем. Документация имелась, но все ключевые знания и компетенции были на стороне внешней организации.
К освоению разработки по системе мы приступили практически с нуля, учитывая ее особенности и слабое распространение. Начали в октябре 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 технических — версий, полученных при добавлении или исключении чего-либо из релиза и отражении изменений прода внерелизами.
Объекты внутри поставок пересекались между собой, особенно в части исполняемого кода, который был уникален менее чем наполовину. Было множество зависимостей как от уже поставленного кода, так и от того, установка которого только планировалась.
После установки партии пакетов приходилось вручную выполнять инструкции по инициализации настроечных параметров. Релиз собирал и устанавливал вендор. Состав релиза уточнялся практически до момента внедрения, что влекло за собой создание «развязочных» пакетов. В результате заметная часть поставок переезжала из релиза в релиз со своим хвостом «развязок».
Теперь понятно, что при таком подходе — сборке релизного пазла на уровне пакетов — единая master-ветвь не имела практического смысла. Установка на прод занимала от полутора до двух часов ручного труда. Хорошо, что хотя бы на уровне установщика задавался порядок обработки объектов: поля и структуры заезжали раньше, чем данные для них и процедуры. Впрочем, это работало только в рамках отдельного пакета.
Логичным результатом такого подхода были обязательные дефекты установки в виде кривых версий объектов, лишнего кода, пропущенных инструкций и неучтенных взаимовлияний объектов, которые лихорадочно устранялись после релиза.
Автоматизацию начали с передачи кода через трубу по такому маршруту:
Следующий pipeline должен зарегистрировать задачу в Jira и ожидать команды для разливки на выбранные контуры тестирования, которые зависят от сроков внедрения задачи. Триггер — письмо о готовности поставки на заданный адрес. Это, конечно, был явный костыль, но с чего-то нужно было начать. С мая 2019 началась передача кода с проверками на наших средах. Процесс пошел, осталось привести его в приличный вид:
После этого шли уже существующие шаги по проверке и передаче кода, по запуску трубы и сборке на нашей стороне.
Данный вариант запустили в июле. Трудности перехода повлекли за собой некоторое недовольство вендора и фронт-линии, но за следующий месяц нам удалось убрать все шероховатости и наладить процесс в командах. У нас появилась сборка по коммиту и доставка.
В августе удалось выполнить первую установку отдельного пакета на прод средствами нашего pipeline, а с сентября все без исключения установки отдельных внерелизных пакетов выполнялись через наше средство CD. Кроме того, нам удалось достичь доли inhouse задач в 40% состава релиза при меньшей по численности, чем у вендора, команде — это определенный успех. Оставалась самая серьезная задача — собрать и установить релиз.
Мы прекрасно понимали, что скриптовать инструкцию вендора — так себе автоматизация, нужно было переосмыслить сам процесс. Решение лежало на поверхности — собирать кумулятивную поставку из релизной ветви со всеми объектами нужных версий.
Начали с proof of concept: собрали руками релизную поставку по составу прошедшего внедрения и выполнили ее установку на наших средах. Все получилось, концепция оказалась жизнеспособна. Далее решили вопрос со скриптованием инициализирующих настроек и включением их в коммит. Подготовили новый пакет и проверили его уже на средах тестирования в рамках обновления контура. Установка была успешной, хоть и с обширным рядом замечаний от команды внедрения. Но главное, что нам дали добро на выход в продуктив в ноябрьском релизе с нашей сборкой.
Оставалось чуть больше месяца, собранные вручную поставки прозрачно намекали, что времени в обрез. Сборку решили делать из релизной ветви, но от чего ее отбранчевать? Prod-like у нас нет, а существующие ветви не годятся — много лишнего кода. Надо срочно пилить prod-like, а это свыше трех тысяч коммитов. Собирать руками — вообще не вариант. Набросали скрипт, который бежит по логу установки продуктива и набирает коммиты в ветвь. Раза с третьего он сработал корректно, и после «доработки напильником» ветвь была готова.
Сборщик установочного пакета написали свой, справились за неделю. Потом пришлось дорабатывать установщик из core-функциональности системы, благо она open-source. После ряда проверок и доработок результат признали успешным. Тем временем оформился состав релиза, для корректной установки которого пришлось выравнивать тестовый контур с продуктивом, написали для этого отдельный скрипт.
Дополнительная сложность заключалась в большом количестве внерелизов, которые приходилось учитывать. Но с Prod-like ветвью и Rebase задача стала прозрачной.
К моменту релиза мы подошли с оптимистичным настроем и более чем десятком успешных установок на разные контуры. Но буквально за сутки до срока оказалось, что вендор не выполнил работы по подготовке релиза к установке принятым способом. Если по каким-то причинам наша сборка не зайдет, то релиз будет сорван. Причем нашими стараниями, что особенно неприятно. Путей для отступления у нас не было. Поэтому мы продумали альтернативные варианты, подготовили планы действий и начали установку.
Весь следующий день в релизном чате царила тишина: никаких проблем внедрения, кривых версий или «левого» кода. Даже как-то неловко было. Позже вылезли отдельные замечания, но на фоне других систем и предыдущего опыта их количество и приоритетность были заметно ниже.
Дополнительным эффектом от кумулятива оказалось повышение качества сборки и тестирования. За счет многократных установок полного релиза своевременно выявлялись дефекты сборки и ошибки развертывания. Тестирование в полных релизных конфигурациях позволило дополнительно выявлять дефекты взаимовлияния объектов, которые не проявлялись при инкрементальных установках. Это определенно был успех, особенно на фоне нашего вклада в релиз на уровне 57%.
Менее чем за год нам удалось:
Разумеется, многое из описанного выглядит как откровенная костылизация, но таковы особенности системы и существующие в ней процессные ограничения. На данный момент изменения коснулись продуктов и сервисов ИС Profile (мастер-счета, пластиковые карты, накопительные счета, эскроу, кредит наличными), но потенциально подход можно применить к любой ИС, для которой поставлена задача внедрения практик DevOps. Кумулятивную модель можно смело тиражировать на последующие внедрения (в том числе внерелизные) из множества поставок.
Пролог: 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. Кумулятивную модель можно смело тиражировать на последующие внедрения (в том числе внерелизные) из множества поставок.
