Если бы devops-инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки, то сроки не были бы настолько безможно сорваны (1.5 дня на решение проблемы);
А каким образом тогда предлагаете работать команде DevOps? Дать личный контакт девопса в тг, чтобы его ддосили вопросами в личку в любое время дня и ночи? Моя практика показывает, что есть разработчики и руководители разработки, которые любят поработать вечерами и ночами и если у них есть личный контакт девопса - не стесняясь пишут ему в 23.00 с проблемой невыкатки сервиса в stage. pre-production и тд. У девопсов есть и ифраструктурные задачи внутри отдела, которые не связаны с процессом разработки. Как их выполнять переключаясь на задачу со срочностью "критично" от менеджера, где в описание скриншот ошибки и больше ничего? Потратить свои 20-30 минут времени, чтобы понять о чем вообще речь идет? Почему-то менеджеры и разработчики очень дорожат своим временем, но при этом часто не уважают время девопсов.
Основные задачи - контролировать свободное место на дисках серверов
Весело читать, что Вы считаете (напрашивается вывод о том, что разработка тоже) это главной задачей девопса, раз указали её первой. Возможно, проблема в вашей команде кроется где-то рядом.
Вместо фото аватарки и на созвонах не включают камеру
Соглашусь с комментатором выше, что это личное желание человека, а не проблема девопса, да и как это влияет на рабочие процессы - непонятно.
Крайне рады в целом если созвона не будет или возможности с него уйти
А кто не рад? Только те, у кого работа - ходить на созвоны.
Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps-инженеры невольно начинают считать его бесполезным посредником
Тут не соглашусь, никто не требует таких глубоких знаний от менеджера, но понимать что такое ОС Linux и как работает Интернет я считаю менеджер должен, в противном случае коммуникация по какой-либо проблеме действительно превращается в ад.
Рекомендации в конце статьи отличные, только вот есть проблема, что бОльший процент менеджеров и разработчиков не хочет вникать в инфраструктурные вопросы: на презентации не ходит, либо ходит и не слушает, документацию предоставленную девопсами не читает, вопросы по ней не задает, в тикете в поле "Тип запроса" пишут "Инцидент", а тикет о том, что надо новый сервис развернуть. Понятно, что всё разнится от команды к команде, я сам работал и с менеджерами и разработчиками, которые интересуются, как, что и где работает, читают доку от девопсов, умеют выстраивать общение и взаимодействие - в таких здоровых командах здорово работать, проблемы решаются моментально. Работал и с токсичными командами, где любой пук и чих в приложении - все стрелки на девопсов, бежим жаловаться СТО на девопсов. Так что исходя из Вашей статьи либо Вам не повезло с девопсами, либо девопсам не повезло с Вами ;)
Если бы devops-инженеры не коммуницировали через сервис деск и вызов дежурного через команду в слаке, а потом не требовали детальной постановки, то сроки не были бы настолько безможно сорваны (1.5 дня на решение проблемы);А каким образом тогда предлагаете работать команде DevOps? Дать личный контакт девопса в тг, чтобы его ддосили вопросами в личку в любое время дня и ночи? Моя практика показывает, что есть разработчики и руководители разработки, которые любят поработать вечерами и ночами и если у них есть личный контакт девопса - не стесняясь пишут ему в 23.00 с проблемой невыкатки сервиса в stage. pre-production и тд. У девопсов есть и ифраструктурные задачи внутри отдела, которые не связаны с процессом разработки. Как их выполнять переключаясь на задачу со срочностью "критично" от менеджера, где в описание скриншот ошибки и больше ничего? Потратить свои 20-30 минут времени, чтобы понять о чем вообще речь идет? Почему-то менеджеры и разработчики очень дорожат своим временем, но при этом часто не уважают время девопсов.
Основные задачи - контролировать свободное место на дисках серверовВесело читать, что Вы считаете (напрашивается вывод о том, что разработка тоже) это главной задачей девопса, раз указали её первой. Возможно, проблема в вашей команде кроется где-то рядом.
Вместо фото аватарки и на созвонах не включают камеруСоглашусь с комментатором выше, что это личное желание человека, а не проблема девопса, да и как это влияет на рабочие процессы - непонятно.
Крайне рады в целом если созвона не будет или возможности с него уйтиА кто не рад? Только те, у кого работа - ходить на созвоны.
Если менеджер проекта не отличает виртуализацию от контейнеризации, DevOps-инженеры невольно начинают считать его бесполезным посредникомТут не соглашусь, никто не требует таких глубоких знаний от менеджера, но понимать что такое ОС Linux и как работает Интернет я считаю менеджер должен, в противном случае коммуникация по какой-либо проблеме действительно превращается в ад.
Рекомендации в конце статьи отличные, только вот есть проблема, что бОльший процент менеджеров и разработчиков не хочет вникать в инфраструктурные вопросы: на презентации не ходит, либо ходит и не слушает, документацию предоставленную девопсами не читает, вопросы по ней не задает, в тикете в поле "Тип запроса" пишут "Инцидент", а тикет о том, что надо новый сервис развернуть. Понятно, что всё разнится от команды к команде, я сам работал и с менеджерами и разработчиками, которые интересуются, как, что и где работает, читают доку от девопсов, умеют выстраивать общение и взаимодействие - в таких здоровых командах здорово работать, проблемы решаются моментально. Работал и с токсичными командами, где любой пук и чих в приложении - все стрелки на девопсов, бежим жаловаться СТО на девопсов. Так что исходя из Вашей статьи либо Вам не повезло с девопсами, либо девопсам не повезло с Вами ;)