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

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

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

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

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

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

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

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

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

Назначение «контактов с эксплуатацией» в каждую команду разработки сервисов

По ряду причин (например, стоимость персонала и его нехватка) мы можем оказаться не в состоянии включить инженера эксплуатации в каждую продуктовую команду. Однако мы по-прежнему можем получить множество преимуществ, назначая в каждую продуктовую команду «контакт с эксплуатацией».

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

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

• каковы принципы его действия — в том, что касается работоспособности, масштабируемости и наблюдаемости (схематическое отображение настоятельно рекомендуется);

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

• имеются ли какие-либо отступления от ранее использовавшихся архитектур и методик и как они обосновываются;

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

• каковы планы запуска функций в производство.