#DevOpsConf Карапет Манасян из MOEX Group. Сколько стоит платформа? Вопреки названию, доклад - не про деньги, он про процессы, обеспечивающие платформенный подход, которые надо наладить. Конечно, процессы стоят денег, но это не главное. Рассказ был о построении платформенной конструкции в рамках MOEX Group. При этом типовой платформенный подход с полной однородностью процессов и единым технологическим стеком у них не подходит, так как бизнес - существенно гетерогенный, есть торговые решения с длинным релизным циклом, есть финтех с коротким тестированием гипотез и есть критическая инфраструктура со своими требованиям регулятором. Тем не менее, они рассматривают сделанное именно как платформу, а не как работу DevOps инженеров.

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

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

Структура команды платформы: change team, которая помогает командам трансформироваться, собирает запросы и обеспечивает поддержку; feature team доработки платформы и core platform, отвечающая за технологические стандарты и единые политики. Всего в ней 26 человек, еще 8 devops-инженеров в конкретных продуктовых командах, что связано со спецификой отдельных продуктов. Задачи от продуктовых команд поступают тремя способами: таск-трекер, демо-встречи платформы и заявки. Дальше идет анализ, как решить поставленную проблему, что стоит делать в платформе, а что команда может сделать, используя существующие возможности.

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

Что достигли: единая точка правды инженерных практик - в платформе; от 50+ devops инженеров сократилось до 26; разработчикам стало видно что происходит на проде, эту границу сняли; платформа обеспечивает публикацию по требованию и выделение ресурсов для тестирования. И видно, что с ростом разработки линейного роста команды платформы не происходит, а по devops - было. Инженеров платформы надо обучать внутри, готовой такой специализации на рынке нет, если искать - то в вакансиях надо писать devops, отбирать и это не дешево.