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

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

Заключение ко второй части

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

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

Часть III. Технические практики потоков создания ценности

Введение

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

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

• созданию основы нашего конвейера развертывания;

• быстрому и надежному автоматизированному тестированию;

• организации непрерывных интеграции и тестирования;

• обеспечению возможности низкорисковых релизов, их проектирование и автоматизация.

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

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

Глава 9. Создание основы конвейера внедрения

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

Слишком часто мы обнаруживаем, как наши приложения работают в среде, приближенной к производственной, только во время развертывания — когда уже слишком поздно, чтобы устранять проблемы без негативного влияния на клиентов. Наглядный пример широкого спектра проблем, вызванных рассогласованием приложений и сред, — программа Enterprise Data Warehouse. Ее созданием в крупной австралийской телекоммуникационной компании в 2009 г. руководила Эм Кэмпбел-Претти. Она стала генеральным менеджером и бизнес-спонсором этой программы, стоившей 200 миллионов долларов, и одновременно получила ответственность за все стратегические цели, связанные с этой платформой.