— Карапет, что такое в современном понимании DevOps?

— Если говорить о современном DevOps, необходимо сделать шаг назад и разобраться в том, какие методологии разработки цифровых продуктов применялись ранее. Их основным минусом была длительность процесса.

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

Но поскольку технологическое развитие резко ускорилось, а изменения в код в целях скорейшего вывода на рынок продуктовых и сервисных новинок требуется вносить постоянно (едва ли не каждый день), стали внедряться новые подходы к разработке. В их составе сейчас достойное место занимают DevOps-практики и platform engineering, которые показывают выдающиеся результаты в ускорении процессов.

Но не только ускорение можно занести в актив этой практики. На сегодняшний день стало must have иметь инструменты для безопасной разработки цифровых продуктов, что порой находит свое отражение в нормативных актах самых разных регуляторов в области кибербезопасности. Поэтому в финансовой сфере стало принято аббревиатуру DevOps расширять до DevSecOps, хотя считается, что по умолчанию в DevOps заложена частица «Sec». Сегодня никому не нужен «дырявый» и дефектный код.

— Может ли MOEX обойтись без Agile и DevOps?

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

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

Поэтому Agile и DevOps, по моему убеждению, больше дополняют друг друга, нежели друг другу противостоят.

А главное, обе эти методологии изменяют прежде всего культуру компании. Заметьте, культуру не одного IT-подразделения, а компании в целом. Поэтому те банки, которые успешно внедрили Agile, чувствуют себя гораздо увереннее с DevOps, так как уже были созданы все условия для формирования команд и набора ими компетенций. Очень важна и поддержка топ-менеджмента, а он ориентируется на результаты успешных проектов. И лидерам рынка, поверьте, есть что показать и своим менеджерам, и управленцам извне, а также регуляторам.

— Где можно погрузиться в лучшие инженерные практики?

— Большие компании, как правило, сами строят свои платформы разработки, развивают инженерную культуру и хранят накопленную экспертизу у себя. У всех остальных нет такой возможности, да и компаниями с 20–30 разработчиками платформа не всегда востребована. А вот экспертиза нужна всегда. Где можно ее почерпнуть? Во-первых, на различных IT-конференциях и мероприятиях. Во-вторых, в отраслевых комьюнити, где формируется концентрированный опыт. В-третьих, в открытых фреймворках. В авторском фреймворке Platen я постарался описать основные подходы создания платформ разработки. Он предназначен для создания и развития DevOps-платформ, а также для трансформации и улучшения текущих инженерных процессов компании. В основу Platen положен максимально простой принцип, который подразумевает движение от хаотичных изменений к упорядоченному набору коротких и понятных процессов.

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

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

— Как Московская биржа запускала сообщество FinDevSecOps (findevsecops.ru) на площадке Ассоциации Финтех?

— В конце 2022 года мы предложили создать сообщество безопасной разработки FinDevSecOps, чтобы обмениваться практиками в финтехе и смежных отраслях. Идею активно поддержала вся финансовая отрасль. В комьюнити мы делимся с коллегами своими компетенциями: «Вот, смотрите, мы сделали так, и оно хорошо работает; вы можете у себя это уже не изобретать, а свободно брать готовые практики из сообщества FDSO». За 2024 год мы провели три крупных митапа и пять практических воркшопов, разработали два значимых артефакта (типовой процесс безопасной разработки, а также карту инструментов DevSecOps). В сообщество входят 19 компаний, из них активных лидеров — уже 11, при этом более 100 участников-экспертов из разных финансовых компаний. Важно отметить, что в ноябре 2024 года в рамках FDSO был проведен первый в России хакатон по безопасной разработке. Это был уникальный формат соперничества и нетворкинга. Результаты деятельности сообщества — колоссальный рост не только для финансовой, но и для других отраслей.

Немаловажно и то, что DevOps имеет некоторую стоимостную оценку, которая при правильном использовании может из затратной компоненты превратиться в прибыльную.

Есть постулат: DevOps в связке с Agile ускоряет разработку, что приводит к сокращению временной дистанции между стартом продукта и получением его клиентом. Если дистанция маленькая и налажено быстрое получение обратной связи, то разработчики своего клиента не теряют и в итоге зарабатывают.

Кстати, об изменении культуры. Если раньше какой-то цифровой продукт разрабатывался, допустим, полгода, а затем столько же его тестировали и только потом выпускали на рынок, а он там оказывался уже устаревшим и не востребованным, это означало финансовые потери всей организации. И вот здесь как раз культура гибких практик, шаринга экспертизы внутри сообществ, использование удобных инструментов помогают ускоряться. АФТ позволяет собрать вокруг себя тех специалистов в области безопасной разработки, которые глубоко погружены в финансовую специфику, что дает возможность с учетом всех требований Банка России как минимум не наступать на одни и те же грабли, а эффективнее двигаться вперед. В ядре проекта — уже 11 человек из топовых банков, финтехов и IT-компаний, которые «драйвят» проект на добровольной основе при минимуме жестких регламентов. По-другому комьюнити не выстраиваются. Сообщества нельзя формализовать. Как только начинается бюрократия, процесс разваливается.

Карапет Манасян, глава платформы разработки Группы «Московская Биржа»

Сейчас мы пытаемся имплементировать регуляторику на технику, то есть совместными усилиями «приземлять» процессы безопасной разработки на те IT-инструменты, процессы и автоматизацию, которые распространены в индустрии. Планы у нас амбициозные: cформировать базу знаний сообщества, создать методологию безопасной разработки в финтехе на базе типового процесса, развивать совместные проекты в Репозитории АФТ, запустить курсы по безопасной разработке и выработать бенчмаркинг по инструментам и практикам.

— Проводились «пилоты» DevOps-платформы, созданной на Московской бирже, в остальных компаниях Группы. Каковы результаты?

— Если коротко, то мы сейчас строим платформу на всю Группу компаний. Это IT-решение родилось и развивалось на Московской бирже, затем его стали масштабировать с использованием наиболее передовых технологий, в частности на базе модели platform engineering. Это процесс создания и предоставления удобных сервисов самообслуживания IT-командам и инженерам в целях ускорения потока создания ценностей, снижения объема их нецелевых активностей, а также повышения качества, надежности и безопасности создаваемых решений.

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