Это действительно так бюрократия нужна с определенного момента, это как процессный скелет компании. Повторюсь, я менеджер и для меня создавать разумную бюрократию, например отгораживая команду планом на 2 недели от неразумного переключения контекста, переработок и тд - основа работы. Однако тут я привел как пример возникающей стены как раз неуместную в моменте бюрократию
Лично мне в целом понятно чем занимаются devops-инженеры, хоть я и не очень силен в технической части
Я наполнил статью кучей иронии и гиперболизации именно чтобы на это обратили внимание наконец. Нет, у меня вообще ник с времен когда была студия (лет 7 назад) и к сожалению не поправить, но поддержка переодически пишет что это должен быть корпоративный блог
Это то чего хочется добиться в целом не ради выкатки с плеча, а ради минимизации инцидентов и возможности быстрой проверки, работает ли оно вообще. Зацепить за минуту 10 пользователей не так страшно, если максимум что случится у них это инвалидация кеша
Отчасти из-за этого меня многие считают токсичным кстати (похоже на кейс поднятый в теме). Если ко мне прийти с задачей, она не попадет в команду сразу, я буду узнавать что за задача, в чем суть, почему это важно, где полное описание в тикете и тд. Если важно для другой команды, почему в целом важно для компании
Нет, я не пишу коллегам голосовые, это лишь фигурацильное выражение, иллюстрирующее что если у нас аврал, то можно и по голосовому работать, тут уже без разницы
Прекрасно понимаю, сам стопаю релизы без ролл бэка и грамотного подхода к миграции. Правда вот сегодня был конфьюз, я настаивал на ближайшем релизе нового микросервиса и не принимал обоснования вида "ну там доделать еще надо", но когда влезли и выяснили что мы токены рефрешим не совсем корректно сейчас, без проблем сдвинули и план выкатки стали еще больше детализировать на все случаи
Печально что у вас был такой опыт, по крайней мере то что я замечаю, стараюсь находиться в позиции чтобы работа делалась благодаря мне, а не вопреки. При этом я не идеален, меня заносит и иногда мы сильно спорим с разработчиками или devops
А как часто вообще команды спрашивают какая им нужна инфра, окружения и тд? Там где я работал обычно это просто устанавливал CTO и точка
Как часто вы работали в таком месте, где был человек-балансировщик на уровне C-lvl?
Но вот за остальных менеджеров не скажу. Как на ваш взгляд можно повысить вот эту долю понимания?
Это действительно так бюрократия нужна с определенного момента, это как процессный скелет компании. Повторюсь, я менеджер и для меня создавать разумную бюрократию, например отгораживая команду планом на 2 недели от неразумного переключения контекста, переработок и тд - основа работы. Однако тут я привел как пример возникающей стены как раз неуместную в моменте бюрократию
Лично мне в целом понятно чем занимаются devops-инженеры, хоть я и не очень силен в технической части
Подскажите пожалуйста, исходя из чего у вас сложилось впечатление что они должны уметь все и все вообще мне что-то должны?
Зато на этот поставил! Странно что нельзя ставить -, +, + , по идее люди иногда могут промахиваться
А что у вас за продукт? Просто на mssql обычно достаточно редко задумываются о переходе
Я наполнил статью кучей иронии и гиперболизации именно чтобы на это обратили внимание наконец. Нет, у меня вообще ник с времен когда была студия (лет 7 назад) и к сожалению не поправить, но поддержка переодически пишет что это должен быть корпоративный блог
Это то чего хочется добиться в целом не ради выкатки с плеча, а ради минимизации инцидентов и возможности быстрой проверки, работает ли оно вообще. Зацепить за минуту 10 пользователей не так страшно, если максимум что случится у них это инвалидация кеша
Отчасти из-за этого меня многие считают токсичным кстати (похоже на кейс поднятый в теме). Если ко мне прийти с задачей, она не попадет в команду сразу, я буду узнавать что за задача, в чем суть, почему это важно, где полное описание в тикете и тд. Если важно для другой команды, почему в целом важно для компании
Нет, я не пишу коллегам голосовые, это лишь фигурацильное выражение, иллюстрирующее что если у нас аврал, то можно и по голосовому работать, тут уже без разницы
Cпасибо за отзыв! Замечу что в статье часто идет обращение к специалистам как к devops-инженерам (хоть и безусловно не везде)
Уххх, сильное напоминание пред-предыдущее место. На текущем у нас вместо бесплатной постгри кокроач, мне нравится
А как быстро масштабироваться в случае он премиса, если действительно смогли дать большой трафик?
Прекрасно понимаю, сам стопаю релизы без ролл бэка и грамотного подхода к миграции. Правда вот сегодня был конфьюз, я настаивал на ближайшем релизе нового микросервиса и не принимал обоснования вида "ну там доделать еще надо", но когда влезли и выяснили что мы токены рефрешим не совсем корректно сейчас, без проблем сдвинули и план выкатки стали еще больше детализировать на все случаи
Печально что у вас был такой опыт, по крайней мере то что я замечаю, стараюсь находиться в позиции чтобы работа делалась благодаря мне, а не вопреки. При этом я не идеален, меня заносит и иногда мы сильно спорим с разработчиками или devops
Тру
Прошу прощения, случайно нажал минус, промахнулся. В данном случае конфиг был у другой команды, но мы совместно катили изменения
Хорошо, как скажете!
Ух, кстати хороший комментарий, эту точку зрения не раскыл. Можно ваш попросить чуть больше накинуть на этот счет?
Безусловно все так!