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

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

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

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

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

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

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

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

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

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

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

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

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

Джейсон Coкс говорит: «В компании Disney есть системные инженеры, введенные в состав команд подразделений, в частности в отделы разработки, тестирования и даже информационной безопасности. Это полностью изменило динамику. В качестве инженеров эксплуатации мы создаем инструменты и возможности, преобразующие задачи и способы мышления. При традиционном подходе мы просто управляем поездом, сделанным кем-то другим. Однако при современной эксплуатации с помощью закрепленных инженеров мы помогаем его делать, причем не только сам поезд, но даже мосты, по которым он катится».

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