В 2013 году был представлен набор паттернов и антипаттернов —
DevOps Topologies, разработанный Matthew Skelton и впоследствии развиваемый совместно с Manuel Pais. Этот набор стал стандартом для анализа организационного дизайна и оценки взаимодействия команд в контексте современной разработки и поставки программного обеспечения. Он применялся в таких компаниях, как Netflix, Conde Nast International, Adidas, Accenture и др., для повышения инженерной культуры, процессов и практик, оптимизации границ ответственности и улучшения взаимодействия между командами разработки и эксплуатации. В 2019 году на основе паттернов был представлен подход Team Topologies и опубликована одноименная книга.
Авторы DevOps Topologies подчеркивают, что ключевая цель DevOps заключается в повышении эффективности поставки ценности для клиентов и бизнеса, а не в изолированном снижении затрат или росте автоматизации. Выбор подходящей структуры команд зависит от контекста организации: количества и разнообразия продуктов, зрелости и единства технического лидерства, готовности трансформировать функции эксплуатации в направлении выравнивания с потоком создания ценности, а также наличия компетенций для лидерства в операционных вопросах. Представленные топологии служат эвристикой для оценки организационного дизайна, т.к. на практике эффективным решением часто становится комбинация нескольких паттернов или их эволюционная трансформация по мере роста инженерной зрелости. Авторы утверждают, что не существует универсальной структуры команд, которая гарантирует успех DevOps во всех организациях, так как выбор топологии зависит от контекста и должен учитывать закон Конвея (Conway’s Law). Сравнение различных моделей позволяет выявить их сильные и слабые стороны и определить наиболее подходящий вариант для конкретной организации.
В DevOps Topologies входят 8 антипаттернов (Anti-Types: Dev vs Ops, DevOps Silo, No Ops Needed, Tools Team, SysAdmin, Embedded Ops, Dev vs DBA, Fake SRE) и 9 паттернов (Types: Dev+Ops, Shared Ops, Ops as IaaS, DevOps-as-a-Service, Temp DevOps Team, DevOps Advocates, SRE Team, Container-Driven, DB Capability), описывающих различные модели взаимодействия и организационного дизайна команд в контексте DevOps.
Anti-Type A: Dev and Ops Silos. Это классическое разделение по принципу "Throw it over the wall" между Dev и Ops, где задачи считаются завершенными после реализации функциональности, даже если система еще не готова к эксплуатации в Production. В такой модели страдает операционная устойчивость программного обеспечения: разработчики не обладают достаточным контекстом для учета эксплуатационных требований, а инженеры по эксплуатации не вовлечены в устранение проблем до вывода системы в Production. Несмотря на очевидные недостатки, по крайней мере в этой топологии наличие проблемы явно осознается.
Anti-Type B: DevOps Team Silo. Эта модель обычно возникает, когда руководитель решает, что организации «нужно немного DevOps», и создает отдельную DevOps команду, зачастую состоящую из людей с ролью DevOps. В результате формируется еще один изолированный контур, который еще сильнее разобщает Dev и Ops: новая команда начинает защищать свою зону ответственности, навыки и инструменты. Единственная ситуация, в которой отдельный DevOps Silo может быть оправдан, — это временный формат сроком менее 12-18 месяцев с четкой целью сблизить Dev и Ops и явным ограничением сделать саму DevOps команду избыточной по истечении этого периода.
Anti-Type C: Dev Don’t Need Ops. Эта топология возникает из сочетания наивности и самоуверенности со стороны разработчиков и руководителей разработки, особенно при запуске новых проектов или систем. Предполагая, что эксплуатация больше не играет существенной роли, команды разработки недооценивают сложность и значимость операционных компетенций, считая, что могут обойтись без них или выполнять соответствующие задачи в свободное время. На практике такая модель часто приводит к необходимости перехода к Type 3 (Ops as IaaS) или Type 4 (DevOps-as-a-Service), когда система усложняется и операционная нагрузка начинает вытеснять время, отведенное на разработку. Признание эксплуатации как самостоятельной и равноценной дисциплины позволило бы таким командам избежать значительного количества проблем и базовых операционных ошибок.
Anti-Type D: DevOps as Tools Team. В стремлении внедрить DevOps, не снижая текущую скорость разработки и поставки функциональности, организация создает отдельную команду, отвечающую за инструменты (Deployment pipelines, Configuration management, Environment management, etc). При этом специалисты Ops продолжают работать изолированно, а команды разработки по-прежнему передают им приложения по принципу "Over the wall". Несмотря на возможные улучшения в инструментальной цепочке, влияние такой модели ограничено. Базовая проблема отсутствия раннего вовлечения Ops и полноценного сотрудничества в рамках жизненного цикла разработки приложений остается нерешенной.
Anti-Type E: Rebranded SysAdmin. Этот антипаттерн характерен для организаций с низкой инженерной зрелостью, которые стремятся улучшить практики и сократить издержки, но не воспринимают ИТ как стратегический драйвер бизнеса. Видя успешные примеры DevOps в индустрии, они пытаются внедрить DevOps, однако вместо анализа структурных и организационных проблем просто нанимают DevOps инженеров в существующие команды. В результате DevOps сводится к переименованию роли SysAdmin без каких-либо реальных культурных или организационных изменений. Подобная модель становится все более распространенной на фоне спроса на специалистов с навыками автоматизации и инструментов.
Anti-Type F: Ops Embedded in Dev Team. В этой модели организация отказывается от отдельной Ops команды, и ответственность за инфраструктуру, управление окружениями, мониторинг и другие операционные задачи передается командам разработки. Однако при проектном или продуктовом подходах такие задачи оказываются зависимыми от ресурсных ограничений и частых пересмотров приоритетов, что приводит к неполноценным решениям и компромиссной реализации. Данный антипаттерн демонстрирует недооценку значимости и специфических компетенций, необходимых для эффективной эксплуатации.
Anti-Type G: Dev and DBA Silos. Это разновидность Anti-Type A (Dev and Ops Silos), характерная для средних и крупных компаний, где несколько Legacy систем зависят от общего ядра данных. Поскольку базы данных критичны для бизнеса, создается выделенная команда DBA, часто в контуре эксплуатации, отвечающая за сопровождение, настройку производительности и восстановление после сбоев. Проблема возникает тогда, когда эта команда становится Gate keeper для любых изменений в базе данных, что превращается в препятствие для частых и небольших релизов, являющихся основой Continuous Delivery. Кроме того, как и в Anti-Type A, команда DBA не вовлекается на ранних этапах разработки, поэтому проблемы, связанные с миграциями, производительностью и моделью данных, выявляются слишком поздно в цикле поставки. В сочетании с перегрузкой по сопровождению нескольких баз данных это приводит к постоянному режиму тушения пожаров и растущему давлению по срокам.
Anti-Type H: Fake SRE. Это разновидность Anti-Type A (Dev and Ops Silos), проявляющаяся спустя годы под новым названием. Инженеры эксплуатации начинают называть себя SRE, однако по сути модель взаимодействия не меняется: разработчики по-прежнему передают в эксплуатацию программное обеспечение, в котором реализована только функциональность, без обеспечения полноценной готовности к работе в Production. Операционная устойчивость систем продолжает страдать, поскольку разработчики не приближаются к реальной ответственности за работу своих сервисов в Production, а SRE не имеют достаточного времени для совместной работы с разработчиками по устранению возникающих проблем.
Type 1: Dev and Ops Collaboration. Эта модель предполагает зрелое и системное взаимодействие между Dev и Ops, при котором сохраняется специализация ролей, но ответственность за результат разделяется. Обычно в такой конфигурации действует несколько команд разработки, каждая из которых работает над собственным продуктом или его частью. Внедрение Type 1 требует организационной трансформации и зрелого технического лидерства. У Dev и Ops должна быть единая, ясно сформулированная и измеримая цель (например Delivering Reliable and Frequent Changes). Ops участвуют в инженерных практиках и взаимодействуют с разработчиками на уровне кода и процессов, а Dev учитывают эксплуатационные требования как неотъемлемую часть продукта и вовлекают Ops в вопросы наблюдаемости, логирования и архитектуры. Модель требует изменения культуры взаимодействия и отказа от изолированного мышления.
Type 2: Fully Shared Ops Responsibilities. В данной модели эксплуатационные компетенции встроены в продуктовые команды, и формального разделения между Dev и Ops практически нет: все участники работают в рамках общей ответственности за результат. Это развитие Type 1 (Dev and Ops Collaboration) с более высокой степенью интеграции и совместного владения операционными задачами. Такой подход возможен в организациях с единым продуктом, как у Netflix или Facebook, однако его масштабирование в многопродуктовой среде затруднено. При наличии нескольких продуктовых направлений бюджетные ограничения и частая смена приоритетов обычно усиливают специализацию и возвращают организацию к модели, близкой к Type 1. Данную топологию нередко называют NoOps, поскольку отдельная команда эксплуатации отсутствует, хотя на практике она может сочетаться с элементами Type 3 (Ops as IaaS).
Type 3: Ops as Infrastructure-as-a-Service (Platform). Эта модель подходит организациям с традиционным IT Operations, которое не готово к быстрой трансформации, а также компаниям, размещающим приложения в публичном облаке, таком как Amazon EC2, Rackspace или Azure. В этом случае эксплуатация рассматривается как провайдер облачной инфраструктуры для развертывания и эксплуатации сервисов, фактически работая по принципу внутреннего IaaS поставщика. Внутри Dev при этом формируется команда или группа экспертов, отвечающая за операционные аспекты: метрики, мониторинг, подготовку серверов и взаимодействие с IaaS командой. Несмотря на фокус на эксплуатационных вопросах, она сохраняет статус команды разработки и применяет стандартные инженерные практики, включая TDD, CI и итеративную разработку. Данная топология представляет собой прагматичный компромисс: организация жертвует частью глубины сотрудничества ради более простой и быстрой реализации, получая практическую ценность быстрее, чем при попытке сразу перейти к Type 1 (Dev and Ops Collaboration), к которому можно вернуться на более зрелом этапе.
Type 4: DevOps as an External Service. Эта модель характерна для организаций, преимущественно небольших, которым не хватает ресурсов, опыта или специалистов для самостоятельного управления операционными аспектами разработки. В такой ситуации команда разработки обращается к внешнему поставщику, который помогает выстроить тестовые окружения, автоматизировать инфраструктуру и мониторинг, а также консультирует по внедрению эксплуатационных практик в процессе разработки. DevOps-as-a-Service становится практичным способом получить необходимую экспертизу и заложить основу для автоматизации, мониторинга и управления конфигурацией. По мере роста организации возможен переход к Type 3 (Ops as IaaS) или к Type 1 (Dev and Ops Collaboration) с развитием собственных компетенций.
Type 5: DevOps Team with an Expiry Date. Эта модель внешне схожа с Anti-Type B (DevOps Team Silo), но принципиально отличается намерением и временными рамками. Команда создается как временный механизм изменений с четкой задачей сблизить Dev и Ops и вывести организацию к модели Type 1 (Dev and Ops Collaboration) или Type 2 (Fully Shared Ops Responsibilities), после чего должна утратить необходимость своего существования. Участники выступают связующим звеном между двумя контурами, помогая выстроить общий язык, процессы и практики. При условии, что организация принимает ценность интеграции, модель может быть успешной. Критически важно не закреплять за этой командой постоянную ответственность за развертывание и эксплуатацию, иначе она закрепится как изолированный DevOps Team Silo (Anti-Type B).
Type 6: DevOps Advocacy Team. Эта модель применяется в организациях, где между Dev и Ops существует устойчивый разрыв или риск его углубления. Создается постоянная фасилитирующая команда, задача которой — поддерживать регулярное взаимодействие и координацию между сторонами. В отличие от Type 5 (DevOps Team with an Expiry Date), такая команда не имеет ограниченного срока существования и действует на постоянной основе с мандатом на развитие сотрудничества. Ее участников часто называют DevOps Advocates, поскольку они продвигают практики, связанные с DevOps, формируют общее понимание целей и поддерживают изменения в культуре и способах взаимодействия между командами.
Type 7: SRE Team (Google Model). В этой модели участие команд разработки в дежурствах не является обязательным. Организация выстраивает явную передачу ответственности от команд разработки к отдельной команде Site Reliability Engineering (SRE), которая принимает систему в эксплуатацию. Для этого Dev должны предоставить доказательства качества и эксплуатационной готовности решения — логи, метрики и иные подтверждающие артефакты. SRE команда обладает полномочием отклонить сервисы, если они не соответствуют установленным операционным стандартам, и вернуть их на доработку до вывода в Production. Взаимодействие Dev и SRE фокусируется на проверке эксплуатационных критериев, после чего ответственность за работу системы в Production полностью переходит к SRE.
Type 8: Container-Driven Collaboration. В этой модели использование контейнеров уменьшает необходимость постоянной координации между Dev и Ops, поскольку требования к развертыванию и выполнению приложения фиксируются внутри контейнера. Контейнер тем самым задает четкую границу ответственности и формирует прозрачный контракт между сторонами. При зрелой инженерной культуре такая модель обеспечивает устойчивое взаимодействие. Однако при игнорировании эксплуатационных требований со стороны Dev она может привести к напряженному и разобщенному взаимодействию между командами.
Type 9: Dev and DBA Collaboration. В этой модели для сокращения разрыва между Dev и DBA организации формируют двустороннюю экспертизу по базам данных: компетенции DBA усиливаются участием специалистов внутри команд разработки, обладающих углубленным пониманием работы с данными. Это позволяет выстроить общий контекст и согласовать подходы — между восприятием баз данных как технического слоя хранения для приложений и пониманием их как стратегического актива и источника бизнес-ценности.