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

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

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

Чтобы самостоятельные команды все же могли воспользоваться опытом организации SRE, Google создал два списка проверок для двух важнейших стадий релиза нового сервиса. Это проверка на готовность к передаче, к смене сопроводителя (Hand-Off Readiness Review, HRR), и проверка на готовность к запуску продукта (Launch Readiness Review, LRR).

Проверка на готовность к запуску должна проводиться перед введением в эксплуатацию любого нового сервиса Google, тогда как проверка на готовность к смене сопроводителя проводится в том случае, когда сервис передается под контроль эксплуатации, обычно через несколько месяцев после запуска. Чек-листы (контрольные списки) процессов LRR и HRR похожи, но проверка на смену управления более строгая, ее стандарты выше, в то время как проверку перед внедрением устраивают сами команды.

Всем командам, проходящим через любую проверку, помогает инженер SRE. В его задачи входит помочь им понять требования и выполнить их. Со временем чек-листы изменялись и дополнялись, и теперь любая команда может извлечь пользу из коллективного опыта всех предыдущих запусков, как успешных, так и не очень. Во время своей презентации «SRE@Google: тысячи DevOps с 2004 г.» Том Лимончелли отметил: «Каждый раз, выпуская новый продукт, мы учимся чему-то новому. Всегда будут те, у кого меньше опыта в организации релизов и запусков. Чек-листы LRR и HRR — хороший способ создать память компании».

Благодаря требованию управлять своими собственными сервисами на стадии эксплуатации разработчики могут понять, каково это — работать в эксплуатации. Списки LRR и HRR не только делают передачу управления более простой и предсказуемой, но также помогают развивать эмпатию между сотрудниками в начале и конце потока создания ценности.

Рис. 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-тестированию и как проводить эксперименты, помогающие быстрее добиться целей компании и завоевать рынок.

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

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

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

Intuit специализируется на создании продуктов для финансового менеджмента и делового администрирования. Цель — упростить жизнь малого бизнеса, покупателей и профессиональных бухгалтеров. В 2012 г. доход компании составлял 4,5 миллиарда долларов, в ней работали около 8500 сотрудников. Ее основными продуктами были QuickBooks, TurboTax, Mint и до недавнего времени Quicken [133].