Выбор подходящей DevOps топологии

Почему я должен это читать?

Вы работаете в организации, которая хочет раскрыть преимущества работы по DevOps принципам. Вы слышали такие термины, как “платформенная команда” и “SRE” и понимаете, что значит фраза “you build, you run it”. Однако эти термины делают ваше погружение в DevOps только сложнее и теперь вам нужно еще и выбирать как организовывать вашу команду/команды. В этой статье приводится обзор трех наиболее подходящих DevOps топологий иобъясняется в каких условиях каждая из них применима.

Для примера, публикация “DevOps topologies” от Matthew Skelton дает отличный обзор различных организационных топологий. Эти топологии так или иначе применялись во многих компаниях в их поисках гибкости и ускорения с помощью DevOps. Несмотря на большое количество топологий, я считаю, что они являются вариантами этих трех видов:

  1. Все команды продуктовые. Каждая продуктовая команда делает все необходимое для работы их приложений, включая использование любых инфраструктурных компонентов, обычно облачных PaaS сервисов.
  2. Платформенные команды и продуктовые команды. Продуктовые команды используют платформенные/инфраструктурные сервисы, которые предоставляет платформенная команда/ы. Сервисы могут быть самыми разнообразными от инфраструктурных до мониторинга, CI и дашбордов.
  3. Платформенные команды, продуктовые команды и команда SRE. Эта топология основана на лучших практиках компании Google.Продуктовые команды могут получить помощь от SRE команд в эксплуатации их приложений, если необходимо и при условии, что приложение удовлетворяет стандартам, определенным SRE командами. SRE команды могут разделять on-call вместе с продуктовыми командами. Платформенная команда/ы предоставляют платформенные/инфраструктурные сервисы.

Какая топология подойдет лучше всего вашей компании, зависит от ее текущей иерархии, размера, требований регуляторов и навыков сотрудников. Также важно понимать, что каждая из топологий имеет подводные камни, которые нужно учитывать.

Все команды продуктовые

Эта топология возможно является наиболее популярной. Каждая команда придерживается принципа “you build it, you run it” и использует и поддерживает выбранную инфраструктуру и инструменты. Это означает, что у команды должно быть довольно много экспертизы для эксплуатации своих сервисов/приложений.

Пример топологии, где все команды продуктовые

Возможные преимущества:

  • Команды обладают полной автономностью в создании и эксплуатации своих продуктов;
  • Командам не нужно делить инфраструктуру и инструменты;
  • Нет разделения ответственности за эксплуатацию приложений;
  • Ответственностью легко управлять;
  • Продуктовые команды могут двигаться в сторону автоматизации в своем темпе;

Возможные проблемы:

  • Потенциальная неэфективность. Команды могут и будут строить свои собственные решения для каждой проблемы. Переиспользование утилит и инфраструктурных компонентов между командами ограничено;
  • Каждая отдельная команда нуждается в своем эксперте в области инфраструктуры и безопасности;
  • Каждой команде будет нужно время на поддержку своей инфраструктуры и инструментов;
  • Каждой команде нужно будет создавать решения для соответсвия требованиями регуляторов;

Эта топология хорошо подходит вашей организации, если:

  • Ваша компания использует облачные сервисы (которые могут быть автоматизированы) для инфраструктуры;
  • Ваша компания/отдел состоит из 1–5 команд или может предоставить каждой команде всю необходимую экспертизу;
  • Требования регулятора, например аудит логов, не должны быть стандартизированы;
  • Невыгодно создавать отдельную команду, которая будет предоставлять инфраструктуру и инструменты для продуктовых команд;
  • Вы фокусируетесь на скорости и вы не сильно заботитесь о стандартизации. Фокусирование на скорости — это хорошая идея, когда вы хотите понять преимущества DevOps без необходимости реорганизовать все команды в компании;
  • У вас нет классического IT-ops отдела/команды, потому что вы модный стартап;

Платформенные команды и продуктовые команды

Как только ваша компания становится достаточно большой, имеет смысл организовать одну или больше платформенных команд, которые будут предоставлять платформенные сервисы (например инфраструктурные и/или CI/CD). Платформенные команды предлагают свои сервисы в формате API различным продуктовым командам. Часто платформенные команды сами используют облачную инфраструктуру для создания сервисов поверх нее. Например, платформенная команда может предоставлять платформу для запуска контейнеров как сервис с настроенными подключениями и системой доступов, удовлетворяющими требования компании.

Пример топологии с платформенной и продуктовой командами

