Статьи
Обучающие материалы
Интерактивные руководства
Топологии команд
Как четыре фундаментальные топологии влияют на внедрение DevOps.
Иэн Бьюкэнэн
Главный разработчик решений
Редакционная статья: Шана Ву
Изучите преимущества команд, ориентированных на потоки, а также узнайте о том, как они работают с командами разработки платформ и подсистем и дают командам возможность поставлять ценность клиентам.
Введение в топологии команд
Командам разработчиков нужно действовать как никогда быстро, чтобы поставлять ценность клиентам. Рост числа облачных решений, SaaS-продуктов и постоянно активных сервисов свидетельствует о том, что клиентам нужны новые функции, снижение числа ошибок и безотказная работа в течение 99,99 % времени (или более).
Чтобы удовлетворить эти потребности, организации внедрили методы agile (а с недавнего времени — и DevOps), которые обещают сократить время выхода на рынок и время выполнения, повысить частоту развертываний, развить культуру команд и расширить сотрудничество между командами и отделами.
На деле внедрение методов DevOps — непростая задача, однако в книге Team Topologies (Топологии команд) содержатся продуманные способы внедрения DevOps в организациях и сведения о том, какие команды могут принести максимум пользы. Эта книга дает представление о том, как в компании Atlassian рассматривают команды. Вместо того чтобы повторять эти выводы, мы хотим поделиться собственным взглядом на типы команд.
Первый шаг на пути к DevOps — определение существующей организационной структуры. Однако сегодня в компаниях есть множество различных типов команд, а в некоторых случаях отдельные команды берут на себя несколько ролей и обязанностей. Когда границы размыты, руководителям трудно представить общую организационную структуру и ответить на вопросы.
См. решение
Инструменты DevOps для всей команды
Связанные материалы
Создание культуры DevOps
- Сформированы ли все необходимые команды?
- Имеются ли области, в которых не хватает возможностей и которыми не занимается ни одна команда?
- Соблюдается ли в командах необходимый баланс между автономностью и поддержкой со стороны других команд?
Руководители команд по разработке и эксплуатации смогут лучше понять, имеются ли у них нужные команды, взглянув на свою организацию через призму топологии команд. Рекомендуется сократить число вариантов команд до четырех основных топологий, которые предельно понятны руководителям высшего звена и самим участникам команд:
- Команда, ориентированная на поток
- Команда разработки платформы
- Команда разработки сложных подсистем
- Команда поддержки
Имейте в виду, что эти типы команд могут принимать различные формы с учетом размера и зрелости компании. На практике чаще всего лучше скомбинировать несколько типов команд или преобразовать одну команду в другую.
Команда, ориентированная на поток
Команды, ориентированные на поток, концентрируются на одном важном потоке работы. Это может быть отдельный продукт или услуга, набор функций, путь пользователя или тип пользователя. Команда может максимально быстро, безопасно и независимо создавать и поставлять ценность клиентам или пользователям, не передавая части работы другим командам.
Команды, ориентированные на поток, работают над полным спектром поставок, поэтому им нужно быть ближе к клиенту. Кроме того, обычно они сразу работают по методике agile. Такая команда учитывает отзывы клиентов в циклах разработки и одновременно сопровождает программное обеспечение в рабочей среде.
Команды, ориентированные на поток, сформированы во многих компаниях по разработке программного обеспечения, однако другим организациям могут быть лучше знакомы структуры команд, организованных по функциям (т. е. отдельные команды для разработки, проектирования и контроля качества) вместо потоков поставки.
В организациях наиболее распространен тип команд, ориентированных на поток, поэтому роли других команд определяются с учетом этого типа. Командам, ориентированным на поток, нужно регулярно обращаться к вспомогательным командам (отделам разработки сложных подсистем, поддержки и разработки платформы), чтобы постоянно повышать скорость поставки и качество продуктов и услуг.
Команда разработки платформы
Команды разработки платформы позволяют командам, ориентированным на поток, автономно выполнять достаточный объем работы. Команда, ориентированная на поток, несет полную ответственность за создание, запуск и исправление проблем приложения в рабочей среде, а команда разработки платформы предоставляет ей внутренние сервисы для работы.
Команды разработки платформы создают возможности, которые доступны многим командам, ориентированным на поток, с небольшими накладными расходами. Оптимизируя продукт, команды разработки платформы минимизируют ресурсы и умственную нагрузку для команды, ориентированной на поток. Это приносит пользу и конечным пользователям, поскольку команды разработки платформы могут создать единый интерфейс для различных пользовательских интерфейсов или продуктов.
В Atlassian команды разработки платформы создают сервисы, которые используются во всех продуктах компании (например, в системе управления учетными данными). Кроме того, они должны предоставлять документацию, оказывать поддержку и давать пояснения командам, ориентированным на поток.
Команда разработки сложных подсистем
Команда разработки сложных подсистем отвечает за создание и обслуживание сектора системы, в работе с которым нужны специальные навыки и знания. Большинство участников команды должны быть специалистами в определенной области знаний, чтобы разбираться в работе подсистемы и вносить в нее изменения.
Задача этой команды — снизить нагрузку на команды, ориентированные на поток, которые разрабатывают системы, включающие или использующие данную подсистему. Команда разработки сложных подсистем обладает определенным опытом и навыками, благодаря чему командам, ориентированным на поток, не приходится развивать умения в областях, которые слишком сложны для их повседневной работы. Участники этой команды могут обладать специальными знаниями в области определенных микрослужб (например, платежного сервиса), алгоритмов или даже искусственного интеллекта.
Распространенная ошибка заключается в том, чтобы включить специалистов в каждую команду, ориентированную на поток, которая использует подсистему. Это решение может показаться эффективным, но в конечном счете оно не приносит экономической выгоды и находится вне области задач команды, ориентированной на поток.
Команда поддержки
Командам, ориентированным на поток, всегда нужно быть готовыми к быстрой поставке и оперативно реагировать на изменения, поэтому им трудно найти время для исследования, изучения и освоения новых навыков.
Команда поддержки, состоящая из специалистов в конкретной технической области (или по продукту), помогает восполнить этот пробел в возможностях. Такие команды концентрируются на исследованиях и экспериментах, чтобы вносить продуманные предложения по выбору инструментальных средств, фреймворков и экосистем, которые влияют на набор инструментов.
Благодаря этому у команд, ориентированных на поток, появляется время для приобретения и развития возможностей без ущерба для основных задач. Команда поддержки стремится прежде всего повысить автономность команд, ориентированных на поток, путем расширения их возможностей с акцентом на проблемах, а не на решениях.
Если команда поддержки хорошо справляется со своей работой, уже через несколько недель коллеги, которым она помогает, перестают нуждаться в помощи. Для команды поддержки не должно существовать постоянной зависимости.
Ориентирована ли ваша команда на поток?
Чтобы определить, ориентирована ли ваша команда на поток, задайте следующие вопросы:
Стремится ли ваша команда обеспечить постоянный поток функций?
Зрелые команды выпускают релизы несколько раз в неделю, а иногда и несколько раз в день. Чтобы достичь этой цели, опытным командам нужна непрерывная интеграция и непрерывная поставка (CI/CD) для частой поставки функций.
Быстро ли ваша команда реагирует на отзывы (клиентские или внутренние) о последних изменениях?
Часто для развития продукта наилучшим оказывается экспериментальный подход. Хорошо продуманные процессы DevOps включают автоматизированное тестирование, необходимое для выпуска качественного кода. Однако в экспериментальных исследованиях не стоит ограничиваться простым модульным или приемочным тестированием. Чтобы продукты приносили максимальную пользу для клиентов, можно использовать флажки возможностей для автоматизации развертываний среди различных групп пользователей, альфа- и бета-версии для запроса отзывов и оценки поведения пользователей, а также качественную непрерывную обратную связь через комментарии, заявки в службу поддержки и форумы сообщества.
Старается ли ваша команда передавать другим командам лишь самый минимум задач?
Если это так, команда должна соответствовать двум требованиям. Чтобы обеспечивать быструю поставку, команда должна быть самодостаточной и выполнять работу силами своих участников. Передача задач вне утвержденной области работ также может происходить в форме автоматизированных процессов. Автоматизация цикла разработки гарантирует бесперебойную передачу задач. При этом не важно, будет следующий этап связан с действием (например, автоматизированным тестированием), слиянием с главной веткой или реальным человеком.
Если ответ на следующий вопрос будет положительным, вы получите бонусные очки.
Есть ли у вашей команды время на повышение качества кода (так называемый «технический долг»), чтобы сделать изменения безопасными и легкими?
Опытные команды ведут базу кода с помощью методов магистральной разработки и CI/CD. При планировании производительности необходимо выделять время на решение проблемы технического долга. Кроме того, крупномасштабным проектам, которые решают проблемы базовой инфраструктуры или платформы, следует уделять внимание наравне с разработкой функций.
Используются ли для оценки команды правильные показатели?
Помимо скорости поставки следует также учитывать показатели технического качества и работоспособности команды.
Примечание по поводу последнего вопроса о показателях. Для определения «успешности» команды DevOps традиционно рассматривают четыре ключевых показателя DevOps Research and Assessment (DORA).
- Частота развертываний. Насколько часто организация успешно выпускает релизы в рабочую среду.
- Время внесения изменений. Промежуток времени до попадания коммита в рабочую среду.
- Частота сбоев при внесении изменений. Процент развертываний, приводящих к сбоям в рабочей среде.
- Время восстановления работы сервиса. Время, необходимое организации для восстановления после сбоя в рабочей среде.
Компания Atlassian обнаружила, что кроме показателей DORA высокоэффективные команды, ориентированные на поток, отслеживают следующие характеристики.
- Сбалансированность команды. В команде представлены разные навыки и точки зрения.
- Штатный владелец. Наличие штатного владельца гарантирует, что ядро команды и участники со множеством обязанностей знают, кому задавать вопросы и как принимать решения по проектам команды.
- Общее понимание. Существует общее понимание требований, определение ценностей и показателей успеха.
- Ориентация на ценность и показатели. У команды есть ориентиры, которые определяют, какие задачи нужно решить, чтобы приблизить проекты к релизу.
- Доказательство концепции. Наличие реального артефакта для дебатов и проверки допущений, который помогает команде постоянно выполнять итерации и вносить улучшения.
- Управляемые зависимости для поддержания скорости. Понимание управляемых зависимостей помогает команде избегать блокеров и поддерживать скорость.
Заключение
DevOps — это не пункт назначения, а путь постоянного совершенствования инструментов, культуры команды и методов. Если вы новичок в DevOps, сначала направьте цели на поставку ценности клиентам. Накопив опыт, снабдите инструменты и процессы автоматизацией. И наконец, когда участники команды станут опытными специалистами, добавьте средства наблюдения, чтобы отслеживать, измерять и улучшать нужные показатели.
Поделитесь этой статьей
Следующая тема
Рекомендуемые статьи
Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.
Сообщество DevOps
Образовательные программы DevOps
