Операция под кодовым названием «Т», или как мы дали каждой команде по кластеру и вышли в прод за 6 месяцев

В программе:

1. Описание кейса

2. Наш процесс

3. Наш стек

4. Взгляд изнутри команды

5. T-Shape или универсальный солдат

6. Вместо заключения

Описание кейса

Для начала немного контекста. Дойче Телеком – третья по величине телеком-компания в мире, чья история начинается аж с середины XX века. Причем бизнес компании достаточно разносторонний: это услуги мобильной связи, продажа смартфонов и прочих гаджетов, а также проводной интернет и IP-TV, включая продажу и сдачу в аренду необходимого оборудования (приставок, роутеров и т.п.).

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

Интеграция всего этого ИТ-зоопарка по принципу точка-точка превращается в кромешный ад. Системы-провайдеры вынуждены поддерживать десятки интеграционных интерфейсов, необходимых различным системами-потребителям, в то время как системы-потребители вынуждены интегрироваться с большим числом провайдеров, чтобы “по крупице” собирать нужные им данные и реализовывать нужные бизнес-процессы. Естественно, что всё это ведет к существенным временным и финансовым затратам как на разработку новой, так и на поддержку уже имеющейся функциональности, поэтому за последние десятилетия в компании предпринималась не одна попытка привести процессы интеграции к некоторому единообразию. Однако существенного успеха добиться так и не удалось: очередная интеграционная шина со временем деградировала в простого посредника для peer-to-peer интеграций.

В 2019 году появилась идея выполнить развязку ИТ-систем друг от друга через стандартизированный API-слой – мы назвали его Enterprise API.  За основу взяли отраслевой стандарт телеком-индустрии – TM Forum, который в числе прочего специфицирует набор REST API, покрывающий (по крайней мере в теории) все нужды телеком-компании. Стандартизация моделей данных и операций над ними должна наконец позволить нам создать действительно повторно-используемые API,  на корню пресекая попытки в очередной раз создать зоопарк из peer-to-peer решений. К тому же за стандартным API можно наконец скрыть legacy-системы, и потом постепенно заменять их на современные решения незаметно для систем-потребителей.

В феврале 2020 перед нами стояла амбициозная задача – реализовать MVP для Enterprise API, включив в него ограниченный набор “core” APIs из TMForum - 10 штук, который скроет за собой полтора десятка бэкэнд-систем. Причем наши новые API были нужны ключевым frontend-приложениям телекома, с которым работают клиенты и бизнес-партнеры компании, и нужны они были в очень сжатые сроки – к выставке бытовой электроники IFA 2020, запланированной на сентябрь. К этому моменту нужно было не просто разработать набор API и выкатить его в прод, но и протестироваться совместно с потребителями, чтобы они также смогли вывести свои доработки в production до выставки.  Таким образом, у нас было всего 6 месяцев на то, чтобы, начав с нуля, выйти в прод в огромном enterprise. Более того, мы стартовали всего 7 командами, чего явно не хватало для разработки MVP, так что нам предстояло еще и значительно вырасти в размере.

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

Наш процесс

1. SAFe фреймворк

Телеком, как и стоит ожидать от компании таких масштабов, не был пионером внедрения гибких моделей разработки. Большинство проектов велись по водопадной модели, а попытки внедрения Agile лишь на уровне команд не давали заметного результата. Поэтому в компании было принято решение внедрить гибкую методологию, адаптированную под большой enterprise, и выбор пал на SAFe (Scaled Agile Framework). Наш проект стал одним из первопроходцев во внедрении SAFe в Дойче Телеком.

В целом, положительные результаты работы по SAFe стали заметны уже после первой итерации. Рабочие процессы, по сравнению с более старыми проектами внутри Дойче Телеком, стали более прозрачными и прогнозируемыми, проще стало учитывать взаимосвязи команд, планировать и приоритизировать задачи. Конечно, не всё шло гладко: при внедрении SAFe мы столкнулись с некоторым скепсисом со стороны команд, даже несмотря на то, что все члены проекта прошли курс обучения по SAFe. Однако, по итогам года можно сказать точно: SAFe работает. Начав в феврале 2020 года 7 agile-командами, а к январю 2021 года мы выросли до 14 команд (более 170 человек).

Конечно, SAFe не является панацеей, потребовалась его адаптация к нашим условиям. Однако, мы успешно используем лучшие практики SAFe в нашей работе.

2. Teams-driven development

Agile-команда у нас реальная боевая единица. У нее есть автономность в выборе технических решений. Решения не навязываются сверху: системные архитекторы формируют лишь наиболее базовые ограничения и общие рекомендации, а далее работают с командами уже в роли коучей и консультантов, поощряя самостоятельное принятие архитектурных решений командами. Все функциональные вопросы по конкретному API отданы команде полностью.

3. T-Shaped skills

У нас кросс-функциональные Agile-команды и мы стараемся развивать культуру универсальности. Каждый специалист в DevTeam может принять участие в разработке, тестировании, аналитике, DevOps-е. Чем универсальнее специалисты в команде, тем выше эффективность работы всей команды. Мы об этом еще поговорим подробнее ниже.

4. PO действительно с командой

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

Наш стек

Технологический стек выбирался исходя из следующих соображений:

Во-первых, ориентированность на облако. Компания уже сталкивалась со сложностями масштабирования корпоративных приложений в собственных дата-центрах, поэтому было принято решение разворачивать Enterprise API в облаке AWS. Однако привязки к конкретному облачному провайдеру хотелось всеми силами избежать, так что в качестве платформы для развёртывания был выбран AWS Elastic Kubernetes Service — EKS. Использование Kubernetes позволит в будущем при необходимости переехать к другому облачному провайдеру (у Azure есть аналогичный AKS, у Google — GKE), или даже в приватное облако. Также в приватном Kubernetes можно будет разворачивать те Enterprise API, которые из соображений безопасности и защиты личных данных нельзя разворачивать в публичных облаках.

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

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

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

В итоге остановились на следующем наборе:

• Java 11+, как единственный допустимый backend-язык

• REST, OpenAPI/Swagger для публикуемых наружу API, OpenAPI-Generator для генерации кода по спецификации

• Spring Boot (c классическим Web MVC или WebFlux) или Quarkus на выбор. Также допустимо использование GraalVM native и OpenFaas

• PostgreSQL для случаев, когда необходима реляционная СУБД, Redis / MongoDB / ElasticSearch на выбор в остальных случаях

• Kafka

С таким стеком команды получили простор для фантазии при выборе решения для своего API, и на рисунке ниже приведена лишь часть возможных комбинаций:

И снова вернемся к практикам. Где начинается и где заканчивается ответственность Agile-команды?

Взгляд изнутри команды

У нас разработкой каждого API-сервиса занимается только одна команда и результат ее работы не зависит от остальных. Поэтому кроме написания кода в обязанности команды также входит проектирование архитектуры приложения, дизайн спецификации, поднятие k8s кластеров, отладка, проведение всевозможных этапов тестирования(апи, нагрузочных и др.), настройка CI/CD для поставки на различные окружения, включая и продакшн, ну и безусловно дальнейшая поддержка и развитие.

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

Преимуществами такого подхода в разработке API являются:

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

• Меньший объем кода позволяет существенно увеличить скорость сборки проекта и поставки его в продакшн.

• Комбинация первых двух пунктов упрощает внедрение новых технологий и применение новомодных практик в разработке.

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

Ну а как же без минусов:

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

• Дублирование работы по части настройки кластеров, пайплайнов и общей конфигурации API. Решением данного вопроса занимается специально созданная команда System Team, которая предоставляет уже готовые и проверенные общие решения, освобождая остальные команды от необходимости написания велосипедов, что позволяет командам сконцентрироваться на бизнес логике своего API.

• В команде требуется экспертиза одновременно в разработке, в тестировании и в DevOps. Мы практикуем T-Shape, и сейчас поговорим о нем подробнее.

T-Shape или универсальный солдат

Что же такое T-Shape? По сути, это некое состояние, в котором у члена dev-команды есть глубокая экспертиза в какой-то конкретной области (бекенд, фронтенд, devOps, QA) — вертикальная палочка буквы Т. Но также есть познания в смежных областях, которые позволяют разработчику общаться с экспертами в каждой конкретной области, и принимать на этих основаниях решения — горизонтальная палочка буквы Т. По-простому, это значит, что все могут всё... в какой-то степени.

Но зачем?

Чтобы исключить ситуации бутылочного горлышка и фактор автобуса в процессе разработки. Например, когда эксперт в области devOps уходит в отпуск, и срочно нужно внести изменения в CI/CD. И не останавливать же работу, если QA внезапно решил уволиться?

Для девелоперов, это, в первую очередь, означает постоянный процесс познания чего-то нового и расширение экспертизы. Если представить IT-индустрию, как огромный пазл, который при этом ещё и расширяется с безумной скоростью (как наша вселенная), то T-shape позволяет девелоперу собрать у себя как можно больше кусочков этого пазла.

Компании, типа Гугл, Амазон и т.п., достаточно давно пришли к пониманию, что девелоперы не просто должны принимать участие на всех этапах разработки программного обеспечения, но должны его драйвить. Быть основной силой, тянущей этот состав. Достичь этого, не имея представления, как же всё работает от начала до конца — невозможно.

Суровая реальность

Далеко не всем интересно, например, разбираться в yaml’е и почему же в очередной раз упал пайплайн. Не всем интересно заниматься проработкой требований, сидеть на бесконечных митингах и обсуждать по десятому разу одно и тоже, с целью подтвердить (или развеять) догадки о том, как же должно работать программное обеспечение. Не говоря уже о ситуациях, когда бизнес сам не знает, чего хочет.

До сих пор, многие разработчики трудятся по принципу «закоммитил и забыл», и не знают, что происходит внутри пайплайна, если он вообще есть, как он сделан, и что же будет с кодом после того, как этот пайплайн пройдёт. Не говоря уже про деплоймент на продакшен. С одной стороны, это очень удобно для разработчика, т.к. в его зоне ответственности, по сути, находится только код. Но с другой стороны, это сильно замедляет процесс разработки, потому что приходится без конца перебрасываться Jira-тикетами, то с QA, то с PO, то с бизнес-аналитиками, то с оперейшенами.

Вместо заключения

Конечно, мы выполнили и даже перевыполнили поставленную перед нами задачу, но легко ли нам это далось? Совсем нет: новые требования к навыкам специалистов, новые технологии, процессы и т.д., безусловно усложняли работу на старте проекта. Но результаты наших трудов, проб и ошибок не заставили себя ждать. Онбординг новых команд встал на поток, а наработки System team сформировали целую технологическую платформу. Наш успех вызвал большой резонанс в компании, и у многих проектов возникло желание воспользоваться нашими наработками. Но это уже тема для отдельной статьи.

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