Всем привет! Меня зовут Александр Соколов, я эксперт центра практик DevOps в МТС Web Services (MWS). В 2020 году в МТС началась масштабная унификация внутренних процессов. По задумке, целью этой трансформации было сделать экосистему наших продуктов по-настоящему технологичной, быстрой, управляемой и гибкой. В компании выделили направления, которым особенно нужно развитие, среди которых был и DevOps. Затем два года мы разрабатывали, пилотировали и внедряли стандарты и практики для более чем 400 продуктов экосистемы.
Сначала такие изменения кажутся избыточными и неоправданно стрессовыми, но в результате формируются типовые процессы, которые облегчают рутину DevOps-инженеров. Как с внедрением практик справлялись продукты, мы уже рассказывали, а я вместе со своим коллегой @volkovro покажу, как мы избегаем сложностей при переменах и находим баланс между унификацией и автономностью.
Чем плох вариант собственных GitLab в каждой команде
До запуска технологической трансформации все наши продукты существовали и развивались без общей инфраструктуры, стека и стандартов качества. Во время предварительного аудита мы насчитали, например, около двадцати разных GitLab. Помимо них, для работы с кодом использовались и другие системы, такие как TFS и SVN.
Собственный GitLab в каждой команде — это очень гибко и удобно: разработчику легко попросить у девопса настроить как надо, и тот сделает. Но в итоге для компании это неуправляемые процессы: строительство экосистемы становится сложномасштабируемым, замедляется ее развитие.
Например, при проблемах в своем GitLab команде приходилось бросать текущие задачи и искать ресурсы на починку. Кроме того, использование собственных инструментов создает дополнительные риски, например bus factor. Если что-то случится с ведущим участок сотрудником, коллеги не смогут завершить проект. Этого можно избежать, если вывести поддержку инструментов из зоны ответственности команд и централизовать ее. Дополнительно повышается надежность и отказоустойчивость сервисов.
Тут в игру вступаем мы: центры компетенций и практик DevOps
Первые отвечают за методологию, разрабатывают стандарты и правила, а вторые помогают командам внедрять их в своих продуктах. Идею, как именно преобразовать DevOps-процессы, сформулировали в центре компетенций, а мы, центр практик, ее реализовывали.
Начали с решения привести команды к единому флоу разработки (условно GitFlow), чтобы у всех были одинаковые ветки и правила для слияния, однообразное именование и так далее. Тогда мы планировали использовать платную версию GitLab Enterprise — в 2021 году еще не было вопросов с лицензированием.
Проработали идею, но сразу поняли, что для многих предложенный процесс избыточен и сама перестройка требует огромных дополнительных трудозатрат. Допустим, в команде два разработчика и trunk based development. Собирать отдельную ветку под каждую фичу бессмысленно, а плюсы полной перестройки процессов для них неочевидны.
Первая задумка не взлетела — и мы пересмотрели подход
Для преобразования DevOps-процессов мы пригласили тех, кто будет напрямую с ними работать. В MWS разработка делится на кластеры — крупные оргструктуры, относящиеся к разным бизнес-вертикалям. Внутри кластеров есть продуктовые команды и отдельно — эксперты по основным направлениям: QA, аналитики, архитекторы, DevOps и так далее. Они помогают коллегам решать сложные ситуации, оптимизировать процессы и занимаются задачами, которые выходят за рамки отдельных продуктов. Именно с ними мы начали шлифовку новой концепции для унификации флоу.
С рабочей группой мы изменили требования к внедряемым процессам. Поняли, что в махровой систематизации нет смысла: суперунифицированное решение будет громоздким и подойдет не всем. Но нам нужно было достичь максимально возможной стандартизации, минимально нагружая DevOps-инженеров и не внося хаос в их деятельность.
Мы сохранили общие правила для повышения прозрачности разработки со стороны внешнего наблюдателя. А остальное отдали на откуп продуктовым командам, которые получили достаточную автономность, чтобы не приходилось через колено ломать внутренние процессы. Себе же мы оставили роль зрителя: смотрим, как все устроено в команде, и дополнительно рекомендуем изменения, которые принесут конкретный профит в надежность или безопасность.
Главная перемена для всех — переход на MWS DevRails
Это внутренняя разработка, включающая собственную систему контроля версий GitRails и основанная на открытой части GitLab. Также DevRails включает обвязки Registry, SonarQube и тому подобное.
До трансформации многие команды использовали Jenkins для построения процессов CI/CD и собственные хранилища артефактов, развернутые на инфраструктуре, поддерживаемой отдельной группой инженеров. Мне нужно было максимально быстро перевести продукт на GitLab CI/CD из-за скорого прекращения поддержки предыдущего решения. Центр практик DevOps тут ни при чем — так совпало.
Роман Волков
Senior DevOps в MTC Web Services
Процессы разделили на три группы: VCS, CI и CD
Каждая включает базовые и расширенные практики, что и обеспечило этапность. Внедрение группы процессов в одной команде занимает три месяца.
К примеру, в этом квартале мы запустили пилот базовых практик VCS в каком-то продукте. К середине срока публикуем общие требования для команд и собираем обратную связь. Вносим корректировки до конца квартала, а в начале следующего процессы становятся обязательными для всех. Далее переходим к проработке расширенных практик.
Эпик «Базовые практики CI» включал в себя требование к хранению кода внутри корпоративного GitRails и запуск на платформе задач сборок и развертки. А эпик «Внедрение расширенной практики CD» требовал унификации скриптов, наличия механизма отката изменений, тегирования репозиториев конфигураций, фиксации версий вынесенных пайплайнов и использования минимально разрешенной версии Helm. Важно, что, декларируя правила, эпики не накладывали существенных ограничений реализации и открывали некоторый простор для действий. Им я и воспользовался.
Роман Волков
Senior DevOps в MTC Web Services
Хотя внедрение поставили на поток, трудозатраты в командах различались
Все зависело от их размера и состава, продукта, исходного IT-ландшафта. Например, у кого-то уже был GitLab и свои практики. Они могли переехать из одного инстанса в другой без особых сложностей. Но какие-то команды не использовали системы контроля версий, или там применялся TFS. Вот им было действительно больно, потому что приходилось мигрировать код, переписывать пайплайны и переучивать людей.
Вот так выглядели команды и анамнез моего проекта до изменений:
Много народу: разработчики, тестировщики, аналитики, архитектор.
Исторических знаний о предыдущем пайплайне ни у кого не было.
Документация в корпоративной wiki по процессам DevOps отсутствовала.
В репозитории продукта наблюдался полный бардак. Например, в группе DevOps не было исходного кода пайплайна для jenkins — он хранился в корне проекта, в репозитории project_name_jenkins_libs. Если бы не jenkins в названии, не знаю, сколько бы времени ушло на его поиски в группе из 70+ репозиториев.
Некоторые репозитории по факту содержали исходный код сразу нескольких микросервисов.
Три языка программирования и четыре пайплайна. Для java было два варианта, отличающихся между собой опциями maven.
Часть команды использует для следования плагин git-flow.
Для Helm изначально была создана общая библиотека шаблонов, но из-за возможности кастомизации внутри репозиториев сервисов она стала скорее маленькой заготовкой, чем унифицированным средством.
Командам не нравилась сама идея изменений: настроения были ближе к «нас заставляют».
Проанализировав ситуацию, я принялся за шаблоны GitLab CI/CD, создание/подбор образов сборки, рисование схем и документирование всего возможного.
Роман Волков
Senior DevOps в MTC Web Services
Закономерно пошли возражения
Коллеги опасались, что новые процессы и требования сделают работу более бюрократичной, а команды будут зависеть от внешней поддержки. Сказывались привычка и нежелание менять устоявшееся. Но с развитием практик и распространением их по всей компании сопротивление ослабевало.
Во-первых, было видно, что в продуктах, где их уже внедрили, все неплохо работает. Команды начали понимать явные бенефиты для себя. Во-вторых, мы научились лучше формулировать и «продавать» то, что предлагаем. Процесс наладился.
Больше всех сопротивлялись команды, ранее не использовавшие GitLab. Поначалу для них было неочевидно, зачем менять то, что работает. Мы старались не давить, а найти компромисс. Если к продуктам какие-то практики были неприменимы, делали исключение (разумеется, после обсуждения всех аргументов, чтобы преодолеть обыкновенную ригидность, — с таким тоже сталкивались).
Спустя время я представил наработки команде, рассчитывая, что улучшения (в частности, почти полное автоматическое версионирование взамен постоянного ручного указания версии) смягчат горькую пилюлю изменений, и встретил… жесточайший отпор.
Почему так вышло?
Предложил переход на TBD. Мое впечатление о развитом автоматизированном тестировании оказалось заблуждением. Тестировщики просто не могли позволить себе дополнительную нагрузку по его совершенствованию. Кроме того, часть команды категорически не хотела отказываться от плагина, реализующего git-flow.
Попытался убедить сразу всех. Недооценил степень стресса от необходимости перемен и столкнулся с общим негодованием.
Однако это выявило инициативных коллег и помогло проявить их сильные стороны. В частности, лид разработки всегда играл роль арбитра и направлял спор в конструктивное русло, а ведущий разработчик java, несмотря на самое живое участие в спорах, был готов идти на компромиссы.
Роман Волков
Senior DevOps в MTC Web Services
Управление изменениями — через каскадирование эпиков в Jira
Их создавал центр практик, затем они копировались в пространства кластеров, а оттуда дублировались в продуктовые команды. На пике трансформации у команд до 25% бэклога уходило под различные стратегические изменения, в том числе на преобразование процессов.
Jira помогает фиксировать задачи, но это не самый эффективный инструмент для взаимодействия с людьми. Чтобы «продавать» новые механизмы, работать с возражениями, минимизировать стресс и уменьшать неопределенность, мы запустили регулярные открытые встречи. Каждые шесть недель мы собирались, чтобы рассказать о ценностях новых практик, о процессе и сроках внедрения, отвечали на вопросы и успокаивали коллег.
Я изучил замечания, сделал выводы и сел за вторую версию пайплайна. По его завершении позвал инициативную группу на обсуждение процесса и показал, как он работает прямо сейчас.
Коллег устроили предложения, и мы смогли договориться о следующей встрече, чтобы на ней обсудить конкретные шаги для перехода к новому процессу и нарезать задачи. Между собраниями инициативная группа должна была убедить коллег, что изменения будут плавными и не такими болезненными, как думалось. А я за это время еще раз проанализирую требования к переезду.
Здесь не последнюю роль сыграло наличие тех самых эпиков «сверху». Ими подкреплялась необходимость некоторых новинок. Например, переход на единые шаблоны helm отлично ложился на требование унификации скриптов развертки.
Спустя время и пару спокойных обсуждений мы двинулись по нашему плану, распределив нагрузку между всеми членами команды. Работа с активистами позволила даже переехать в новую группу репозиториев и разбить общие на отдельные, существенно облегчив внедрение пайплайна (общие для групп переменные). А ведь при первом обсуждении это казалось почти невозможным, так как у каждого разработчика репозитории хранились локально — «удобно».
Без ошибок и дополнительной ночной нагрузки, чтобы утром не расстраивать команду, конечно, не обошлось. Но все закончилось хорошо. Мы с коллегами уже работаем в других продуктах, но наш уютный CI/CD вспоминаем с теплотой.
Роман Волков
Senior DevOps в MTC Web Services
Плюсы нашего типизированного мира
Базовые процессы VCS (переезд в общий централизованный инструмент, правила идентификации и связанные с этим практики) внедрили 99% команд. Более сложные этапы — расширенный CD или появившийся позже Quality Check (автоматизированные проверки с использованием определенных инструментов в пайплайне) — применяют свыше 70%.
Как и прежде, помогаем оставшимся достичь общего уровня. Большая часть из них — продукты, появившиеся извне. С ними мы проходим путь к стандартизации с самого начала. Свои новые разработки, конечно, строим сразу в соответствии с принятыми практиками.
В итоге команды освободились от непрофильных DevOps-задач. Тем, кто раньше использовал собственные «велосипеды», теперь ��е нужно тратить время, инфраструктуру и бюджет на их настройку, поддержку и починку. Централизованные инструменты мы развернули в соответствии с лучшими практиками и довольно жесткими SLA, поскольку они mission critical. Массовых инцидентов с ними не зафиксировано.
Теперь проще шарить знания между командами в компании. Инженерам гораздо легче менять проекты: вне зависимости от причин и направления ротации, даже если человек переходит в другой кластер, на новом месте он будет работать с теми же инструментами.
В плане управления процессы стали намного прозрачнее. Мы подняли бюджеты на поддержание всей инфраструктуры разработки. Но главное — выросла производительность и появилась возможность измерять продуктивность, собирать разные метрики состояния команд. Так мы можем анализировать узкие места в пайплайнах и улучшать процессы.
Интересно, что вокруг этих изменений мы смогли собрать одно из крупнейших технических сообществ в MWS: инженеров DevOps, разработчиков, тестировщиков, системных администраторов и инженеров поддержки. Мы дружно ноем об адаптации практик, проводим митапы и обучаем на отдельном трехмесячном курсе тому, что должен уметь DevOps-инженер в MWS.
На этом у меня все. Готов ответить на ваши вопросы.