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

Аналогично в большинстве примеров, представленных в этой книге, используется непрерывная доставка: это разработка встроенного программного обеспечения принтеров HP LaserJet, система печати счетов компании CSG, работающая на 20 технологических платформах, включая приложения для мейнфреймов, написанные на языке COBOL, разработки компаний Facebook и Etsy. Эти же шаблоны могут использоваться для разработки программного обеспечения, работающего на мобильных телефонах, наземных станциях управления космическими спутниками и так далее.

Заключение

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

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

Глава 13. Архитектура низкорисковых релизов

Почти все известные примеры применения DevOps, используемые в качестве образцов, были обречены из-за проблем архитектуры. Об этом уже говорилось в историях LinkedIn, Google, eBay, Amazon и Etsy. В каждом случае компании смогли успешно прийти к архитектурам, более соответствующим текущим организационным потребностям.

Это принцип эволюционной архитектуры: Джез Хамбл отмечает, что архитектура «всех успешных продуктов или организаций обязательно развивается в ходе жизненного цикла». До перехода в Google Рэнди Шуп в 2004–2011 гг. работал главным инженером и ведущим архитектором eBay. Он отмечает, что «и eBay, и Google находятся в процессе пятой полной переработки архитектуры ПО сверху донизу».

Он размышляет: «Оглядываясь назад, я понимаю, что некоторые технологии и выбор архитектуры выглядят замечательными, а другие — неперспективными. Весьма вероятно, что каждое решение в свое время наилучшим образом служило целям организации. Если бы мы в 1995 г. попытались осуществить что-то эквивалентное микросервисам, то мы, скорее всего, потерпели бы неудачу, проект разрушился бы под собственной тяжестью и, возможно, вместе со всей компанией и с нами»[104].

Задача в том, чтобы обеспечивать переход с имеющейся у нас архитектуры на необходимую. В случае с eBay, когда компании надо было переделать архитектуру, они сначала делали небольшой экспериментальный проект, чтобы показать, что они понимают проблемы достаточно хорошо, чтобы предпринять необходимые меры. Например, когда команда Рэнди Шупа в 2006 г. планировала переделать некоторые части сайта на полный набор языка Java, она искала область, дающую наибольший эффект в обмен на вложенные деньги, и с этой целью отсортировала страницы сайта по величине дохода, приносимой каждой из них. Она выбрала области с самыми большими доходами, остановив отбор, когда бизнес-отдача от очередных страниц оказалась недостаточно большой, чтобы оправдать затраченные усилия.

То, что команда Шупа сделала в eBay, хрестоматийный пример эволюционного проектирования с использованием метода, называющегося «удушающее приложение» (strangler application): вместо «вырезания» старого сервиса с архитектурой, больше не помогающей достичь наших организационных целей, и замещения его новым кодом мы скрываем существующую функциональность за API, чтобы избежать дальнейших изменений. Вся новая функциональность затем реализуется в новых сервисах, использующих новую желаемую архитектуру и выполняющих при необходимости вызовы старой системы.

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

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