Внедрение CI/CD и DevOps в Enterprise (в нашем случае — Ростелеком) +4


Тема до сих пор весьма хайповая, и админы, добавляющие в свои резюме словечко DevOps, автоматически рассчитывают на +100К к зарплате. Но мы не про это. Мы хотим рассказать про то, как Ростелеком ИТ внедряет CI/CD & DevOps в энтерпрайзовый ИТ-ландшафт и тяжелые монолитные Legacy-системы.

Первая часть нашего руководства будет про «Почему, зачем, как получить на это денег от бизнеса и как получается внедрять CI/CD в десятки проектных команд очень большой компании». Это интересная практическая информация для руководителей ИТ-подразделений и лидов. Вторая часть статьи – сугубо инженерная, с описанием прикладных подходов, инструментов и реализаций в зависимости от типа и технологического статуса проекта. И третий блок будет про процесс внедрения в рамках Karma Framework в круге. Поехали!

Ретро. Как всё начиналось

Примерно за год  ИТ-разработка Ростелекома в определенном периметре выстроила современную инфраструктуру, основанную на микросервисной архитектуре с развертыванием в кластере OpenShift. Эту инфру мы потом назвали «Платформой Цифровых Продуктов», далее ПЦП. Мы позже подробнее опишем состав ПЦП.

Внедрение ПЦП позволило существенно перестроить работу некоторых команд, которые были лоцированы в одном структурном подразделении, с одной точкой управления. Это важно, так как у нас получилось создать в определенной степени технологический и методологический анклав и выстроить новые практики, которые отличаются от остальной корпорации — вплоть до того, что мы не поддержали промышленный корпоративный стандарт, и проекты, запускавшиеся в ПЦП, выводились в продакшн на конечных юзеров, но не передавались в общую эксплуатацию. По сути это означает, что продукты НЕ падали вообще и были вне контура эксплуатации. Но с СБ ИТ все договоренности мы имели и нужные мероприятия делали. Плюс несколько команд начали работать в продуктовом подходе по Agile. Разумеется, это стало возможным на определенном классе продуктов и сервисов, что мы запускали. В основном это были относительно легкие фронтовые и middleware-решения, которые легко создавались на основе микросервисов и быстро запускались — web-проекты, но с интеграциями в глубокий корпоративный бэкенд. Часть функционала и интеграции запиливались в микросервисы, которые могли использовать другие проекты. Тем не менее, для большой корпорации это был «космос» — оказывается, за 3-6 месяцев можно развернуть для конечных пользователей довольно большой проект или сервис с интеграцией в общий ИТ-ландшафт, опробовать бизнес-гипотезы и модели или просто включить в продуктовую линейку и возможности для клиентов. Сноска для понимания стартаперов: в больших компаниях со множеством региональных биллингов на миллионы людей раньше нельзя было взять и просто за 3-6 месяцев запустить на всю клиентскую базу новый продукт или сервис. Обычно успехом считалось, что это время уходит только на согласование бюджета и ТЗ. А продукт в коде появлялся не ранее чем через год. Еще здесь стоит заметить, что любой стартап через пару лет становится легаси ))

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

И вот тут-то оказалось, что массы — это разнокалиберные монолитные легаси-системы «глубокого залегания» порой циклопического масштаба и набора функционала с историей, уходящей вглубь веков. Класс систем типа АСР, CRM, аналитические системы, хранилища тарифных планов, системы ордеринга — в общем, чудный мир OSS/BSS. И вся наша микросервисная архитектура, весь наш DevOps, OpenShift и CI/CD — как попытка научить стадо слонов синхронному плаванию. Причем как чисто технологически, так и коммуникационно. Примерно полгода у нас ушло на исследование: насколько вообще применим пусть не микросервисный, а хотя бы компонентный инфраструктурный подход к монолитным системам. Еще сложнее оказалось объяснить и вовлечь ИТ-хэдов проектов и команд в исследование на тему как и главное — зачем распиливать на компоненты ядро, где вся логика зашита, например, в пакеты Oracle. Ну допустим. А далее эстафета достигает, достигает, достигает… бизнес-заказчиков. И бизнес задает главный вопрос жизни, вселенной и всего такого — а зачем мы будем платить за архитектурный рефакторинг систем, которые и так работают? 

