Как я убеждал руководство в ценности сотрудничества и совместной работы

5 января 2012 г.

Автор: John Allspaw

I am currently a co-founder of Adaptive Capacity Labs, LLC. Previously, I was Chief Technology Officer at Etsy

Копаясь в архивах в поисках совсем другой информации, я наткнулся на письмо, которое отправил в конце 2009 года руководству инженерного департамента Yahoo. Это было время, когда я уходил из Flickr в Etsy. Я хотел открыто рассказать всему Yahoo о том, как всё было устроено во Flickr и почему именно так. Я надеялся, что другие подразделения Yahoo смогут поучиться у процессов и культуры нашей команды, над созданием и поддержанием которой мы так усердно работали.

Идея о том, что разработка и эксплуатация могут:

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

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

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

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

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

Вот текст письма, которое я отправил трём уровням руководства выше меня в моей организации в Yahoo:

Тема: Почему Flickr поднялся с 73-го по популярности сервиса Yahoo в 2005 году на 6-е место спустя 5 лет

Ниже мои размышления о некоторых причинах успеха Flickr с точки зрения менеджера по инженерии эксплуатации (Operations Engineering).

Когда я говорю все ниже, я имею в виду все группы и подгруппы внутри подразделения Flickr: Продукт, Поддержка клиентов, Разработка, Сервисная инженерия, Борьба со злоупотреблениями и защита, Дизайн и Управление сообществом.

Вот хотя бы некоторые причины нашего успеха:

• Продуктовая команда включала и уважала мнение всех практически в каждой функции и решении.
• Все владели доступностью сайта, а не только эксплуатация.
• Управление сообществом и служба поддержки были вовлечены рано и часто. Во всё. Если их не было — это воспринималось как серьёзный промах, который нужно было исправить.
• Между разработкой и эксплуатацией не было никакого разрыва, когда дело касалось доступности и производительности. Нет, правда. Они работали в унисон, вовлекая друг друга в свои дела, когда это имело значение, и доверяя друг другу на каждом шагу. Эта культура была взращена, а не дана от рождения.
• Я никогда не рассматривал эксплуатацию Flickr как пожарных, и никогда не считал разработчиков Flickr поджигателями. (Я слышал эту аналогию в других местах Yahoo.) Две команды — это на 100% равноправные партнёры с абсолютной прозрачностью. Если что, у нас была проблема с излишней почтительностью между двумя командами.
• Сайт мог эволюционировать, меняться и расти так быстро, как это было необходимо, при условии, что это было безопасно. Конкретно: развёртывание кода и конфигураций. Когда это было небезопасно, мы замедлялись, и все были в порядке с этим, понимая, что цель — вернуться к режиму настолько-быстро-насколько-нам-нужно. См. выше о том, что все владеют доступностью.
• Разработчики могли видеть результаты своей работы почти мгновенно в продакшене. Институционализированный страх деградации и простоя гарантировал, что изменения были настолько безопасны, насколько это требовалось. Разработчики и инженеры эксплуатации интуитивно понимали, что страховочная сетка у вас такая, какую вы сами для себя построили. Когда изменения небольшие и частые, причины деградации или простоя из-за развёртывания кода исключительно прозрачны для всех вовлечённых. (Перечитайте выше о том, что все владеют доступностью.)
• Мы никогда не развёртывали "рано и часто" потому что это:
  1 было модно,
  2 мы хотели похвастаться,
  3 или потому что думали, что мы лучше других. (Мы делали это, потому что для Flickr это было правильно.)
• Всех информировали о любых запусках, которые несли риски, и мы работали над списками вещей, которые могли пойти не так, и что мы будем делать в случае, если это произойдёт. Иногда мы что-то упускали, и приходилось думать быстро, но такие случаи были редки при запуске новых функций.
• У эксплуатации Flickr всегда было право решать "запускать или не запускать", как и у других групп, которые могли голосовать с учётом своей готовности. Значительная часть моей работы заключалась в том, чтобы работать в направлении "запускать", а не "не запускать". На самом деле, почти вся моя работа.

