Райффайзенбанк: Наша цель - выйти на сверхпроизводительность команд разработки по методологии Google

Николай Кныш, CTO розничного бизнеса Райффайзенбанка

Момент, когда ИТ перестает быть выделенным сервисом для бизнеса и становится его неотъемлемой частью, имеет четкую отсечку: у ИТ-команд появляются бизнес-KPI. Как показывает опыт мировых ИТ-компаний, это оказывает огромное влияние на скорость и качество разработки продуктов. Райффайзенбанк, который во многом стал ИТ-компанией – четверть сотрудников банка в России работает на ИТ-позициях – также накопил немало кейсов, связанных с развитием DevOps-практик.

Наш опыт показывает, что для переходgoа от взаимодействия по политикам и регламентам к совместной работе необходимы несколько лет, последовательность в развитии DevOps-подходов и активная информационная поддержка внутри банка.

Одним из первых продуктов Райффайзенбанка, в котором разработка стала вестись с использованием принципов DevOps, были кредитные карты. В 2017 году кредитная карта с нестандартным грейс-периодом в 110 дней была запущена всего за четыре месяца. До перехода на DevOps подобный проект, с учетом тестирования продукта, мог бы занять год.

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

DevOps: высокая культура быта

Значимость стандартов в DevOps еще выше при agile подходе к развитию продуктов. Работая с 25 самоорганизующимися командами, вы не можете себе позволить иметь бардак в инженерных практиках. Первое, что нужно сделать, - уделить время разработке сквозных стандартов. Когда независимые эксперты проводят оценку наших DevOps-подходов, их впечатляет проработанность наших ИТ-стандартов.

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

В московском офисе Райффайзенбанка

Сейчас мы не требуем от наших команд соответствия всему списку ИТ-стандартов, мы сфокусировались на нескольких основных, которые позволяют нам быстрее двигаться к полномасштабному внутреннему internal open source подходу. Например, это автотестирование, ревью кода и практики continuous integration\continuous delivery, а также trunk base development. Если раньше контроль над софтом был административным, то теперь это скрипты, которые автоматически подключаются к репозиториям и проверяют их.

Одной из ключевых ролей, которая появляется на этом этапе, является технический лид. Ее нет в классических scrum-моделях, однако именно эта роль позволила нам обеспечить эффективность процесса разработки и поддержки софта, а также внедрение стандартов и практик в продуктовые команды. Техлиды сыграли в них ключевые роли. Объясняя нашим ИТ-командам, что на DevOps могут перейти самые сложные платформы, мы часто приводим в пример Oracle Siebel CRM, классическую банковскую CRM-систему. По умолчанию она, возможно, является самой DevOps-неприспособленной, Siebel не предусматривает классического механизма контроля версий объектов, к нему нельзя подключить популярные статические анализаторы кода (например, SonarQube), он плохо приспособлен для внедрения автотестов и автодеплоя.Как с помощью EvaProject и EvaWiki построить прозрачную бесшовную среду для успешной работы крупного холдинга 2.4 т

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

Еще одной историей успеха была смена BPM-платформы. В Райффайзенбанке BPM-система отвечает за моделирование, исполнение и мониторинг работы кредитных конвейеров. В 2018 году мы перешли с монолитной BPM-платформы, которой пользовались на тот момент, к BPM-решению Camunda. Оно было выбрано по нескольким причинам:

• архитектура решения поддерживает DevOps по умолчанию, ее не нужно дорабатывать
• позволяет быстро выводить новые сервисы в продуктив
• платформа имеет открытые исходные коды
• поддерживает максимальный уровень автоматизации (тестирования, миграции данных)

На моменте старта перехода на Camunda регрессионное тестирование решения занимало 6 часов. Через несколько месяцев нам удалось сократить это время до 2-3 часов. Сейчас регресс запуска новых сервисов и обновлений кредитного конвейера занимает не более 1,5 часа. Таким образом, с момента старта миграции на Сamunda нам удалось сократить время регресса в 4 раза. Также удалось значительно снизить количество ошибок на продуктивной среде.

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

ИТ специалист Райффайзенбанка в подразделении в Омске

Что дальше: перспективы развития DevOps в Райффайзенбанке

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

В этом году мы перейдем к использованию OKR-модели – единых командных целей для владельца продукта, технического лида, скрам-мастера и доменного эксперта, а также команды разработки. Это позволит убрать главное противоречие между бизнесом и разработкой – бизнес сам приходит к пониманию необходимости соблюдения ИТ-стандартов, когда видит, что их несоблюдение приводит к тому, что он не может выпустить новую функциональность так быстро, как это необходимо.

Вместо заключения: 4 ошибки, которых нужно избежать в DevOps, если вы банк

1. Не игнорируйте культуру: для полноценного перехода на DevOps необходимо начинать с buy-in со стороны руководства и команд, а не с набора инструментов. Уделите этапу запуска инициативы значимое для такого большого перехода время.

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

3. Не бойтесь начинать с наиболее сложных и неприспособленных к DevOps систем и приложений, если это ваш приоритет.

4. Не используйте стандартные подходы к оргструктуре. Если вам нужны роли, которых нет в классических фреймворках – экспериментируйте и вводите их.

Источник фото - Райффайзенбанк