Если продолжать обсуждать переход от документо-ориентированных (document-centric) процессов управления к программно-задаваемым (software-defined) (предыдущие посты: раз, два, три), легко упустить одно обстоятельство, которое одновременно наиболее ярко покажет совершившуюся революцию (и возможно окажется, что это революция консервативная).

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

Менеджера в общем мало интересует содержание отдельных работ, его интересует выполнение взятых на себя обязательств исполнителями: чтобы разработчики в срок разработали код фичи и передали его тестировщикам, чтобы тестировщики протестировали фичу и передали его для деплоя на продакшн и т.п. Одна из основных задач менеджера — контроль таких обязательств. Если тот, кому передали результаты некоторой работы подписал акт приемки, менеджеру в целом не важно, работает ли фича на самом деле, закрывает ли она потребности клиента, т.к. обязательства прописанные в контракте выполняются. Ошибка на продакшне это всего лишь повод либо добавить в контракт “гарантийный срок на поставляемый результат” (как обязательство устранять дефекты в течение этого срока), либо открыть отдельный контракт на поддержку. И это все совершенно нормально и правильно, т.к. контракт за выполнением которого он следит – это интерфейс через который взаимодействуют организации. Если контракт плохо организован, начнет сбоить само взаимодействие.

Инженера же, напротив, интересует в первую очередь как именно происходит работа. Не соблюденный технологический процесс не приведет к тому результату, который мы ожидаем, в непротестированном коде почти наверняка будут ошибки. При этом, любая инженерная деятельность по своей сути весьма неравномерна — разработчик не может сказать “я написал код к фиче, как ее дальше будут тестировать и деплоить, и будет ли фича в принципе работать мне не важно”. Почти всегда потребуется то или иное его участие и в других фазах. Ошибка найденная при тестировании или на продакшне возвращается к нему, и ее потребуется исправить. Для получения успешной системы в продакшне важно не только выполнение отдельных работ, но и весь технологический процесс, который поставляет результат в продакшн. В нем в отдельных фазах в принципе может не быть людей, а в других фазах могут участвовать одновременно несколько командных ролей, при этом у этих участников нет явно формализованной ответственности за участие в этой фазе. Если тестировщик нашел багу в написанном коде, разработчик садится с ним рядом и они вместе разбираются в чем там проблема, а не перекидывают тикеты друг другу ("-Я протестировал и нашел ошибку. -А я исправил. -А я снова потестировал и снова нашел"). При этом сбой на ранней стадии сквозного технологического процесса с большой вероятностью приведет к проблемам на его поздних стадиях, и поэтому этот процесс нужно проектировать также как и любой объект инженерной деятельности, и настолько же тщательно контролировать его реализацию: лучше всего описать его кодом чтобы получить гарантию что он всегда будет происходить именно так как проектировался.

Такое неоднородное вовлечение в процесс хорошо показано на “Горбатой диаграмме” из RUP:

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

Итак, если рассмотреть особенности этих двух ролевые позиций – менеджера и инженера, то сразу становится ясна причина по которой звучат разные фантастические призывы вокруг DevOps, что мол “devops-инженер должен наладить взаимодействие между разными командами” – если смотреть на вещи как и прежде, с позиции менеджера, вполне закономерно будет казаться именно это. При этом, первый более-менее внятный ответ на вопрос в чем именно будет состоять «налаживание взаимодействия» кажется было дано лишь в подходе Team Topologies, и именно в нем снова начали говорить о «контрактах» между командами, до этого были достаточно пространные (с т.з. менеджера) слова про «коллаборацию» и «работу на общую цель», т.е. опять таки решение инженерное. UPD: скорее следующее будет не так Но раз у нас происходит разворот от менеджмента к инженерии, это налаживание взаимодействия (с т.з. корректировки обязанностей и контроля их выполнения) скорее становится новой задачей как раз таки менеджера (и это уже будет какой-то другой вид менеджера, например, scrum-мастер или менеджер потока). Инженерной же задачей здесь будет организация собственно технологического процесса, и этот технологический процесс будет затрагивать не только собственно конвеер CI/CD, но и фазы архитектурного проектирования и анализа. Как я писал чуть раньше, эту самую инженерную задачу скорее всего будет формулировать руководитель разработки. Devops-инженер же будет реализовывать по этому заданию конкретные компоненты сквозного процесса – подобно тому как разработчики реализуют бизнес-функциональность приложения по спеке/набору user stories от владельца продукта.

И еще один момент. Глядя на это же самое обстоятельство нельзя ставить знак “равно” между ITIL и DevOps. ITIL – дисциплина для менеджеров, даже несмотря на то, что в 4й версии его авторы изо всех сил постарались сделать его инженерным. Глядя же, например, на DevOps-топологии мы явно видим, что все топологии где идет речь о разграничении ответственности (т.е. о менеджерском взгляде на вещи) считаются антипаттерном для DevOps.