— Аээ… 42!

Обычно на этом дискуссия съеживается, и ИТ уходит в офлайн мариновать тему, а архитекторы наслаждаться интеллектом друг друга. Тоже прок и лекарство против выгорания.

Вот на этом этапе и возникают докладчики на DevOps-конференциях с заявлениями, что в энтерпрайзе все это не летит.

Практики внедрения CI/CD&DevOps в Ростелекоме

Не то чтобы мы самые умные или упоротые. Но мы все же решили посмотреть, что есть за горизонтом событий. Даа, «мало, мало огня, мы хотим еще немного больше». Горит в Ростелекоме внутренний огонь!

Начали с простых внутрикорпоративных докладов и митапов для различных проектных ИТ-команд и для инхаус-бизнес-заказчиков. Это не дало результат с точки зрения конкретных внедрений CI/CD & практик DevOps в проекты за периметром ПЦП. Но когда ты этим занимаешься больше года, то повестка начинает проникать даже в весьма консервативные команды и дальние регионы компании. Дискурс меняется, и вдруг некоторые коллеги начинают козырять словом Kubernetes как своим! Это определенно шаг вперед. 

Вскоре реплицировался инфраструктурный кластер с похожим на ПЦП подходом в макрорегиональном филиале Ростелекома в Краснодаре, где ребята стали внедрять практику DevOps и CI/CD процессы в новые проекты, но в более тяжелый класс систем, нежели web-решения. Появились общие подходы к автотестированию, юнит-тестированию, нагрузочному тестированию, подготовки к релизу, мониторингу. Потихоньку общий подход к архитектуре, основанной на микросервисах и компонентах, стал доминирующим для новых стартующих в разработку систем. Однако по-прежнему существующие монолитные легаси-системы жили своей жизнью.

Следующим шагом стала попытка организовать гильдии «девопсеров». Это горизонтально организованный коммуникационный формат, где различные проектные команды обмениваются опытом и практиками внедрения DevOps и CI/CD. Различные гильдии были созданы и по другим ИТ-специализациям. Формат какое-то время успешно поработал в части дальнейшего проникновения актуальных практик в различные ИТ-команды. Десятки DevOps-инженеров Ростелекома объединились и выносили задачки и свой опыт в общее тематическое инфополе. Но в итоге данный формат затух. Прежде всего потому,  что сложно самоподдерживать мотивацию без целеполагания, оформленного в роадмап. Второй веской причиной затухания гильдий стало то, что этот формат без обязательств так и не позволил на системном уровне внедрять CI/CD в большие проекты и легаси-системы. Как ни крути, но не DevOps-инженеры принимают решения о переформатировании всего технологического и релизного цикла разработки или о рефакторинге.

Примерно за три года миссионерской работы знание и принимаемость темы DevOps и CI/CD в компании вышли за порог отрицания. Проделанная работа в итоге начала все же приводить к тому, что по крайней мере IT-команды стали экспериментировать и что-то использовать из инструментов интеграции и развёртывания, особенно в части тестирования и работы с git. И, наконец, мы начали пробовать внедрять CI/CD на некоторых системах тяжелого класса с монолитным ядром в БД и легаси-кодом, которые оказались по разработке в прямом операционном управлении. 

Важный кейс и настоящий профит от ПЦП, от сложившегося подхода к архитектуре, разработке и набора инструментов мы получили для сетапа самого яркого огонька в корпоративном ИТ в России 2020 — это экосистемы. Концепция цифровых экосистем с кросс-связанностью и кросс-сервисами по всей продуктовой линейке отлично приземляется на микросервисную архитектуру. И у нас уже была готовая инфраструктура, откуда стали быстро расти экосистемные ростки Ростелекома. А что требуется для таких стейтмент-терминов как цифровая экосистема? Правильно — quick win. Чайки, налетайте!

