Close

Путь к успешному управлению инцидентами начинается здесь

Просмотр тем

Оправдывает ли принцип «кто разработал, тот и поддерживает» созданный вокруг него ажиотаж?

С момента появления принципа «кто разработал, тот и поддерживает» прошло 13 лет. Оправдался ли его потенциал?

Тринадцать лет назад в одном интервью прозвучал новый призыв относительно развертывания и эксплуатации программного обеспечения, который кардинально изменил ИТ-процессы по всему миру. Сегодня невероятное множество компаний придерживается подхода DevOps, основанного на сотрудничестве, и принципа «кто разработал, тот и поддерживает», идущего вместе с ним. Но актуальна ли эта концепция теперь, более десяти лет спустя? Принесла ли она обещанные преимущества?

«После того как разработчикам были переданы операционные обязанности, качество услуг значительно повысилось как с точки зрения клиента, так и с точки зрения технологии. В традиционной модели вы подходите со своим программным обеспечением к стене, которая отделяет разработку и эксплуатацию, перебрасываете его через стену и забываете о нем. Но не в Amazon. У нас используется принцип «кто разработал, тот и поддерживает». Это вовлекает разработчиков в повседневную эксплуатацию их ПО и взаимодействие с клиентами. Циклы обратной связи от клиентов крайне важны для улучшения качества обслуживания».

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

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

Очевидные преимущества… и очевидные трудности

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

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

Поскольку ответственность за код несет та же команда, этот подход положительно сказался и на предотвращении инцидентов. Согласно отчету, показатель успешности совпадает для компаний, где проверка кода перед развертыванием проводится сторонними командами, и компаний, не проводящих такую проверку. С другой стороны, оценка, выполненная знакомыми с продуктом разработчиками, положительно влияет на предотвращение инцидентов.
Если говорить о проблемах, наша команда сформулировала некоторые из трудностей нового подхода к управлению инцидентами следующим образом: «Проблема [децентрализации управления инцидентами] заключается в том, что организациям все еще требуется централизация. Руководству нужен доступ к отчетам и документации. Заинтересованные стороны в компании хотят получать новости. Они хотят отслеживать показатели инцидентов, такие как среднее время разрешения и среднее время подтверждения. Им нужны четкие сообщения об инцидентах, отчеты о ретроспективном разборе инцидентов, а также планомерная работа по устранению недостатков.

Многие компании, которые успешно переходят к децентрализации [на основе подхода «кто разработал, тот и поддерживает»], преодолевают эту сложность с помощью технологии, создающей условия для децентрализации и независимости команд. Так команды могут быстро разрешать инциденты и в то же время централизованно хранить информацию, чтобы компания оставалась в курсе событий».

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

Итак, оправдался ли принцип «кто разработал, тот и поддерживает»?

По нашему опыту, результат оправдывает преодоленные трудности. Преобразование отрасли, вызванное подходом «кто разработал, тот и поддерживает», по-прежнему продолжается, и даже традиционные ИТ-команды начинают к нему прицениваться.

Подход «кто разработал, тот и поддерживает» пока не породил исследований, однако наша практика показывает, что он часто связан с внедрением принципов DevOps в целом (у нас есть статистика на этот счет). Согласно отчету Forrester, в 2017 году 63 % организаций заявили об успешном внедрении DevOps, еще 27 % планировали внедрение в течение года, и только 1 % не выразил заинтересованности в подобных изменениях.

Для наглядности приведем еще некоторые данные: компании сообщили о повышении уровня удовлетворенности клиентов в среднем на 45 % и увеличении производительности сотрудников на 43 % после внедрения принципов DevOps.

продолжение темы
Problem management vs. incident management