Возможные преимущества:

  • Эффективное переиспользование платформенных сервисов между продуктовыми командами;
  • Переиспользование инфраструктурных компонентов порождает в качестве побочного эффекта стандартизацию;
  • Продуктовые команды избавлены от поддержки инфраструктуры и инструментов;
  • Разделение задач между платформенной и продуктовой командой означает, что продуктовая команда может сфокусироваться на доставке ценности пользователю. А платформенная команда в свою очередь на обеспечении сервисов для работы приложений;
  • Требования регуляторов, например аудит логов, могут быть легко выполнимы благодаря использованию сервисов, предоставляемых платформенной командой;

Возможные проблемы:

  • Product Owner платформенной команды должен одновременно иметь понимание будущего развития платформы и удовлетворять требования продуктовых команд;
  • Продуктовые команды нужно обучать давать регулярный фидбек платформенной команде вместо того, чтобы создавать свои собственные инструменты всякий раз, когда платформа не может их предоставить;
  • Платформенные команды должны иметь возможность собирать фидбек от продуктовых команд;

Эта топология хорошо подходит вашей организации, если:

  • Дешевле иметь платформенную команду, поддерживающую инфраструктуру/сервисы, чем строить их в каждой продуктовой команде отдельно. Эта граница зависит от организации;
  • По требованиям регулятора какие-то сервисы должны быть стандартизированы;
  • Вы не можете выделить каждой продуктовой команде своего эксперта в области инфраструктуры и безопасности;
  • Вы хотите стандартизировать вашу инфраструктуру и инструменты;
  • Вы отдали на аутсорс вашу инфраструктуру и инструменты;
  • У вас уже есть IT-ops отдел и ваш бизнес очень зарегулирован, например банки или гос. органы;

Платформенные команды, продуктовые команды и команда SRE

Согласно определению Ben Traynor, SRE команда — это “то, что случается когда разработчику ставятся задачи эксплуатации”. Ben Traynor — это основатель первой SRE команды в Google. Кто-то может поспорить, что SRE команда это то же самое, что классическая IT-operations команда, и не отвечает таким DevOps принципам, как ответственность от начала до конца. Отличие SRE модели состоит в модели общей ответственности между продуктовыми и SRE командами. Больше узнать о SRE модели можно из бесплатной книги от Google, доступной по ссылке https://landing.google.com/sre/book.html.

Платформенные команды предоставляют свои сервисы в форме API различным продуктовым командам.

Пример топологии SRE/платформенная/продуктовая команда

Возможные преимущества:

  • Продуктовым командам нужно сильно меньше экспертизы в эксплуатации, чем в предыдущих вариантах. Эта экспертиза может быть сосредоточена в SRE командах;
  • SRE команда активно обучает продуктовые команды как улучшить качество их приложений и их эксплуатации;
  • SRE команды постоянно ищут возможности улучшить и автоматизировать эксплуатацию и доставку ПО;
  • Продуктовые команды, которые ответсвенны за бизнес-критичные приложения чувствуют себя спокойнее за их эксплуатацию благодаря поддержке SRE команды;

Возможные проблемы:

  • Разница между SRE и классической IT-ops командой в нюансах. Непонимание этих нюансов просто приведет к усложнению организационной структуры;
  • Члены SRE команды должны иметь навыки менторства и разработки;

Эта топология хорошо подходит вашей организации, если:

  • У вас ограничено количество IT-ops специалистов;
  • Существующие IT-ops специалисты имеют обширные навыки менторства;
  • Существуют разные требования к экспертизе Ops в разных продуктовых командах. Например одной продуктовой команде с бизнес-критичным сервисов требуется SRE команда, в то время как другая может поддерживать свой сервис сама;
  • В вашей компании более пяти продуктовых команд;
  • У вас уже есть IT-ops отдел, который отделяет infrastructure-ops команды от application-ops команд;
  • У вас крайне зарегулированый бизнес, например банк или гос. органы;
  • Вы отдали на аутсорс вашу инфраструктуру и инструменты;
  • Вы хотите быть уверенными, что продуктовая команда с бизнес-критичным сервисом придерживается заданных критериев качества;

Я прочитал статью, что теперь?

Будет ли для вас работать конкретная DevOps топология крайне зависит от контекста вашей организации. Топологии, описанные в этой статье, не являются взаимно исключающими. Вы можете смешивать и выбирать их на вашем пути к DevOps. Запомните, что в его начале жизненно важно максимизировать обучение. Только с помощью обучения на базе вашего опыта вы сможете понять какая из топологий вам подходит на каждом этапе этого пути.

Одно точно: копирование успешных историй других компаний не работает. Но вдохновляет.

Что еще можно прочитать по этой теме: