Глава 5

Архитектура

Мы уже видели, что внедрение практик непрерывной доставки повышает эффективность доставки, влияет на культуру и уменьшает выгорание и «боль развертывания» ПО. Однако архитектура вашего программного обеспечения и сервисов, от которых оно зависит, может быть существенным препятствием для увеличения как скорости, так и стабильности процесса выпуска релизов и поставляемых систем.

Кроме того, DevOps и непрерывная доставка возникли в веб-системах, поэтому законно спросить, могут ли они быть применены к системам мейнфреймов, микропрограммному обеспечению или к средней корпоративной среде с большим количеством систем с нераспознаваемой структурой (Фуут и Йодер, 1997), состоящей из тысяч тесно связанных систем.

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

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

Типы систем и эффективность доставки

Мы изучили большое количество типов систем, чтобы выяснить, существует ли корреляция между типом системы и эффективностью команды. Мы рассмотрели следующие типы систем как в качестве основной системы в разработке, так и в качестве интегрируемой службы:

• гринфилд (greenfield): новые системы, которые еще не были выпущены;
• системы взаимодействия (используются непосредственно конечными пользователями);
• системы записи (используются для хранения критически важной для бизнеса информации, когда жизненно необходимы согласованность и целостность данных);
• пользовательское программное обеспечение, разработанное другой компанией;
• пользовательское программное обеспечение, разработанное внутри компании;
• упакованное, коммерчески готовое программное обеспечение;
• встроенное программное обеспечение, которое работает на заводском аппаратном оборудовании (manufactured hardware device);
• программное обеспечение с компонентом, установленным пользователем (в том числе мобильные приложения);
• программное обеспечение вне мейнфреймов, которое работает на серверах другой компании;
• программное обеспечение вне мейнфреймов, которое работает на внутренних серверах;
• программное обеспечение для мейнфреймов.

Мы обнаружили, что участники исследования с низкими показателями с большей вероятностью говорили, что программное обеспечение, которое они создают, или набор сервисов, с которыми они должны взаимодействовать, — это пользовательское ПО, разработанное другой компанией (например, партнером на аутсорсинге). Они же с большей вероятностью работали над системами мейнфреймов. Интересно, что необходимость интеграции с системами мейнфреймов существенно не коррелировала с эффективностью.

В остальных случаях не было выявлено значимой корреляции между типом системы и эффективностью доставки. Мы были удивлены: мы ожидали, что команды, работающие над упакованным ПО, системами записи или встроенными системами, будут хуже, а команды, работающие над системами взаимодействия и системами гринфилд, — лучше. Данные показывают, что это не так.

Это делает еще более важным фокус на архитектурных характеристиках, обсуждаемых ниже, а не на деталях реализации вашей архитектуры. Достичь этих характеристик можно даже с помощью упакованного программного обеспечения и устаревших систем мейнфреймов — и, наоборот, использование новейшей архитектуры микросервисов, развернутой на контейнерах, не гарантирует более высокой производительности, если вы игнорируете эти характеристики.

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

Сфокусируйтесь на развертываемости и тестируемости

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

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

Представляется, что эти характеристики архитектурных решений, которые мы называем тестируемостью и развертываемостью, важны для создания высокой эффективности. Для достижения этих характеристик системы разработки слабо связаны, то есть могут быть изменены и проверены независимо друг от друга. В обзоре 2017 года мы провели анализ, чтобы проверить, насколько слабосвязанная, хорошо инкапсулированная архитектура влияет на эффективность ИТ. Мы обнаружили, что влияет. Действительно, самый большой вклад в непрерывную доставку в анализе 2017 года (даже больше, чем автоматизация тестирования и развертывания) состоит в том, могут ли команды:

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

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

Эта связь между пропускной способностью связи и архитектурой систем была впервые затронута Мелвином Конвеем, который сказал: «Организации, которые разрабатывают системы… вынуждены производить конструкции, которые являются копиями коммуникационных структур этих организаций» (Конвей, 1968). Наше исследование поддерживает то, что иногда называют «обратным маневром Конвея», который гласит, что организации должны развивать свою команду и организационную структуру для достижения желаемой архитектуры. Цель состоит в том, чтобы ваша архитектура поддерживала способность команд выполнять свою работу — от проектирования до развертывания — без необходимости использования многоканальной связи между командами.

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

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

