Знаменитое изображение разработчиков, передающих свою работу в эксплуатацию, прочно запечатлелось в сознании первых приверженцев DevOps. Он подчеркнул необходимость объединения команд разработки и эксплуатации в единые команды DevOps, чтобы лучше сотрудничать при быстром выпуске приложений. Но на самом деле внедрение DevOps уже почти десять лет было сосредоточено на технической автоматизации разработки конвейеров CICD для приложений. Поэтому создание единых DevOps-команд отошло на второй план.
Оглядываясь назад, можно сказать, что это, вероятно, был правильный подход для того периода времени, поскольку без сквозной автоматизации скорость выпуска релизов была недостаточно высокой, чтобы требовать объединенной команды разработчиков и эксплуатации. Работа в рамках гибких итераций позволила сократить размер выпусков, но ручные действия и передачи по-прежнему приводили к удлинению циклов выпуска. Затем несколько циклов agile-спринтов были объединены в финальную версию. Поскольку более быстрых релизов по сути не было, необходимости часто сотрудничать между Dev и Ops не было, и поэтому необходимости ломать стену между Dev и Ops не ощущалось.
Но благодаря автоматизации CICD, а в некоторых случаях и чрезвычайной бесконтактной автоматизации, более высокая скорость публикации стала реальностью. Частота публикаций увеличилась с одного раза в девять месяцев до одного раза в неделю или даже чаще, по запросу. Таким высокоскоростным приложениям теперь приходится учитывать проблемы, связанные с частыми передачами от разработки к эксплуатации, для поддержки новых версий. Команды эксплуатации находятся под огромным давлением, требуя поддерживать тот же уровень обслуживания в производстве, несмотря на изменения, вызванные частыми выпусками. Растущая частота выпусков приложений является веским аргументом в пользу объединения команд DevOps. И мы видим, что все больше и больше организаций хотят формировать такие команды, по крайней мере, для своих цифровых приложений.
Заместитель вице-президента и руководитель подразделения DevOps COE в Infosys Limited.
Проблемы построения единой команды и пути их преодоления
Однако создать объединенные команды не так просто, как объединить Dev и Ops и назвать их одной командой. Создание успешных объединенных команд DevOps требует некоторых ключевых соображений.
Во-первых, если не произойдет явных изменений в корпоративной культуре и мышлении, будет нелегко заставить Dev и Ops работать над задачами друг друга с одинаковой приверженностью. Требуется изменение мышления, чтобы помочь им осознать более крупную цель и преодолеть барьер, связанный с расстановкой приоритетов одних задач над другими. Хороший «тренер DevOps» может помочь изменить это мышление с помощью таких методов, как внедрение, бизнес-взаимодействие, настройка общих ключевых показателей эффективности и показателей для всей команды, а также удаление любых показателей производительности для отдельных задач разработки или эксплуатации.
Во-вторых, «тренеру DevOps» необходима поддержка посредством организационных изменений, которые определят общего владельца продукта для единой команды DevOps. Владелец продукта, который понимает важность задач разработки и эксплуатации и может расставлять их приоритеты друг над другом в зависимости от потребностей бизнеса, играет решающую роль в команде. Без такого общего владельца продукта всегда будут проблемы с расстановкой приоритетов задач, и команды будут продолжать выполнять отдельные роли разработчиков или операторов.
В-третьих, создание команды Dev и Ops не приведет к созданию команды экспертов DevOps. И Dev, и Ops требуют межфункциональных навыков посредством очень структурированного подхода к обучению. Это не просто цель научить разработчика выполнять оперативные задачи и наоборот. Разработчикам также необходимо обширное обучение процессам поддержки, соглашениям об уровне обслуживания, анализу проблем и устранению неполадок. Самое главное, что им требуется более широкий опыт в предметной области и системах, чтобы правильно обнаруживать и решать проблемы. Точно так же недостаточно разрешить оперативным членам программировать, поскольку существуют разные уровни оперативной поддержки, такие как L1, L2 и L3, которые имеют свои собственные уровни опыта программирования. Непрактично ожидать, что они начнут программировать. «Тренер DevOps» должен создать план для каждого уровня операционной поддержки, который включает постепенное добавление мероприятий по разработке. Например, сотрудники службы поддержки L3, вероятно, смогут очень быстро освоить программирование и начать вносить вклад в пользовательские истории. Однако человек на уровне L2 не может сразу взаимодействовать с пользовательскими историями. Поэтому лучше использовать поэтапный путь обучения, который позволяет сначала работать над задачами L3, а затем над пользовательскими историями. Хороший тренер DevOps может создать такие индивидуальные пути обучения, а также планы ролей и ответственности, чтобы со временем сформировать по-настоящему межфункциональную команду.
Наконец, хотя может показаться, что составить план обучения на бумаге легко, найти время для очень занятых команд разработчиков и эксплуатации для изучения новых навыков и работы над другими задачами, отличными от текущих, является сложной задачей, влияющей на скорость или соглашения об уровне обслуживания. С чего они начинают в первую очередь? Следует ли вам понизить уровень некоторых пользовательских историй разработчиков и попросить их внести свой вклад в выполнение задач Ops, чтобы у Ops была возможность изучить навыки программирования? Или члены Оперативного штаба должны взять на себя инициативу? Хороший тренер DevOps может принимать контекстуальные решения о том, как создать достаточную пропускную способность, чтобы команды могли приобрести межфункциональные навыки, не влияя при этом на бизнес.
Трансформация людей
Подводя итог, можно сказать, что автоматизация проектирования CICD — это сложная часть внедрения DevOps, хотя вы думаете, что это определенно не так. Трансформация сотрудников всегда была очень субъективной темой, и не существует заранее определенного рецепта успеха. Легче сказать, чем сделать создание единых команд DevOps. Однако пристальное внимание к тому, как создаются эти команды под руководством опытного тренера DevOps, может усилить преимущества DevOps для любого приложения.
Мы представили лучшую платформу для совместной работы команд.
Эта статья была создана в рамках канала Expert Insights от TechRadarPro, где мы рассказываем о лучших и ярких умах в области технологий сегодня. Мнения, выраженные здесь, принадлежат автору и не обязательно отражают точку зрения TechRadarPro или Future plc. Если вы заинтересованы в участии, узнайте больше здесь:
