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

Рис. 39. Проверка на готовность к запуску и проверка на готовность к смене сопроводителя в компании Google (источник: “SRE@Google: Thousands of DevOps Since 2004”, видео с сайта YouTube, 45:57, выложено пользователем USENIX, 12 января 2012 г., https://www.youtube.com/watch?v=iIuTnhdTzK0)

Лимончелли отмечает: «Согласно идеальному сценарию, команды разработчиков используют чек-лист LRR в качестве руководства, работая над соблюдением его требований параллельно с разработкой своего продукта. Если же им нужна помощь, они консультируются с инженерами SRE».

Кроме того, Лимончелли замечает: «Команды, быстрее всего добивающиеся одобрения проверки HRR, работают с инженерами SRE дольше всего, с начальных этапов проектирования и до запуска сервиса. Самое хорошее то, что получить помощь сотрудника SRE всегда очень просто. Каждый инженер ценит возможность дать совет команде на ранних этапах и, скорее всего, добровольно выделит только для этого несколько часов или дней».

Обычай инженеров SRE помогать командам на первых стадиях проекта — важная культурная норма, постоянно укрепляемая в Google. Лимончелли объясняет: «Помощь разработчикам — долговременная инвестиция, приносящая плоды много месяцев спустя, когда настает время запуска. Эта форма “социально ответственной позиции” и “работы на благо общества” здесь очень ценится. Ее регулярно рассматривают, когда оценивают SRE-инженеров на предмет возможного повышения».

Заключение

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

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

В следующей главе мы исследуем, как телеметрия может помочь основанной на выдвижении гипотез разработке и A/B-тестированию и как проводить эксперименты, помогающие быстрее добиться целей компании и завоевать рынок.

Глава 17. Встройте основанную на гипотезах разработку и A/B-тестирование в свою повседневную работу

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

Еще хуже, если внесение изменений в компонент, который не работает, может быть отодвинуто на задний план разработкой нового функционала в приложении. Неэффективный компонент так никогда и не будет действовать на полную мощность. В общем случае, как отмечает Джез Хамбл, «самый неэффективный способ протестировать бизнес-модель или идею продукта — создать этот продукт и посмотреть, есть ли на него спрос».