Привет, Хабр! На связи команда разработки App.Farm в РСХБ-Интех.
App.Farm —платформа по типу PaaS для стандартизации процесса разработки бизнес-приложений: от хранения исходного кода до запуска сервисов. App.Farm CI — подсистема обеспечивающая хранение кода, артефактов, автоматизацию сборки. В этой статье хотели бы представить вам одну из подсистем нашего продукта — PaaS App.Farm, и это будет финальная часть цикла статей об App.Farm CI. Наш материал посвящён работе с пользователями App.Farm CI — какие темы затронем в этой части:

• Сопровождение как задумывали

• Сопровождение как получилось

• Процесс Feature Requests

• Публикация Changelog

• Итоги и планы

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

Сопровождение как задумывали

Мы реализуем платформу и пользователи нашего продукта — это другие разработчики, которые реализуют собственные бизнес-продукты, автоматизируя разработку с помощью нашей платформы.

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

В нашем понимании направление SRE должно было обеспечить баланс между хаосом и развалами при реализации MVP платформы и стабильностью сервисов для пользователей. Чтобы SRE был как элемент противостояния (в хорошем смысле) разработке: где разработка платформы стремится часто изменять состояние, делать новое, ломать что-то, а SRE — уравновешивает это внедрением различных процессов и технических средств для соблюдения надежности, стабильности, непрерывной работоспособности и т.д.

Мы хотели, чтобы служба SRE была частью команды разработки платформы и имела полноценные права на развитие продукта в скоупе ответственности SRE. А наличие высоких инженерных навыков позволяло бы инженеру SRE самостоятельно исправить проблемы пользователя без эскалации в разработку.

Какие задачи SRE мы видели на тот момент:

• Обеспечение надежности платформы:

  • Мониторинг и поддержание стабильности работы сервисов.

  • Управление инцидентами (выявление, устранение и предотвращение сбоев).

  • Разработка и внедрение механизмов автоматического восстановления.

• Автоматизация:

  • Создание инструментов для автоматизации рутинных задач.

  • Уменьшение количества существующих ручных действий в эксплуатации платформы.

• Проектирование и оптимизация:

  • Участие в проектировании архитектуры платформы с учетом требований надежности.

  • Оптимизация производительности и ресурсов.

• Управление изменениями:

  • Контроль за внедрением изменений в production-среде.

  • Проведение тестов на отказоустойчивость (например, chaos engineering).

• Работа с метриками и SLA/SLO/SLI:

  • Определение и контроль ключевых показателей надежности (Service Level Indicators, SLI).

  • Обеспечение выполнения обязательств по уровню обслуживания (Service Level Agreements, SLA).

  • Постоянное улучшение целевых показателей (Service Level Objectives, SLO).

• Коллаборация с командами-потребителями:

  • Тесное взаимодействие с разработчиками, пользователями платформы, чтобы учитывать требования к надежности на этапе проектирования.

  • Обучение и поддержка других команд в вопросах эксплуатации.

Мы понимали, что SRE и саппорт — это две разные, но взаимодополняющие функции, которые вместе могут обеспечивать стабильность платформы и удовлетворенность пользователей. Но хотели сфокусироваться больше на задачах SRE, а саппорт развивать уже внутри этой службы. Этот подход позволил бы в том числе улучшить найм, потому что вакансия инженера SRE и его задачи с элементами саппорта выглядели привлекательней для соискателя, чем классический «сопровожденец».

Напомню, что все это мы задумали на самом старте разработки платформы и мы были довольно оптимистичными. Дальнейший опыт эксплуатации внес свои коррективы в нашу задумку со службой SRE.

В момент, когда мы реализовали первые flow и по сути сказали всем командам разработки: «Добро пожаловать на платформу» — мы получили лавинообразный эффект из пользователей, которые начали массово переезжать на App.Farm CI. Как следствие мы стали получать огромное количество обращений от пользователей, которые нужно было обрабатывать.

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

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

• Консультация по работе с платформой.

• Ошибки и дефекты, возникающие во время работы.

• Проблемы с производительностью или отказами каких-либо подсистем или инфраструктуры.

• Запросы на доработки и на поддержку какой-то особой специфики.

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

Из-за этих факторов фокус службы SRE сильно сместился в сторону сопровождения и работу с пользователями. А отсутствие времени у SRE на усиление компетенций и знаний устройства платформы приводило к тому, что все темы практически сразу эскалировались в разработку.

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

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

Так мы пришли к тому, что вместо службы SRE с задачами по сопровождению мы получили службу сопровождения с задачами по SRE. Также этому способствовало вышестоящее руководство, которое по своему видело развитие сопровождение и вывело эту службу из состава платформы, а также закрепило за этой службой KPI по темам сопровождения, а не SRE. Оглядываясь на этот опыт не хотелось критиковать те или иные события, просто получилось по другому, обстоятельства потребовали адаптироваться.

Сопровождение как получилось

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

Сейчас наше сопровождение выполняет следующие работы:

