Руководство по DevOps - [136]

Практически всегда можно автоматизировать создание полных и точных запросов, дополняя тикеты деталями того, что именно нужно исправить. Например, можно автоматически создавать тикет изменений в ServiceNow со ссылкой на требования заказчика в системе JIRA вместе со сборкой манифеста, результатами тестов конвейера развертывания и ссылками на исполняемые скрипты Puppet/Chef.

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

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

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

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

Практический пример

Автоматизированные изменения инфраструктуры как стандартные изменения в компании Salesforce.com (2012 г.)

Компания Salesforce.com была основана в 2000 г., ее целью было сделать управление взаимоотношениями с клиентами легкодоступным и легко поставляемым сервисом. Предложения организации были широко востребованы на рынке, результатом чего стало успешное IPO[172] в 2004 г. К 2007 г. у компании было более 59 000 клиентов, в день ее сервисы обрабатывали сотни миллионов транзакций, а годовой доход достиг 497 миллионов долларов.

Однако в то же самое время их способность к разработке и выпуску новой функциональности упала практически до нуля. В 2006 г. у них было четыре больших релиза, но в 2007-м компания сделала всего лишь один релиз, несмотря на то что к тому времени число ее инженеров увеличилось. В результате число новых компонентов функциональности на команду падало, а периоды между большими релизами увеличивались.

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

На конференции DevOps Enterprise Summit в 2014 г. Дэйв Мангот и Рина Мэтью описали занявшую много лет DevOps-трансформацию компании, начавшуюся в 2009 г. Согласно Манготу и Мэтью, применяя принципы и методики DevOps, в 2013 г. организация сократила среднее время развертывания с шести дней до пяти минут. В результате стало легче масштабировать ресурсы, что позволило их сервисам обрабатывать более миллиарда транзакций в день.

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

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

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

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