Джин Ким - Руководство по DevOps

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

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

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

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

Процесс проверки работы коллегами (peer review) сервиса GitHub — яркий пример того, как критическое рассмотрение может улучшить качество, сделать развертывание более безопасным и стать частью повседневной работы. Специалисты сервиса GitHub стали первопроходцами практики pull request ( запроса на внесение изменений ), одной из самых популярных форм проверки кода коллегами как в разработке, так и в эксплуатации.

Скотт Чейкон, директор по информационным технологиям и один из основателей компании GitHub, писал на своем сайте, что запросы на внесение изменений — механизм, позволяющий инженерам сообщать об изменениях, отправляемых в репозиторий GitHub. Когда запрос отправлен, заинтересованные лица могут оставить отзыв о предлагаемых правках, обсудить потенциальные модификации и даже, если потребуется, предложить расширение кода на основе предлагаемых изменений. Программисты, отправляющие запрос, часто запрашивают «+1», «+2» и так далее в зависимости от того, сколько отзывов нужно.

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

Рис. 40. Комментарии и предложения к запросу внесение изменений, GitHub (источник: Скотт Чикон, “GitHub Flow”, сайт ScottChacon.com, 31 августа 2011 г., http://scottchacon.com/2011/08/31/github-flow.html)

Поток GitHub состоит из пяти этапов.

1. Чтобы начать работать над чем-то новым, инженер создает соответствующую именованную ветку от «master» (например, «new-oauth2-scopes»).

2. Инженер работает только с этой веткой, регулярно отправляя свой код на сервер.

3. Когда ему нужна обратная связь или помощь или когда он считает, что ветка готова к слиянию с master, он отправляет запрос на внесение изменений.

4. Когда инженер получает рецензии и необходимые согласования новой функциональности, он может добавить свои изменения в ветку «master».

5. Когда правки внесены и отправлены в главную ветку, инженер развертывает их в производственную среду.

Эти практики, встраивающие рецензирование и координацию в процесс ежедневной работы, позволили компании GitHub быстро и надежно поставлять на рынок продукты высокого качества и высокой надежности. Например, в 2012 г. сотрудники провели 12 062 развертывания — потрясающее количество. В частности, 23 августа на общекорпоративной конференции придумали и обсудили много новых замечательных идей, и это был самый загруженный день этого года: сотрудники и пользователи провели 563 сборки и 175 успешных развертываний. Все благодаря механизму запросов на внесение изменений.

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

Провал компании Knight Capital — одна из самых показательных ошибок внедрения ПО в недалеком прошлом. Пятнадцатиминутная ошибка развертывания — причем инженеры не могли отключить рабочие сервисы — привела к потере 440 миллионов долларов. Финансовые убытки поставили под удар функционирование организации, в результате чего владельцы были вынуждены быстро продать компанию, чтобы она могла продолжать деятельность без риска для финансовой системы.

Джон Оллспоу замечает, что, когда происходят такие резонансные провалы, как ошибка развертывания Knight Capital, обычно есть две противоречащие фактам интерпретации, почему же эти сбои вообще могли случиться [135].

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