Книга: Руководство по DevOps

Разработчики дежурят наравне с сотрудниками эксплуатации

Даже если развертывания кода и релизы проходят гладко, в любой сложной системе всегда будут неожиданные проблемы, например сбои и падения в самое неподходящее время (каждую ночь в 2:00). Если их оставить без исправления, они будут источником постоянных проблем для инженеров в нижней части потока. Особенно если неполадки не видны инженерам в верхней части, ответственным за создание задач с проблемами.

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

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

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

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

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

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

Оглавление книги