Текст книги "Ускоряйся! Наука DevOps"

● качество и производительность приложений – как они воспринимаются теми, кто работает над ними;

● процент времени, затраченного на доработку или незапланированную работу;

● процент времени, затраченного на работу с ошибками, выявленными конечными пользователями.

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

Участники с высокими показателями сообщили, что тратят 49 % времени на новую работу и 21 % на незапланированную работу или доработку. Напротив, участники с низкими показателями тратят 38 % своего времени на новую работу и 27 % на незапланированную работу или доработку.

Незапланированная работа и доработка являются полезными индикаторами качества, потому что они представляют собой неспособность встроить качество в наши продукты. В книге The Visible Ops Handbook незапланированная работа описана как разница между тем, как если «обратить внимание на сигнал низкого уровня топлива в автомобиле или остаться без топлива на шоссе» (Бер и соавторы, 2004). В первом случае организация может устранить проблему плановым образом, без особой срочности или нарушения других запланированных работ. Во втором случае они вынуждены решать проблему в очень срочном порядке, часто задействуя все ресурсы, – представьте, что шесть инженеров должны бросить все и бежать по шоссе с полными газовыми баллонами, чтобы заправить застрявший грузовик.

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

ПРАКТИКА НЕПРЕРЫВНОЙ ДОСТАВКИ: ЧТО РАБОТАЕТ, А ЧТО НЕТ

В нашем исследовании мы обнаружили девять ключевых возможностей, которые управляют непрерывной доставкой. Они перечислены ранее в этой главе. Некоторые из этих возможностей имеют интересные нюансы, которые мы обсудим в этом разделе – за исключением архитектуры и выбора инструментов, которые заслуживают отдельной главы (Глава 5). Непрерывная интеграция и автоматизация развертывания не рассматриваются далее в этой главе.

КОНТРОЛЬ ВЕРСИЙ

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

АВТОМАТИЗАЦИЯ ТЕСТИРОВАНИЯ

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

● Наличие надежных автоматических тестов: при их выполнении команды уверены, что их программное обеспечение готово к релизу. Кроме того, они уверены, что провалы тестов указывают на реальную ошибку. Слишком много тестовых наборов являются слоеными и ненадежными, производя ложные положительные и отрицательные результаты, поэтому имеет смысл инвестировать постоянные усилия в один надежный набор. Один из способов добиться этого – поместить ненадежные автоматические тесты в отдельный набор «на карантине», который выполняется независимо[16]16
  Дополнительную информацию смотрите по ссылке https://martinfowler.com/articles/nonDeterminism.html


[Закрыть]. Или, конечно, вы можете просто удалить их. Если они управляются версиями (как и должно быть), вы всегда можете их вернуть.

● Разработчики в основном создают и поддерживают приемочные тесты, и они могут легко воспроизводить и фиксировать их на своих рабочих станциях разработки. Интересно отметить, что наличие автоматических тестов, созданных и поддерживаемых главным образом командой обеспечения качества (QA – quality assurance) или аутсорсинговой стороной, не коррелирует с ИТ-эффективностью. Теория, лежащая в основе этого, заключается в том, что когда разработчики участвуют в создании и поддержании приемочных тестов, возникает два важных следствия. Во-первых, код становится проще тестировать, когда разработчики пишут тесты. Это одна из основных причин, почему разработка на основе тестирования (TDD – test-driven development) является важной практикой: она заставляет разработчиков создавать проекты, которые легче поддаются тестированию. Во-вторых, когда разработчики отвечают за автоматические тесты, они больше заботятся о них и будут вкладывать больше усилий в их поддержание и исправление.

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

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

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

УПРАВЛЕНИЕ ТЕСТОВЫМИ ДАННЫМИ

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

МАГИСТРАЛЬНАЯ РАЗРАБОТКА

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

Даже после обнаружения того, что методы разработки на основе магистрали способствуют повышению эффективности доставки программного обеспечения, некоторые разработчики, которые привыкли к GitHub Flow[17]17
  Описание GitHub Flow смотрите по ссылке: https://guides.github.com/introduction/flow/


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

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

ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ

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

ВНЕДРЕНИЕ НЕПРЕРЫВНОЙ ДОСТАВКИ

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

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

Глава 5
Архитектура

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

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

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

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

ТИПЫ СИСТЕМ И ЭФФЕКТИВНОСТЬ ДОСТАВКИ

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

● гринфилд (greenfield): новые системы, которые еще не были выпущены;

● системы взаимодействия (используются непосредственно конечными пользователями);

● системы записи (используются для хранения критически важной для бизнеса информации, когда жизненно необходимы согласованность и целостность данных);

● пользовательское программное обеспечение, разработанное другой компанией;

● пользовательское программное обеспечение, разработанное внутри компании;

● упакованное, коммерчески готовое программное обеспечение;

● встроенное программное обеспечение, которое работает на заводском аппаратном оборудовании (manufactured hardware device);

● программное обеспечение с компонентом, установленным пользователем (в том числе мобильные приложения);

● программное обеспечение вне мейнфреймов, которое работает на серверах другой компании;

● программное обеспечение вне мейнфреймов, которое работает на внутренних серверах;

● программное обеспечение для мейнфреймов.

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

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

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

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

СФОКУСИРУЙТЕСЬ НА РАЗВЕРТЫВАЕМОСТИ И ТЕСТИРУЕМОСТИ

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

● мы можем выполнить большую часть нашего тестирования, не требуя интегрированной среды[18]18
  Мы определяем интегрированную среду как среду, в которой несколько независимых служб развертываются вместе, как, например, промежуточная среда. На многих предприятиях интегрированные среды являются дорогостоящими и требуют значительного времени на настройку.


[Закрыть];

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

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

● вносить масштабные изменения в разработку своей системы без разрешения кого-либо вне команды;

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

● завершить свою работу без коммуникации и координации с людьми вне своей команды;

● осуществить развертывание и выпуск продукта или услуги по требованию независимо от других сервисов, от которых они зависят;

● провести большую часть тестирования по требованию, не требуя интегрированной среды;

● выполнить развертывание в обычное рабочее время с незначительным временем простоя.

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

Эта связь между пропускной способностью связи и архитектурой систем была впервые затронута Мелвином Конвеем, который сказал: «Организации, которые разрабатывают системы… вынуждены производить конструкции, которые являются копиями коммуникационных структур этих организаций» (Конвей, 1968). Наше исследование поддерживает то, что иногда называют «обратным маневром Конвея»[19]19
  Дополнительную информацию см.: https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver


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

Архитектурные подходы, позволяющие использовать эту стратегию, включают использование ограниченных контекстов и API-интерфейсов как способов разделения больших областей на более мелкие слабосвязанные блоки, а также использование тестовых двойников и виртуализации для изолированного тестирования служб или компонентов. Предполагается, что сервис-ориентированная архитектура обеспечивает эти результаты, как и любая истинная архитектура микросервисов. Однако при реализации таких архитектур важно быть очень строгим в отношении этих результатов. К сожалению, в реальной жизни многие так называемые сервис-ориентированные архитектуры не позволяют тестировать и развертывать службы независимо друг от друга и таким образом не позволяют командам достичь более высокой производительности[20]20
  «Платформа болтовни» Стива Йегге содержит несколько отличных советов по достижению этих целей: http://bit.ly/yegge-platform-rant


[Закрыть].

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

СЛАБОСВЯЗАННАЯ АРХИТЕКТУРА ОБЕСПЕЧИВАЕТ МАСШТАБИРОВАНИЕ

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

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

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

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

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

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

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

ПОЗВОЛИТЬ КОМАНДАМ ВЫБИРАТЬ СВОИ СОБСТВЕННЫЕ ИНСТРУМЕНТЫ

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

● уменьшение сложности среды;

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

● увеличение покупательной способности с поставщиками;

● обеспечение правильного лицензирования на все технологии.

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

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

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

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

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

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

АРХИТЕКТОРЫ ДОЛЖНЫ ФОКУСИРОВАТЬСЯ НА ИНЖЕНЕРАХ И РЕЗУЛЬТАТАХ, А НЕ НА ИНСТРУМЕНТАХ ИЛИ ТЕХНОЛОГИЯХ

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

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