Управление инцидентами для высокоскоростных команд
Оправдывает ли принцип «кто разработал, тот и поддерживает» созданный вокруг него ажиотаж?
С момента появления принципа «кто разработал, тот и поддерживает» прошло 13 лет. Оправдался ли его потенциал?
Тринадцать лет назад в одном интервью прозвучал новый призыв относительно развертывания и эксплуатации программного обеспечения, который кардинально изменил ИТ-процессы по всему миру. Сегодня невероятное множество компаний придерживается подхода DevOps, основанного на сотрудничестве, и принципа «кто разработал, тот и поддерживает», идущего вместе с ним. Но актуальна ли эта концепция теперь, более десяти лет спустя? Принесла ли она обещанные преимущества?
История сдвига
Все началось с интервью технического директора Amazon Вернера Вогельса в 2006 году:
«После того как разработчикам были переданы операционные обязанности, качество услуг значительно повысилось как с точки зрения клиента, так и с точки зрения технологии. В традиционной модели вы подходите со своим программным обеспечением к стене, которая отделяет разработку и эксплуатацию, перебрасываете его через стену и забываете о нем. Но не в Amazon. У нас используется принцип «кто разработал, тот и поддерживает». Это вовлекает разработчиков в повседневную эксплуатацию их ПО и взаимодействие с клиентами. Циклы обратной связи от клиентов крайне важны для улучшения качества обслуживания».
Так появился принцип «кто разработал, тот и поддерживает» — новый способ выполнения работы, который прекрасно вписался в ставший позднее популярным подход DevOps, основанный на сотрудничестве. Его главная идея состоит в том, чтобы разрушить стену между разработчиками и командой поддержки.
Идея прижилась — и вполне обоснованно. В решении разрушить стену между разработкой и эксплуатацией было здравое зерно. Почему команда, написавшая код (то есть хорошо знакомая с продуктом), не может примерить на себя роль супергероев при возникновении инцидента? Такая практика не только ускоряет время разрешения инцидентов. Она позволяет разработчикам узнавать о текущих проблемах и впечатлениях клиентов, помогая в результате создавать бесперебойные сервисы.
Очевидные преимущества… и очевидные трудности
Перемены в технологии всегда приносят не только преимущества, но и сложности. Поэтому предприятия с более традиционной структурой усиленно сопротивлялись нововведению.
Среди преимуществ нового подхода можно было назвать снижение нагрузки на ИТ-команды, учет реальных требований рабочей среды при разработке, повышение скорости реагирования и более тщательная проверка кода (в конце концов, если знаешь, что устранять баг посреди ночи придется именно тебе, ты с большей вероятностью проведешь повторную проверку при следующем развертывании). Также сложились условия для появления более квалифицированных и разносторонних разработчиков, которым пришлось осваивать новые навыки и смотреть на бизнес по-новому.
Поскольку ответственность за код несет та же команда, этот подход положительно сказался и на предотвращении инцидентов. Согласно отчету, показатель успешности совпадает для компаний, где проверка кода перед развертыванием проводится сторонними командами, и компаний, не проводящих такую проверку. С другой стороны, оценка, выполненная знакомыми с продуктом разработчиками, положительно влияет на предотвращение инцидентов.
Если говорить о проблемах, наша команда сформулировала некоторые из трудностей нового подхода к управлению инцидентами следующим образом: «Проблема [децентрализации управления инцидентами] заключается в том, что организациям все еще требуется централизация. Руководству нужен доступ к отчетам и документации. Заинтересованные стороны в компании хотят получать новости. Они хотят отслеживать показатели инцидентов, такие как среднее время разрешения и среднее время подтверждения. Им нужны четкие сообщения об инцидентах, отчеты о ретроспективном разборе инцидентов, а также планомерная работа по устранению недостатков.
Многие компании, которые успешно переходят к децентрализации [на основе подхода «кто разработал, тот и поддерживает»], преодолевают эту сложность с помощью технологии, создающей условия для децентрализации и независимости команд. Так команды могут быстро разрешать инциденты и в то же время централизованно хранить информацию, чтобы компания оставалась в курсе событий».
Другая принципиальная сложность заключается в том, что многим компаниям для внедрения подхода «кто разработал, тот и поддерживает» приходится менять структуру команд и внутреннюю культуру. Для этого нужно поддерживать сотрудничество, по-новому смотреть на продукт и создать такую структуру команд, которая позволит им взаимодействовать без препятствий. Внести подобные изменения нелегко. Кроме того, нужный результат требует весьма специфического подхода.
Итак, оправдался ли принцип «кто разработал, тот и поддерживает»?
По нашему опыту, результат оправдывает преодоленные трудности. Преобразование отрасли, вызванное подходом «кто разработал, тот и поддерживает», по-прежнему продолжается, и даже традиционные ИТ-команды начинают к нему прицениваться.
Подход «кто разработал, тот и поддерживает» пока не породил исследований, однако наша практика показывает, что он часто связан с внедрением принципов DevOps в целом (у нас есть статистика на этот счет). Согласно отчету Forrester, в 2017 году 63 % организаций заявили об успешном внедрении DevOps, еще 27 % планировали внедрение в течение года, и только 1 % не выразил заинтересованности в подобных изменениях.
Для наглядности приведем еще некоторые данные: компании сообщили о повышении уровня удовлетворенности клиентов в среднем на 45 % и увеличении производительности сотрудников на 43 % после внедрения принципов DevOps.
Начало работы с принципом «кто разработал, тот и поддерживает»
Внедрение принципа «кто разработал, тот и поддерживает» невозможно без гибкой платформы, удобной для ведения совместной работы. В основе принципа лежит слаженная совместная работа команд по разработке и эксплуатации, а обеспечить такое сотрудничество можно только с помощью подходящих инструментов.
Jira Service Management объединяет команды с помощью интегрированного совместного общения и позволяет им оставаться на связи любым привычным способом — от каналов чата (в Slack или Microsoft Teams) до видеоконференций (с помощью встроенных средств видеосвязи или Zoom). Практически каждый аспект Jira Service Management — от оповещений до правил маршрутизации и не только — можно настроить в соответствии с потребностями каждой команды. Все это позволит привлекать необходимых реагирующих лиц и предоставлять контекст всем сторонам на всех этапах, начиная с первоначального реагирования и заканчивая созданием отчетов по разбору инцидентов и управлением проблемами.
Подробнее о том, как сервис Jira Service Management может раскрыть потенциал вашей команды для совместной работы.
Составление графика дежурств с помощью Opsgenie
С помощью этого руководства вы научитесь настраивать график дежурств, использовать правила переадресации дежурств, настраивать оповещения о начале дежурства, а также изучите другие возможности Opsgenie.
Читать учебное руководствоПлюсы и минусы различных подходов к управлению дежурствами
Дежурные команды быстро развиваются. Узнайте о плюсах и минусах различных подходов к управлению дежурствами.
Читать статью