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

В 2009 г. Джим Стоунхэм занимал должность директора подразделения Yahoo! Communities. В него входили Flickr и Answers. До этого он отвечал за работу Yahoo! Answers. Конкурентами были такие сервисы вопросов и ответов, как Quora, Aardvark и Stack Exchange.

В то время у сервиса Answers было примерно 140 миллионов посетителей в месяц, свыше 20 миллионов активных пользователей, отвечающих на вопросы на более чем 20 языках. Однако рост доходов и числа пользователей прекратился, а показатели активности пользователей сокращались.

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

Стоунхэм продолжает: «Эти эксперименты очень хорошо делали компании Twitter, Facebook и Zynga. Они устраивали эксперименты как минимум дважды в неделю, даже разбирали и анализировали изменения, сделанные до развертывания, чтобы убедиться, что они все еще на правильном пути. Вот он — я, управляющий крупнейшим сайтом вопросов и ответов на всем рынке, желающий внедрить быстрое и многократное тестирование функциональности. Но мы не можем выпускать релизы чаще раза в четыре недели. А другие на этом же рынке получают обратную связь в десять раз быстрее, чем мы».

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

Когда команда Yahoo! Answers смогла перейти на еженедельное развертывание, а затем и на несколько развертываний в неделю, ее способность экспериментировать с функциональными возможностями сильно выросла. Впечатляющие достижения и новый опыт за следующие 12 месяцев регулярных экспериментов увеличили количество посещений на 72 %, активность пользователей возросла втрое, а команда удвоила доход. Чтобы укрепить успех, она сосредоточилась на оптимизации следующих показателей.

• Время до первого ответа. Как быстро появился ответ на вопрос пользователя?

• Время до лучшего ответа. Как быстро сообщество присудило награду за лучший ответ?

• Количество плюсов на один ответ. Сколько плюсов было поставлено за ответ?

• Вопросы/неделя/пользователь. Сколько ответов давали пользователи?

• Уровень повторного поиска. Как часто посетители были вынуждены повторять поиск, чтобы найти нужный ответ? (Чем ниже, тем лучше.)

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

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

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

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