Примеры: самые скучные (антиклиматические, с операционной точки зрения) запуски

• Flickr Video: Я на самом деле задержал запуск на несколько часов, пока мы не решили проблему с сетью, которая, как я считал, представляла риск для трафика после запуска. Кроме этого, это был просто переключатель в приложении, который перевели из положения "выкл" в "вкл". Код функции уже месяцами находился на продакшен-серверах в бета-версии. См. "тёмный запуск".
• Редизайн главной страницы: Беспрецедентный объём данных об активности подгружался на главную страницу для залогиненных пользователей, на порядок увеличилось количество обращений к бэкенд-базам данных. Почему это было скучно? Потому что мы сделали тёмный запуск за 10 дней до этого. Реальный запуск был просто переключением в положение "вкл".
• Люди на фотографиях (он же "тегирование людей"): Поскольку функция требовала данных, которых у нас на самом деле ещё не было, мы не могли сделать тёмный запуск. Это была функция, которая должна была быть либо включена, либо выключена. Из-за этого архитектор Flickr составил список всех частей функции, которые могли вызвать проблемы с нагрузкой, какова вероятность каждой из них, как отключить эти части функции, какое влияние это может оказать на поддержку клиентов, и какие непредвиденные обстоятельства, вероятно, потребуют вовлечения управления сообществом.

Тёмные запуски

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

Это повышает уверенность всех почти до состояния безразличия, что касается страха проблем с нагрузкой. Я понятия не имею, сколько развёртываний кода было сделано в продакшен в любой день за последние 5 лет (хотя я мог бы легко найти это на графике), потому что по большей части меня это не волнует, потому что эти изменения в продакшене имеют настолько низкий шанс вызвать проблемы. Когда они вызывали проблемы, любой сотрудник Flickr мог найти на веб-странице когда было сделано изменение, кто сделал изменение и точно (построчно) что было изменено.

В случае, когда у нас была уверенность в потреблении ресурсов функции, но не 100% уверенности в функциональности, функция включалась только для сотрудников. Я бы сказал, что около 95% функций, которые мы запустили за эти 5 лет, были включены для сотрудников задолго до того, как они были включены для всего населения Flickr. Когда мы всё ещё не чувствовали 100% уверенности, мы медленно увеличивали процент участников Flickr, которые могли видеть и использовать новую функцию.

Конфигурационные флаги

У нас есть много частей Flickr, которые инкапсулированы как флаги "функций", которые выглядят так просто, как: $cfg[disable_feature_video] = 0; это позволяет сайту быть гораздо более устойчивым к конкретным сбоям. Если у нас есть какая-либо деградация в рамках определённой функции, мы можем просто отключить эту функцию во многих случаях, вместо того чтобы закрывать весь сайт. Эти "флаги" в прошлом приоритизировались в разговорах с продуктовой командой, так что есть простой выбор, если что-то идёт не так и время работы сайта становится противоположно времени работы функции.

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

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

Подробнее на эту тему здесь: http://code.flickr.com/blog/2009/12/02/flipping-out/

Итоги

Эксплуатация Flickr находится в завидном положении, потому что им не нужно убеждать кого-либо в подразделении Flickr в том, что:

1. Эксплуатация имеет право принимать решение "запускать или не запускать" наравне с каждой другой подгруппой.
2. Тратить время, усилия и деньги на обеспечение стабильных запусков функций до их запуска — это правило, а не исключение.
3. Непрерывное развёртывание лучше для доступности сайта.
4. Эксплуатация Flickr должна быть вовлечена как можно раньше на этапе разработки любого проекта.

Эти вещи принимаются как данность. Любой другой путь просто казался бы странным.

Не знаю, помогает ли публикация этого письма кому-то кроме меня самого, но вот так.