Несмотря на заметные результаты, как ни странно, целевое дело пошло на проектах, которые начинали делать не мы, и проекты пришли к нам в Центр Компетенции digital-разработки Ростелеком ИТ в тяжелом нестабильном состоянии. До 90% ресурса команд уходило на багфикс и латание дыр. Техдолг уходил за горизонт полугода. О функциональном развитии можно было забыть. При этом системы были чрезвычайно важны и нужны бизнесу. Вот здесь и случились прорывы. Возвращаясь к вопросу бизнеса: «Зачем мы будем платить за архитектурный рефакторинг систем, которые и так работают?». А вот если системы еле ворочаются и критикал-баги зашкаливают, то разговор с бизнесом из томного превращается в конструктив. У вас как у ИТ-разработки появляется возможность найти у бизнеса понимание, что для сохранения жизнеспособности систем и затем их развития нужно не перепиливать все с нуля (на больших системах часто это вообще невозможно по технологическим или бюджетным причинам), а начать внедрять DevOps и CI/CD процессы с параллельным архитектурным рефакторингом, и начинать нужно с особенно критичных мест в системе и оптимизации релизного цикла. А внедрять можно даже в рамках существующего ресурса команды и бюджета. Мы, например, брали на себя коммиты, что через 3 месяца сократим затраты ресурса команды проекта на багфикс с состояния более 50% AS IS, в котором мы получили проект, до приемлемых в среднем по индустрии менее 20%. При том практически без роста бюджета и состава команды. 

В общем, если вы хотите внедрить в энтерпрайзовую легаси-систему DevOps и CI/CD процессы, отдайте ее условным индусам. Верните ее потом себе назад в ужасном состоянии, и у вас появится возможность все исправить модными штучками! Шутка))

Что в итоге сработало. Круги и Karma Framework

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

Но реальный системный результат дало использование формата кругов в рамках Karma Framework. Поскольку «Ростелеком ИТ» – не внешний вендор (тоже важный момент, кстати), а инхаус-разработчик в группе компаний ПАО «Ростелеком», то мы работаем не за маржинальность, а за карму. Это не абстракция, а финансовая модель, помноженная на ключевые ценности. И, следуя фундаментальным ценностям, таким как открытость, честность, доверие и партнерство между ИТ и бизнес-заказчиками, мы как ИТ зарабатываем карму, или другими словами — свою репутацию и лояльность бизнеса, стараясь делать продукты качественно, быстро и за адекватные бюджеты. Для последнего, собственно, и нужны Devops & CI/CD, с точки зрения технологий и процессов.

Karma Framework — это оригинальная практика управления IT в Ростелекоме, которую мы внедряем последние годы, и даже Gartner включил Karma в число передовых мировых управленческих практик. Вполне заслуженно, надо сказать. Про Karma Framework можно рассказывать очень долго на разных уровнях абстракции, но для нашей темы достаточно пояснить, что суть фреймворка в плоской модели управления, где упор делается на самоорганизацию команд и горизонтальное взаимодействие команд посредством кругов. В одном круге с каким-либо предназначением может быть множество людей, представителей команд или целых проектных групп, которые объединены целью — выполнить предназначение круга.

В нашем случае предназначение Круга DevOps стало очень простым: внедрить подходы Devops и практики CI/CD на корпоративном масштабе во множество проектных команд и сделать это технологическим промышленным стандартом.

В отличие от других форматов, круг позволил выстроить системную работу с роадмапами, инструментами, стандартами и учётом кастомных нюансов. И мы наконец ушли от прекрасного, но малорезультативного евангелизма и обмена опытом в чатах, и занялись предметным внедрением Devops & CI/CD в очень разные классы проектов и систем. Как работает круг и фреймворк в целом, мы расскажем в следующих частях про внедрение Devops&CI/CD в энтерпрайзе. 

А пока же эту бизнесовую по сути часть темы резюмируем двумя блоками обоснования и ответом на вопрос, зачем нужно внедрять Devops&CI/CD и платить за это. Плюс несколько ключевых поинтов.

