Когда в вашем ИТ-ландшафте есть «маленькая шлюпка», представляющая собой один контейнер, — это понятная и легко управляемая история. Если же речь идет о «Титанике», множестве контейнеров, то все уже не так просто, как хотелось бы. Когда же вы вырастаете до целой флотилии, где каждый корабль — это отдельный кластер Kubernetes, то здесь возникают нюансы.
Всем доброе утро! На связи Крылов Александр, CPO «Штурвала». В статье я поделюсь опытом, как подойти к этой проблеме системно: внедрить DevOps as a Service так, чтобы он стал не «еще одной модной практикой», а реально работающим сервисом внутри enterprise. Разберем, какие сложности чаще всего встречаются на пути, какие метрики помогают понять, что вы движетесь правильно, и как справляться с сопротивлением команд.
Кому будет полезно:
Техническим директорам (CTO) и архитекторам, которые ищут способы упорядочить хаос в инфраструктуре.
Руководителям DevOps и платформенных команд, которым важно отладить процессы без постоянного «ручного управления».
DevOps-инженерам — чтобы взглянуть на свою работу с позиции «сервиса внутри компании».
Продуктовым и проектным менеджерам — чтобы понять, как DevOps-платформа влияет на скорость вывода новых фич.
Всем, кто сталкивается с «зоопарком инструментов», долгими согласованиями и непредсказуемыми сроками релизов.
Принципы DevOps as a Service
Начнем с базы. DevOps as a Service (DaaS) — это выстроенный процесс работы инженерного подразделения компании, при котором компетенции DevOps-инженеров предоставляются как «сервис под ключ» — за счет автоматизации развертывания чего-либо «по кнопке» или с помощью выделения ресурсов под конкретные проект/активность/систему.
Основные принципы DaaS:
Наличие единой команды DevOps для компании со сквозным процессом взаимодействия с командами и понятными стейкхолдерами;
Существование enabling team;
Ежеквартальный пересмотр аллокации ресурсов между различными стейкхолдерами (активности, проекты, продукты, системы, пилоты или MVP технологий);
Наличие единого процесса привлечения аллокации инженеров для новых проектов, систем, продуктов и активностей. А при необходимости — и опрос-листов для старта.
Теперь давайте рассмотрим наиболее частые сценарии, при которых внедряют DaaS:
Компания активно применяет практики DevOps и CI/CD и имеет собственную команду DevOps, ресурсы которой ежеквартально распределяются под проекты или системы. При этом компания не пользуется услугами аутстафа, аутсорса или консалтеров.
Под каждый проект выделяются один–два DevOps-инженера. После его завершения ресурсы перераспределяются на другие задачи или проекты.
Специалисты DevOps гибко перемещаются между проектами. После завершения одного проекта их время высвобождается для новых задач.
Над каждым проектом работает смешанная команда. Все как в первом сценарии, но уже с привлечением внешних ресурсов.
DaaS нужен, чтобы управлять ростом без хаоса. Когда в компании много команд разработки, каждая начинает работать по-своему и использовать разные инструменты. Получается «зоопарк технологий», которым сложно управлять. DaaS наводит порядок и упрощает поддержку всей этой сложной системы.
Ниже перечислю основные бенефиты от использования (на самом деле, их гораздо больше):
Выполнение работ под ключ. При данном подходе DevOps-инженерам необязательно постоянно согласовывать фронт работ или взаимодействовать со стейкхолдерами. Им понятен процесс и достаточно просто поставить задачу с измеримым результатом, например: «поднять CI/CD для системы N на таком-то стеке для такого-то фреймворка и прочее».
Контроль качества (MTTD, MTTR, MTTF и другие метрики). Мониторинг полученного результата, включающий метрики эффективности команды и инфраструктуры. При этом метрики могут строиться как по продукту или конвейеру разработки, исходя из проблематики, так и по работе системы или решения в продуктиве.
Стандартизация и унификация процессов и инструментов. Все команды начинают использовать единые инструменты CI/CD и инфраструктуру развертывания — Kubernetes, GitlabCI, Ansible, Helm и другие. Проведение аудита помогает избавиться от «дублирующихся» инструментов и тем самым высвободить ресурсы команды для других задач. Помимо этого, когда все участники понимают «правила игры» и критерии пересмотра приоритетов и сроков по задачам, становится проще управлять бэклогом команды. Если не выстроить сквозной приоритет, то получится как в том меме, где вы приходите и пытаетесь подружить много собачек друг с другом.
Уменьшение T2M. Разработчики получают готовые сервисы, необходимые им для работы «по кнопке», и не тратят время на согласования и настройку. Например, кластер K8s со всеми обвязками CI/CD можно получить всего за 5 минут вместо нескольких недель.
Уменьшение TCO подразделения DevOps. Получается избежать дублирование усилий: одна команда DevOps поддерживает инфраструктуру CI/CD и все инструменты, которые в нее входят. Также за счет централизованного управления и контроля ресурсов получается оптимизировать финансовые затраты.
Каждому свое
Что значит внедрить DaaS? А точнее — как понять, эффективно ли он влияет на процессы?
При выборе той или иной практики стоит опираться на следующие факторы:
Особенность культуры разработки в команде или компании
Принятые процессы и правила разработки
Наличие процессов и видов тестирования
Степень бюрократизации — есть ли возможность менять устоявшиеся процессы или создавать новые?
Особенность релизного цикла систем и продуктов
Объем команд разработки, тестирования и архитектуры, а также количество инженеров поддержки
Также полезно ответить на ряд вопросов:
Что болит?
Нужны ли метрики?
Что и зачем будем делать прозрачнее?
Что хотим видеть, чего нет сейчас?
Какую задачу решаем?
К какому результату стремимся?
Что намерены делать с этим результатом в дальнейшем?
Теперь давайте коротко пройдемся по самым популярным способам оценки того, как в компании настроены процессы разработки и DevOps. Их стоит воспринимать как некое «среднее по больнице» (более подробно я рассматривал их тут).
1) Maturity model от Accenture. Классическая модель зрелости, местами пересекающаяся с SMMI в разрезе культуры и практик DevOps, применяющихся на одном проекте, но не в отношении всей разработки.
В рамках подхода проводится аудит зрелости процессов команды DevOps и степени автоматизации конвейера CI/CD с выявлением проблемных зон. Сбор информации осуществляется эмпирическим путем на основе таблицы критериев, распределенных по уровням зрелости: инструменты конвейера CI/CD, степень автоматизации, мониторинг, тестовые окружения и время их развертывания и остальное. После этого формируются план улучшений, вектор развития компетенций команды и желаемый уровень автоматизации конвейера CI/CD.
2) Maturity model от Gartner. Достаточно старый подход, изначально основанный на опросниках, в которых собиралась картина аудита ИТ-процессов в компании, а после трансформировалась в аудит DevOps. Предусматривает пять уровней зрелости организации, рассматривающих культуру, процессы разработки и автоматизацию. Конечный результат такой же, как и в первом пункте, но методика сводится к заполнению опросников.
3) DORA Capabilities. Команда DevOps Research and Assessment (DORA) выявила практики, которые повышают производительность программного обеспечения и организации. Здесь можно почитать, как реализовать, улучшить и измерить эти возможности.
А вот наглядная схема, демонстрирующая, какие метрики можно использовать в вашей команде или компании.
Подход предполагает определение проблемы, которую необходимо решить. Для этого нужно выделить набор метрик и сформировать план по их улучшению. Здесь важно отслеживать прогресс. Если появляются новые проблемы — определяете новые метрики и повторяете цикл по кругу столько, сколько потребуется.
4) DASA Radar. Модель компетенций DevOps включает набор важных навыков и, собственно, компетенций, необходимых для улучшения совместной работы, повышения гибкости и ускорения цифровой трансформации организации. По сути, это нечто среднее между первым и вторым подходами, но с иной визуализацией и другими критериями аудита. Этот метод позволяет оценить прямое влияние практик DevOps на бизнес продукта. Пример такого радара ниже.
5) DevOps Governance. Про этот подход я подробно рассказывал в прошлых своих статьях: почитать можно здесь и здесь.
Скорее всего, вам подойдет не конкретный подход, а что-то общее от перечисленных или других известных практик. Выбирая что-то для себя, не забывайте про Best practices VS Effective practices — между возможностями, «средним по больнице» и вашей индивидуальностью.
Этапы внедрения DaaS
Допустим, вы поняли, что следующий шаг в эволюции вашей компании — это создание единых стандартов, набора инструментов CI/CD и появление сквозной службы, которая будет управлять всеми продуктами и проектами. С чего начать?
Заручиться поддержкой топ-менеджмента. Прежде всего надо изучить основные боли команд, предложить решения, например, в формате slide-desk, и защитить их на уровне C-level. Далее важно протестировать концепт на фокус-группе потенциальных последователей и получить от них обратную связь.
Управлять сопротивлением. Это самый тяжелый этап, длиною в 3–6 месяцев, потому что придется менять привычки всего ИТ-отдела. Разработчики и тестировщики уже привыкли работать по-старому, и переучивать их будет сложно. Хороший референс по работе с сопротивлением — теория Джона Коттера или фреймворк «метод аккордеона». Ваша главная задача — не заставлять, а убеждать — находить сторонников ваших идей и аккуратно работать с теми, кто против.
Например, при унификации инфраструктурного микросервисного пласта на базе K8s в разных командах использовался разный инструмент поставки, вы решили массово перейти только на ArgoCD + GitlabCI + Helm, а от всего остального отказаться. Бунт неизбежен, работы будет немало, особенно в тех местах, где легкий переход невозможен, утеряна документация по сервисам и их зависимостям, и задача перехода превращается в крупный проект со всеми вытекающими в виде увеличения сроков и трудозатрат.
Непосредственное внедрение DaaS с обучением сотрудников, которым нужна адаптация. В это время важно собирать обратную связь с команд, которые начинают жить по новому процессу, и корректировать моменты, которые оказались нежизнеспособными. В среднем этап занимает от 1 до 8 месяцев, в зависимости от масштаба перехода.
Работа с обратной связью. Запомните, что вы не высекаете правила в монолите и можете их менять по запросам команды или тогда, когда что-то работает не так, как задумывалось. Но в рамках здравого смысла! При этом данный этап должен иметь конечный срок и критерии успешности, чтобы можно было считать внедрение завершенным. Тут можно провести аналогию с ПМИ, когда есть четкие критерии успешности по завершению проекта или пилота. Когда мы понимаем, что закрыты все основные проблемы (стабильность работы инфраструктуры, унификация инструментов автоматизации и прочее), то внедрение можно считать успешным. Далее сбор обратной связи просто переводим в рутинную задачу.
Выводы
DaaS — это отличный старт, но на этом ваш путь к цифровой трансформации не заканчивается. Дальше важно вывести эффективность на новый уровень, начав предоставлять все ключевые технологии как готовые сервисы: от развертывания окружений и CI/CD-пайплайнов до управления базами данных и Kubernetes-кластерами.
Такой подход не просто ускорит вывод новых функций на рынок — он высвободит ценные ресурсы команд, позволив им сосредоточиться на главном: создании продуктов, а не поддержке инфраструктуры.
Как показывает практика, внедрение DaaS трансформирует ИТ компании, принося ощутимые преимущества, например, сокращение Time to Market. Однако важно помнить, что после завершения подобных изменений перед вами неизбежно встанут новые вызовы, к которым стоит подготовиться заранее. Одним из таких вызовов может стать внедрение Kubernetes as a Service (KaaS).
Про внедрение подхода Kubernetes as a Service мы расскажем в следующей статье. До новых встреч!