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

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

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

Преобразования DevOps в компании Big Fish Games показывают, как централизованная команда эксплуатации смогла добиться результатов, обычно ассоциирующихся с рыночно ориентированными командами. Мы можем использовать следующие три общие стратегические установки:

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

• включить инженеров эксплуатации в команды разработки сервисов;

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

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

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

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

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

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

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

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