Для бизнеса:

  1. Ускорить Time-2-market вывода продукта в целом или обновлений по линейному развитию легаси.

  2. Экономия. Оплатить внедрение Devops&CI/CD и потратить N бюджета, чтобы на горизонте получить экономию в деньгах Y больше N. Или получить прибавку производительности команды, и это окупит N, а потом пойдет время чистоганом. Реальные горизонты наступления эффектов в энтерпрайзе — 6–12 месяцев. Бывает, что и за пару месяцев на проектах с нулевой зрелостью CI/CD можно окупить потраченный ресурс команды.

  3. Сократить расходы на оплату ресурса команды, уходящего на багфиксы. В среднем по индустрии на зрелых проектах бизнес готов мириться с 20% затрат на саппорт на третьей ЛТП от бюджета развития. В целевом сокращается до 10%, а иногда уходит почти в ноль. И бизнес получает больше функционального развития.

  4. Гораздо более стабильные продукты и системы. Это автоматически ведет к росту бизнес-маркеров типа NPS, экономии на 1-2 линиях, колл-центрах и т.д.

  5. Нормализация работы и коммуникации бизнеса с ИТ. Исчезновение ментальных дисбалансов на темы «Кто кому должен и кто плохо работает».

 Для ИТ:

  1. Реальная оптимизация технологического цикла разработки. Можно сократить время и усилия почти на каждом участке — от аналитики и постановок задач до подготовки релиза и вывода в продакшн. У нас есть кейсы, где вместо ночных многочасовых бдений вывод в продуктив стал занимать десятки минут и без тоскливого ощущения снова получить на регрессе кучу критикал-багов, иногда без возможности откатить.

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

  3. Разработчики занимаются программированием и кодом, творчеством, а не разбором инцидентов и поиском их причин. Вообще, внедрение CI/CD влечет за собой повышение квалификации команды и более точного состояния, когда каждый специалист занимается своим делом.

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

  5. Все нормальные айтишники хотят делать хорошие качественные продукты. Все хотят заниматься производительным трудом на благо продукту и использовать современные стеки и технологии. В энтерпрайзе это делать тяжелее. И внедрение Devops&CI/CD позволяет подкормить профессиональную совесть качественным нектаром.  

Важные моменты:

  1. CI/CD начинается до технологического цикла. Мы рассматриваем CI/CD как процесс, который начинается с идеи в горнилах бизнеса. И важно операционные процессы с бизнесом выстроить так, чтобы сырые идеи не залетали в разработку, чтобы бизнес внутри себя договаривался, что конкретно и в каком порядке пойдет в разработку. По сути это качественная работа с бэклогом, чтобы он всегда был полон на пару месяцев вперед и приоритезирован. 

  2. Devops&CI/CD можно внедрять на любом уровне зрелости продукта и команды. Целый ряд вещей вообще не технологического порядка, а логистического и операционного. Часть инструментов и подходов можно внедрить очень дешево во всех смыслах. Даже в старых, тяжелых легаси-системах.

  3. Devops&CI/CD не является синонимом Agile и вполне работает в классическом ватерфоле и фикспрайсовых моделях. Отдельные инструменты и подходы вполне можно использовать: ту же автоматизацию сборки, автотесты, Unit-тестирование, правильную настройку git(а) можно внедрять хоть где. 

Однако, CI/CD наиболее эффективен в связке со Scrum или Канбан. По сути, это объединение продвинутых операционной и технологической методик работы с ИТ-конвейером. У нас есть несколько кейсов такого рода. И мы увидели большие перспективы наложения на Канбан-доску с ее этапами разработки, матрицы действий и инструментов CI/CD. Здесь просто золотая жила. И мы уже делаем оригинальный фреймворк о том, как поженить Devops&CI/CD с Канбан. В следующих частях темы Devops&CI/CD в энтерпрайзе мы расскажем и том, как устроена наша Платформа Цифровых Продуктов, и о том, как работают круг и фреймворк внедрения Devops&CI/CD в разные классы систем и проектов.

Ждите новостей от Ростелеком ИТ!




К сожалению, не доступен сервер mySQL