Вступление
Основная цель DevOps в любой организации - улучшить качество поставки ценности клиентам и бизнесу, а не уменьшить расходы, улучшить автоматизацию или внедрить систему управления конфигурацией. Следовательно для эффективного взаимодействия разработки (Dev) и эксплуатации (Ops) в разных организациях нужны разные структуры команд.
Резюме
Какая именно структура DevOps команды подойдет организации зависит от нескольких факторов:
Набор продуктов организации: чем меньше программных продуктов, тем проще взаимодействие, вследствие меньшего количества естественных барьеров описанных законом Конвея.
Степень, качество и эффективность технического управления; имеют ли разработка и эксплуатация общие цели.
Готовность и желание организации изменить отдел эксплуатации в соответствии со своим потоком создания ценностей, и готовность продуктовых команд относиться серьезно к эксплуатационным особенностям.
Наличие в организации способности и навыков взять инициативу в вопросах эксплуатации.
Конечно, существуют различные вариации решений в поднятой проблематике; структуры и паттерны приведены как примеры и справочный материал для оценки применимости тех или иных шаблонов. На практике, чаще всего лучшим решением является комбинация нескольких шаблонов или шаблон меняющийся в другой.
Так какая структура команды нужна для процветания DevOps? Очевидно, что не существует серебряной пули или структуры команды, которая подошла бы любой организации. Тем не менее, будет полезно описать несколько различных моделей построения команд, некоторые из них подойдут конкретной организации лучше остальных. Изучая сильные и слабые стороны структур команд (или топологий), можно найти такую структуру, которая наилучшим образом подойдет для реализации DevOps практик в вашей организации, учитывая закон Конвея.
Большинство DevOps топологий уже были ранее описаны. В частности, Lawrence Sweeney из CollabNet описывает интересные подробности в комментариях к публикации в блоге Ben Kepes о структурах, которые я обозначил как Антипаттерн B (Отдельная DevOps команда), Паттерн 3 (Эксплуатация как IaaS), и Паттерн 1 (Сотрудничество команд разработки и эксплуатации). У DevOpsGuys есть список из двенадцати антипаттернов DevOps, и у Jez Humble, Gene Kim, Damon Edwards (и многих других) есть подобные списки. Я добавил три дополнительные 'топологии', которые я редко встречал (Полностью распределенные функции эксплуатации, DevOps как внешний сервис и Временная DevOps команда).
Антипаттерны DevOps
Полезно взглянуть на ряд плохих практик, которые мы можем назвать ‘антипаттернами‘.
Антипаттерн A: Изоляция Разработки и Эксплуатации
Это классическая схема с ‘перебрасыванием через стену‘ между Разработкой и Эксплуатацией. Она означает, что задачи могут быть закрыты преждевременно (статус СДЕЛАНО означает, что ‘фича готова‘, но не что она работает в производственном окружении), и работоспособность продукта страдает из-за того, что у Разработки недостаточно контекста об эксплуатационных особенностях, а у Эксплуатации нет времени или желания связываться с Разработкой, чтобы решить проблемы до того, как продукт будет запущен.
Вероятно, всем понятно, что это плохая структура, но я, на самом деле, считаю, что имеют место быть и худшие структуры. В случае Антипаттерна А (Изоляция Разработки и Эксплуатации) мы хотя бы знаем, что здесь есть проблема.
Антипаттерн B: Отдельная DevOps команда
Отдельная DevOps команда (Антипаттерн B) — типичный результат решения менеджера или исполнительного директора о том, что "нам нужно немного этого самого DevOps-а", и создания ’DevOps команды’ (возможно полностью состоящей из так называемых ’DevOps-ов’). Члены DevOps команды быстро изолируются, держась подальше от Разработки и Эксплуатации и закрывая в собственный уголок навыки и инструментарий от ’невежд из Разработки’ и ’динозавров из Эксплуатации’.
Отдельная DevOps команда действительно имеет смысл в случае, когда она создается временно, скажем, на срок не более 12 или 18 месяцев, с явной целью сблизить Разработку и Эксплуатацию и с явным распоряжением распустить DevOps команду по истечении этого времени. Это образует то, что я называю 5-м Типом (Временная DevOps команда).
Антипаттерн C: Разработке не нужна Эксплуатация
Эта структура - порождение сочетания наивности и высокомерия разработчиков и менеджеров от разработки, особенно в начале работы над новым проектом или системой. Решив, что Эксплуатация - это пережиток прошлого ("Теперь у нас есть Облака, ведь так?"), разработчики сильно недооценивают сложность и важность эксплуатационной деятельности и навыков, и верят, что они смогут обойтись без них или просто обретут их в свободное время.
Подобную DevOps структуру Антипаттерна C, вероятно, в конечном итоге, нужно будет преобразовать или в структуру 3-го Типа (Эксплуатация как 'Инфраструктура-как-сервис') или в структуру 4-го Типа (DevOps как внешний сервис), когда их продукт станет более сложным и эксплуатационная деятельность начнет поглощать время для разработки. Только если такие команды понимают, что Эксплуатация такая же важная и значительная область как и Разработка, они способны избежать сильной боли и ненужных (и довольно типичных) эксплуатационных ошибок.
Антипаттерн D: DevOps как разработка инструментария
Для того чтобы "стать DevOps" без потери текущей скорости команды разработки (доставлять функциональные возможности), DevOps команда занимается работой над инструментарием, необходимым для пайплайнов разработки, управления конфигурацией, управления окружениями и т.д. В то же время, Эксплуатация продолжает быть в изоляции, а Разработка продолжает перебрасывать им приложения "через стену".
Хотя результатом работы такой отдельной команды могут быть преимущества в виде улучшенного набора инструментов, ее влияние ограничено. Фундаментальная проблема недостатка участия Эксплуатации и совместной работы в цикле разработки приложения осталась нерешённой.
Антипаттерн E: Переименованные сисадмины
Этот типичный антипаттерн для организаций с низкой инженерной зрелостью. Они хотят улучшить свои практики и уменьшить стоимость, но они не видят IT как основной двигатель бизнеса. Поскольку успехи с DevOps в отрасли теперь очевидны, они тоже хотят “сделать DevOps”.
DevOps становится всего лишь переименованием роли, уже известной ранее как системный администратор, без каких-либо культурных или организационных изменений. Этот антипаттерн становится все более и более распространенным из-за того, что недобросовестные рекрутеры начинают искать кандидатов с навыками автоматизации и инструментов. К сожалению, лишь их межличностные коммуникативные навыки могут сделать DevOps в компании процветающим.
Антипаттерн F: Эксплуатация встроенная в команду разработки
Организация не хочет держать отдельную команду эксплуатации, поэтому команды разработки берут на себя ответственность за инфраструктуру, управление окружениями, мониторинг и т.д. Однако, делать это в рамках проекта или продукта, означает подвергнуть эти элементы ограничению ресурсов и изменению приоритетов, которые приведут к непостоянным и полузаконченным решениям.
В этом антипаттерне организация демонстрирует недооценку важности и навыков, требуемых для эффективной IT эксплуатации.
Антипаттерн G: Изоляция разработчиков и DBA
Это форма Антипаттерна А (Изоляция разработки и эксплуатации), которая популярна в средних и крупных компаниях, где множество устаревших систем, зависящих от одного и того же набора данных. Эти базы данных настолько важны для бизнеса, что специализированная команда DBA, часто под зонтиком эксплуатации, отвечает за обслуживание, производительность и аварийное восстановление. Это можно понять. Проблема в том, что эта команда становится сторожем ворот от любых изменений базы данных, что, фактически, становится препятствием для небольших и частых поставок. (Основной принцип DevOps и непрерывной поставки).
Кроме того, как и эксплуатация в Антипаттерне А, команда DBA не участвует в раннем этапе разработки приложения, поэтому проблемы с данными (миграция, производительность и т.д.) обнаруживаются в конце цикла поставки. В сочетании с перегруженностью от поддержки множества приложений и баз данных, в конечном итоге это приводит к постоянному пожаротушению и давлению на процесс поставки.
DevOps структуры команд
В противовес антипаттернам мы можем посмотреть на некоторые структуры, в которых DevOps может работать
- 1: Сотрудничество команд разработки и эксплуатации
- 2: Полностью распределенные функции эксплуатации
- 3: Эксплуатация как 'Инфраструктура-как-сервис' (IaaS)
- 4: DevOps как внешний сервис
- 5: Временная DevOps команда
- 6: Команда DevOps евангелистов
- 7: SRE Команда (Модель Google)
- 8: Взаимодействие через контейнеры
- 9: Взаимодействие Разработки и DBA
Тип 1: Сотрудничество команд разработки и эксплуатации
Это 'земля обетованная' культуры DevOps: комфортное сотрудничество между командами разработки и командами эксплуатации, каждая из которых специализируется на своем, но, по мере необходимости, там где нужно. При этом, вероятно, есть много отдельных команд разработки, каждая из которых работает над отдельным или частично отдельным продуктовым стеком.
Я считаю, что модель 1-го Типа нуждается в достаточно существенных организационных изменениях для ее создания, а также в высокой степени компетентности в команде технического руководства. Разработка и эксплуатация должны иметь четко выраженную и очевидную полезную общую цель ('Доставка надежных, частых изменений' или что-то еще). Сотрудники команды эксплуатации должны уверенно сотрудничать с командой разработки, понимать и справляться с тестированием в разработке (test-driven), знать Git, а программисты должны серьезно относиться к эксплуатационным функциям и самостоятельно подключать сотрудников эксплуатации для реализации логирования и так далее, везде, где необходимо изменение культуры из недавнего прошлого.
Применимость Тип 1: организации с сильным техническим руководством.
Потенциальная эффективность: ВЫСОКАЯ
Тип 2: Полностью распределенные функции эксплуатации
Там, где команда эксплуатации была интегрирована в группу разработки продуктов, мы видим топологию Типа 2. Между задачами разработки и эксплуатации мало разделения и все сотрудники сфокусированы на общей цели. Это спорная форма Тип 1 (Сотрудничество команд разработки и эксплуатации), но она имеет свои возможности.
Такие организации, как Netflix и Facebook, практически разрабатывающих один веб-продукт, реализовали эту топологию Типа 2, но я думаю, что это, вероятно, не очень удобно за пределами узкого целевого продукта, поскольку бюджетные ограничения и контекстное переключение обычно присутствуют в организации с несколькими цифровыми продуктами, что заставит их разделить разработку и эксплуатацию, скажем, обратно к модели Типа 1. Эта топология также может быть названа «NoOps», поскольку нет отдельной или видимой команды эксплуатации (хотя Netflix NoOps также может быть Типом 3 (Эксплуатация как 'Инфраструктура-как-сервис')).
Тип 3: Эксплуатация как 'Инфраструктура-как-сервис' (IaaS)
Для организаций с довольно традиционным отделом ИТ эксплуатации, который не может или не будет быстро (достаточно быстро) изменяться, и для организаций, которые запускают все свои приложения в публичном облаке (Amazon EC2, Rackspace, Azure и т.д.), вероятно, поможет рассматривать эксплуатацию как команду, которая просто обеспечивает гибкую инфраструктуру, на которой развертываются и запускаются приложения. Внутренняя команда эксплуатации, таким образом, прямо эквивалентна Amazon EC2 или Инфраструктура-как-сервис (Infrastructure-as-a-Service).
Команда (возможно, виртуальная команда) разработки затем выступает в качестве источника знаний об эксплуатационных функциях, метриках, мониторинге, настройке серверов и т.д., и, вероятно, выполняет большую часть взаимодействия с командой IaaS. Тем не менее, эта команда по-прежнему является командой разработчиков, следует стандартным практикам, таким как TDD, CI, итеративное развитие, коучинг и т.д.
Топология IaaS разменивается некоторой потенциальной эффективностью, теряя прямое сотрудничество с командой эксплуатации, для более легкой реализации, возможно, получая ценность быстрее, чем в случае Типа 1 (Сотрудничество команд разработки и эксплуатации), который можно попытаться воплотить позже.
Применимость Тип 3: для организаций с несколькими различными продуктами и сервисами, с традиционным подразделением эксплуатации или чьи приложения полностью запускаются в публичном облаке.
Потенциальная эффективность: СРЕДНЯЯ
Тип 4: DevOps как внешний сервис
Некоторые организации, в особенности небольшие, могут не располагать финансами, опытом или персоналом, чтобы взять на себя инициативу в аспектах эксплуатации продукта, который они производят. Команда разработки может обратиться к поставщику услуг вроде Rackspace с просьбой помочь им построить тестовые окружения и автоматизировать их инфраструктуру и мониторинг, а также консультировать по поводу эксплуатационных особенностей, которые необходимо реализовать в ходе цикла разработки продукта.
То, что можно назвать DevOps-as-a-Service, может быть успешным и прагматичным выбором для маленьких организаций или команд, чтобы научиться автоматизации, мониторингу и управлению конфигурацией, и затем, возможно, перейти к модели 3-го Типа (Эксплуатация как 'Инфраструктура-как-сервис') или даже 1-го Типа (Сотрудничество команд разработки и эксплуатации), когда они расширятся и наймут больше персонала с фокусом на эксплуатацию.
5 Тип: DevOps команда с ограниченным сроком действия
DevOps команда с ограниченным сроком действия (5 Тип) в значительной степени похож на Антипаттерн B (Отдельная DevOps команда), но цель и продолжительность её существования совершенно другие. У этой временной команды есть задача сблизить Разработку и Эксплуатацию, в идеале к модели 1 Типа (Сотрудничество команд разработки и эксплуатации) или 2 Типа (Полностью распределенные функции эксплуатации), в конечном итоге став ненужной.
Члены временной команды будут ‘переводчиками’ между Разработкой и Эксплуатацией, будут предлагать безумные идеи в виде stand-up-ов и Канбан'а для команды эксплуатации, и будут думать о неприличных деталях наподобие балансировщиков нагрузки, управления сетевыми интерфейсами и SSL-offloading'ом для команды Разработки. Если достаточно людей начинает видеть значительное сближение Разработки и Эксплуатации, то у временной команды есть реальный шанс достичь своей цели. Принципиально, что долгосрочная ответственность за развертывание и диагностику продуктового окружения не должна быть возложена на временную команду, иначе это становится похожим на Отдельную DevOps команду (Антипаттерн B).
Применимость Тип 5: в качестве предшественника Структуре 1-го Типа, но остерегаясь Антипаттерна B.
Потенциальная эффективность: От НИЗКОЙ до ВЫСОКОЙ
Type 6: Команда DevOps евангелистов
Внутри организаций, в которых существует огромный разрыв между Разработкой и Эксплуатацией (или склонность к образованию разрыва), может быть эффективно иметь 'вспомогательную' DevOps команду, которая бы призывала Разработку и Эксплуатацию к диалогу. Это версия 5-го Типа (DevOps команда с ограниченным сроком действия), но где DevOps команда существует на постоянной основе с компетенцией содействия сотрудничеству и взаимодействию между Разработкой и Эксплуатацией. Членов этой команды иногда называют 'DevOps евангелистами', поскольку они помогают распространить понимание DevOps практик.
7 Тип: SRE Команда (Модель Google)
DevOps часто рекомендует, чтобы команда разработки присоединялась к ротации в дежурстве, но это не существенно. По факту, некоторые организации (включая Google) используют другую модель, с явной передачей 'из рук в руки' от Разработки к команде, которая запускает продукт, т.е. команде обеспечению надежности информационных систем (SRE). В этой модели команде Разработки нужно обеспечить данные тестов (логи, метрики и т.д.) команде SRE, показывая, что их продукт соответствует норме, чтобы дальше поддерживаться командой SRE.
По существу, команда SRE может отклонить продукт, который не соответствует эксплуатационной норме, запросив Разработчиков улучшить код перед его отправкой на продуктовое окружение. Взаимодействие между Разработкий и SRE происходит в пределах критериев эксплуатации, но когда команда SRE довольна кодом, они (а не команда Разработки) поддерживает его в продуктовом окружении.
Применимость Тип 7: Тип 7 применим только для организаций с высокой степенью инженерной и организационной зрелости. Остерегайтесь возвращения к Антипаттерну A если SRE/Ops команде говорят "Просто Блин Выкати Это".
Потенциальная эффективность: От НИЗКОЙ до ВЫСОКОЙ
8 Тип: Взаимодействие через контейнеры
Контейнеры убирают необходимость в некоторых типах взаимодействия между Разработкой и Эксплуатацией, перекладывая требования по развертыванию и сопровождению приложения на контейнер. В таком случае, контейнер выступает границей ответственности Разработки и Эксплуатации. В здоровой инженерной культуре, модель Взаимодействия через контейнеры работает отлично, но если Разработка начинает игнорировать эксплуатационные особенности, такая модель может вернуться к противоречащему 'мы и они'.
9 Тип: Взаимодействие Разработки и DBA
Для того чтобы преодолеть разрыв между Разработкой и DBA, некоторые организации экспериментировали с чем-то вроде структурой 9-го Типа, где возможности баз данных от DBA складываются с возможностями (или специализацией) от команды Разработки. Похоже, что это помогает перейти с Dev-ориентированного представления баз данных (по сути, просто тупое хранилище для приложений) на DBA-ориентированное (интеллектуальные, богатые источники бизнес-ценности).
Применимость Тип 9: для организаций с одной и более большими централизованными базами данных с множеством подключенных приложений.
Потенциальная эффективность: СРЕДНЯЯ