• Дежурства 24/7. Здесь выполняется оказание круглосуточной поддержки, базовые консультации и решения базовых проблем, регистрация инцидентов, эскалирование при необходимости.

• Сопровождение пользователей. Включает в себя прием и обработку обращений от пользователей. Предоставление справочной информации (документация, инструкции). Выполнение диагностики проблем, в том числе анализ и устранение сложных технических проблем. Сотрудники, занимающиеся этой работой, обладают технической экспертизой, владеют глубокими знаниями архитектуры платформы, а так же умением анализировать логи, метрики и исходный код продукта. Сопровождение включает в себя группы по направлениям:

  • Поддержка инфраструктуры.

  • Поддержка интеграции.

  • Поддержка пользователей платформы.

• Онбординг новых систем на платформу. Здесь происходит глубокий анализ систем, которые планируют использовать платформу. Тесное взаимодействие с владельцами этих систем. А также работа с требованиями и конфигурациями; подготовка и первичное размещение систем на платформе.

• Процесс работы с Feature Requests. Процесс обработки пользовательских запросов на доработку платформы, где сопровождение совместно с командой разработки выполняет: анализ, первичное проектирование, экспресс оценку и приоритезацию.

• Инцидент-менеджмент. Комплексный процесс, включающий организационные мероприятия и технические средства по регистрации, обработке, диагностике, экскалации и прочие работы с инцидентами.

Кроме того, в службе сопровождения сохранился центр SRE, который продолжает развиваться и усиливаться разработчиками и инженерами. Центр занимается реализацией различных технических решений для обеспечения процессов сопровождения. А также выполняет работы непосредственно по своему профилю: разработкой организационно-технических мероприятий по улучшению надежности и стабильности продукта.

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

Что касается взаимодействия с пользователями, то для него мы реализовали пользовательскую Issue Board в Gitlab, где пользователи фиксировали обращения. Кроме того, мы реализовали беспрецедентную акцию по меркам нашей организации: общий чат платформы, который доступен всем пользователям, где они могут задать любой вопрос или обсудить что-то по технике с другими пользователями платформы.

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

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

• Сопровождение стало перенаправлять всех пользователей с их вопросами на доску, потому что KPI саппорта измерялся по решенным запросам, а мессадж в чатике никто не измерит.

• Чат превратился в чат пользовательского алертинга, когда в нем массово начинают все писать только при каких-то проблемах на платформе, например, стали медленно работать конвейеры.

• Только единицы пользователей подхватили тему community и на своем опыте и энтузиазме помогают другим пользователям наравне с нами. За что им респект.

• В конечном счете чат превратился в инструмент, где пользователи пингуют саппорт о том, что нужно срочно посмотреть их запрос на доске: «Я завел issue1234, срочно посмотрите!».

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

Процесс Feature Requests

Хотелось бы подробнее остановиться на нашем процессе Feature Requests. Любой продукт подразумевает развитие и вектор развития может определяться: потребностями бизнеса, потребностями рынка, государственным регулированием и прочими факторами. Потребностями бизнеса для нас является запрос на развитие от пользователя — владельца бизнес-системы, которая используют платформу.

Feature Requests могут быть абсолютно разными по уровню сложности или по охвату подсистем платформы, которые потребуют модификацию. Это может быть как атомарная понятная задача, так и epic, который потребует проектную деятельность с глубоким анализом в несколько итераций и подзадач. Подобная амплитуда требует специалиста широкого профиля, который способен обработать подобный Request. Обработать не значит реализовать. В рамках обработки необходимо дать заключение: будем делать или нет, как это можно реализовать, что нужно предусмотреть при реализации, какие могут быть зависимости, дать экспресс оценку. А также быть способным сформулировать ответ для пользователя — инициатора запроса, либо запросить у него дополнительную информацию для корректной обработки запроса.

Как показала практика один человек не всегда способен принять правильное решение относительно Feature Request. Потому что невозможно уместить в одной голове все знания о платформе, тонкостях архитектуры, да и вообще обладать высокими компетенциями по всем направлениям начиная от сетевой инженерии, заканчивая Spring Boot на Java.

Мы пришли к тому, что для обработки запросов на развитие нужно собирать кворум, который включает:

• Прикладного разработчика.

• Инфраструктурного инженера.

• Системного аналитика.

• Сотрудника сопровождения.

• Владельца продукта.

Все участники должны обладать скиллами уровня «архитектор» Участие сотрудника сопровождения нужно в том числе для баланса сил и отстаивания интересов пользователя, что-то вроде customer advocate. Участие владельца продукта необходимо для управления приоритетами.

Оформляя эту процедуру в процесс мы задумались: «А как же ее назвать?». Нам хотелось в названии отдать дань бюрократическим процессам внутри крупной продуктовой компании, добавив немного иронии, и назвали это — «Bureau» . Такое бюро архитекторов, бутылочное горлышко из устаревших специалистов, которые уже утратили связь с реальностью, но обладают правами принимать решение, потому что пережили своих предшественников. Это абстрактная сущность, которой мы не хотели становится, поэтому в названии заложили напоминание себе об этом.

Мы ввели следующие правила проведения Bureau:

• Сбор дважды в неделю по расписанию или внепланово по требованию.

• Соблюдение кворума из: инженера, разработчика, аналитика.

• Ротация участников каждую неделю. Она производится из пула сотрудников, готовых проводить бюро.

• Регулярное включение новых сотрудников в пул, готовых проводить бюро (определяется по результатам performance review).

• Формирование заключения по каждому запросу с одним из результатов:

  • Запрос берется в работу (с установкой приоритета).

  • Запрос требует уточнений (ожидание до получения разъяснений).

  • Запрос отклоняется (с описанием причин).

Итоговый жизненный цикл Feature Request:

• Пользователь заводит запрос на доску саппорта с описанием бизнес-потребности.

• Сопровождение обрабатывает запрос на своем уровне. В результате обработки могут быть следующие исходы:

  • Доработка уже сделана. Даются ссылки на документацию.

  • Предлагаемая доработка не требуется, бизнес-потребность может решиться наличием существующего функционала. Предлагается решение.

  • В запросе недостаточно описания для понимания предлагаемой доработки. Запрашиваются уточнения.

  • Доработку завели из-за наличия ошибки в существующем функционале. Переквалифицируется в дефект.

  • Доработка предположительно требуется и передается на рассмотрение в бюро.

• Бюро по расписанию или внепланово собирается на рассмотрение запросов пользователя.

• Бюро обрабатывает каждый запрос и дает заключение.

• Если бюро одобрило запрос, он попадает в очередь запросов на реализацию.

• Далее менеджмент совместно с владельцем продукта планирует запросы в работу.

• На планирование спринта запрос назначается в работу.

Публикация Changelog

В результате выполнения исправлений или доработок платформы у нас накапливается история изменений. Для ведения истории изменений внутри самих компонент мы используем файл CHANGELOG.md. Но нам также хотелось иметь историю изменений относительно продукта в целом, чтобы видеть какие изменения происходили в истории продукта. Кроме того хотели сделать свою деятельность более публичной и ближе к пользователю, чтобы показывать информацию обо всех доработках и в целом популяризовать платформу.

Для решения этой задачи мы организовали следующие процессы:

• Корпоративный новостной канал, где публикуем посты с кратким описанием изменений.

• Страница с продуктовой историей изменений в пользовательской документации.

В процесс разработки мы включили обязательный пункт для доработок, чтобы после их реализации разработчик оформлялся changelog в документации, где было бы: короткое описание доработки, quick start по её использованию, ссылки на документацию с подробным описанием и т.д. Публикацию истории изменений мы делаем в разрезе спринтов, так можно делать группировку по временным отрезкам, а также прикинуть производительность разработки платформы.

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

Итоги и планы

В текущей статье мы описали процессы по работе с пользователями и рассмотрели различные аспекты эксплуатации платформы. Все это справедливо не только для подсистемы App.Farm CI, которой был посвящен этот цикл статей, а в целом для всей платформы App.Farm. Будем считать это подводкой к новым статьям о других подсистемах App.Farm.

На этом мы завершаем цикл статей про подсистему App.Farm CI. В качестве итога представляем вам список поддерживаемых на данный момент flow:

• Собственная разработка:

  • Java/Kotlin.

  • C#/.NET.

  • Angular/React/Generic Frontend.

  • Python.

  • NodeJS.

  • Golang.

  • 1С:Предприятие.

• Вендорские сборки:

  • JVM исполняемые артефакты.

  • Python исполняемые артефакты.

  • .NET исполняемые артефакты.

  • Frontend исполняемые артефакты.

  • OCI-образ.

На данный момент в планах развития подсистемы App.Farm CI есть следующие задачи:

• Реализация CI 2.0: переход с синтаксиса Gitlab CI на собственный DSL и программную реализацию на Golang.

• Отказ от иерархического ведения организационной структуры в Gitlab в пользу плоской.

• Внедрение gitlab-operator: переход к автоматизации управления репозиториями.

• Внедрение nexus-operator: переход к автоматизации управления артефактами.

• Упаковка и тиражирование App.Farm CI: продажа подсистемы другим компаниям.

Ну и конечно же никуда не исчезает регулярный онбординг новых команд разработки на App.Farm CI для автоматизации их процесса разработки под ключ.

Чтобы как можно больше пользователей сосредоточились на бизнесе, а обо всем остальном позаботится App.Farm.

Предыдущие части:

• Как мы создавали PaaS‑платформу App.Farm

• App.Farm CI. Часть I. Проблемы и выбор решений

• App.Farm CI. Часть II. Конвейер — швейцарский нож: особенности запуска мультиарендного процесса разработки

• App.Farm CI. Часть III. Подготовка к реализации flow — быть вахтером или не быть?

• App.Farm CI. Часть IV. Реализуем flow — шагаем к автоматизации разработки