Почему DevOps-евангелист, а не DevOps-инженер?

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

Рассмотрим пример. Девелоперу из команды разработчиков требуется помощь с инфраструктурными изменениями в его работе. Обращаясь в инфраструктурную команду за помощью, девелопер не учитывает общую загруженность команды и наличие у нее других «горящих» задач (а они практически всегда «горят»). В текущей ситуации требуется решить одну частную проблему. Но что, если таких разработчиков много и у каждого из них с десяток своих «горящих» проблем? Как быть админам, которые могут быть загружены рутинной работой, которую никто не отменял?

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

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

Так как уйти от отдельной роли и перейти к практике философии на уровне организации? Если в команде разработчиков нашелся человек, который хочет самостоятельно разбираться в инфраструктуре и не тратить время на обращения к админам, а сотрудник инфраструктурной команды намерен понять проблемы девелоперов на более глобальном уровне – это уже начало распространения культуры DevOps в компании. Выстраивая взаимодействие между командами, разбираясь в частых проблемах и их устранении, фиксируя это в определенном документе, доступном всем командам, щедро делясь практиками и инструментами с коллегами, сотрудник становится DevOps-евангелистом. То есть проводником в мир DevOps на уровне компании, а не своей отдельно взятой команды. Будучи DevOps-евангелистом, любой сотрудник, независимо от его роли, может распространять эту философию в своей организации.