Слабосвязанная архитектура обеспечивает масштабирование

Если мы достигаем слабосвязанной, хорошо инкапсулированной архитектуры с соответствующей организационной структурой, происходят две важные вещи. Во-первых, мы можем добиться лучшей эффективности доставки, увеличивая как скорость, так и стабильность, одновременно уменьшая выгорание и проблемы развертывания. Во-вторых, мы можем существенно увеличить размер нашей инженерной организации и повысить производительность линейно (или даже больше, чем линейно) по мере того, как мы это делаем.

Чтобы измерить производительность, мы рассчитали следующий показатель из наших данных: количество развертываний в день на одного разработчика. Ортодоксальная точка зрения на масштабирование команд разработчиков ПО гласит, что при добавлении разработчиков в команду может повыситься общая производительность, а производительность отдельных разработчиков фактически снизится из-за «накладных расходов» на коммуникацию и интеграцию. Однако при взгляде на количество развертываний в день на одного разработчика для респондентов, которые осуществляют развертывание хотя бы один раз в день, мы можем увидеть следующие результаты на рис. 5.1.

По мере увеличения числа разработчиков мы обнаружили следующее.

• Участники из группы с низкими показателями эффективности сокращают частоту развертывания кода.
• Участники из группы со средними показателями развертывают код с постоянной частотой.
• Участники из группы с высокими показателями значительно увеличивают частоту развертывания кода.

Фокусируясь на факторах, которые прогнозируют высокую эффективность доставки: созидательной, ориентированной на цели культуре, модульной архитектуре, инженерных практиках, обеспечивающих непрерывную доставку, и эффективном лидерстве, — мы можем масштабировать развертывания на одного разработчика в день пропорционально количеству разработчиков (или больше). Это позволяет нашему бизнесу двигаться быстрее, когда мы берем больше людей, а не замедляться, как это обычно происходит.

Позволить командам выбирать свои собственные инструменты

Во многих организациях инженеры должны использовать инструменты и фреймворки из утвержденного списка. Этот подход обычно служит одной или нескольким из следующих целей:

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

Однако у этого недостатка гибкости есть и обратная сторона: она не позволяет командам выбирать технологии, наиболее подходящие для их конкретных потребностей, и экспериментировать с новыми подходами и парадигмами для решения своих проблем.

Наш анализ показывает, что выбор инструмента является важной частью технической работы. Когда команды могут решить, какие инструменты использовать, это способствует эффективности доставки программного обеспечения и, в свою очередь, организационной эффективности. Это неудивительно. Технические специалисты, которые разрабатывают и доставляют программное обеспечение и управляют сложными инфраструктурами, выбирают инструменты на основе того, что лучше всего подходит для завершения их работы и поддержки пользователей. Аналогичные результаты были получены и в других исследованиях технических специалистов (например, Форсгрен и соавторы, 2016), предполагающих, что преимущества делегирования выбора инструментов командам могут перевесить недостатки.

Тем не менее есть место и для стандартизации, особенно вокруг архитектуры и конфигурации инфраструктуры. Преимущества стандартизированной операционной платформы подробно обсуждаются в работе Хамбла (2017).

Другим примером служит описание Стивом Йегге перехода Amazon на сервис-ориентированную архитектуру (СОА), в котором он отмечает: «Отладка проблем с чужим кодом становится намного сложнее и в принципе невозможна, если нет универсального стандартного способа запуска каждой службы в отладочной "песочнице"» (Йегге, 2011).

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

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

Архитекторы должны фокусироваться на инженерах и результатах, а не на инструментах или технологиях

Дискуссии вокруг архитектуры часто фокусируются на инструментах и технологиях. Следует ли организации использовать микросервисы или бессерверные архитектуры? Должны ли они использовать Kubernetes или Mesos? На каком сервере, языке или платформе непрерывной интеграции они должны быть стандартизированы? Наше исследование показывает, что это не те вопросы, на которых следует фокусироваться.

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