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

Чтобы не допустить этого, сделаем так, чтобы все исполнители в потоке создания ценности делили ответственность по устранению сбоев в эксплуатации. Этого можно добиться, если разработчики, руководители разработки и архитекторы будут участвовать в дежурствах. Именно так в 2009 г. поступил Педро Канауати, директор по организации производства компании Facebook. Все сотрудники получат конкретную и практическую обратную связь по любым принятым решениям в отношении архитектуры или кода.

Благодаря такому подходу инженеры эксплуатации не остаются один на один с проблемами эксплуатации, возникшими из-за плохого кода. Вместо этого все, вне зависимости от положения в потоке создания ценности, помогают друг другу найти подходящий баланс между исправлением проблем на стадии эксплуатации и разработкой новой функциональности. Как заметил Патрик Лайтбоди, SVP [125]по управлению продукцией компании New Relic, «мы обнаружили, что, если будить разработчиков в два часа ночи, дефекты исправляются как никогда быстро».

Побочный эффект такой практики — то, что менеджмент разработки начинает понимать: бизнес-цель достигнута не тогда, когда напротив нового элемента функциональности ставится пометка «сделано». Вместо этого элемент считается выполненным, когда работает в эксплуатации именно так, как задумывалось, без чрезмерного количества оповещений о проблемах или незапланированной работы для девелоперов и отдела эксплуатации [126].

Такая методика подходит и для ориентированных на рынок команд, отвечающих за разработку функциональности и за ввод ее в эксплуатацию, и для команд, ориентированных только на разработку приложения. Как в своей презентации 2014 г. отметил Аруп Чакрабарти, менеджер по эксплуатации в компании PagerDuty, «компании все реже и реже содержат специальные дежурные команды; вместо этого любой сотрудник, притрагивающийся к коду или окружению, должен быть доступен во время сбоя».

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

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

Самая частая реакция разработчиков после такого исследования — смятение. «Ужасно видеть многочисленные способы расстроить наших клиентов». Такие наблюдения почти всегда приводят к значительным открытиям и жгучему желанию улучшить результат для заказчика.

Наша цель — использовать ту же самую методику для понимания, как наша деятельность влияет на внутренних заказчиков. Разработчики должны отслеживать ситуацию со своим кодом на протяжении всего потока ценности, чтобы понимать, как коллеги справляются с результатами их работы при вводе кода в эксплуатацию [127].

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

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

Исследование в контексте часто производит большое впечатление на заказчиков. Описывая свое первое наблюдение за работой пользователя, Жене Ким, соавтор этой книги и основатель компании Tripwire, проработавший в ней 13 лет на должности CTO, отмечает:

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

К несчастью, способа лучше не имелось. Другой клиент рассказал, что установка и настройка нашего продукта заняли у него 1300 шагов. Внезапно я понял, почему работа по сопровождению нашего приложения всегда доставалась новичкам в команде: никто не хотел брать это на себя. Такова одна из причин моего участия в создании методики наблюдения за работой пользователей в моей компании: я хотел искупить вину перед нашими заказчиками.

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

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

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

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