Здравствуйте, обращаем ваше внимание, что доклад можно обсудить со спикером на официальном канале конференции и задать в чате канала конференции свои вопросы t.me/DevOpsConfTalks
На самом деле интересное предложение, архитектор согласно разрабатываемому приложению и его функциям разрабатывает набор инструментов, девопс приходит на встречу и выражает своё фи или не согласие с использованием инструмента "по какой-то своей причине", архитектор сидит и чешет репу, как ему сделать софт согласно требованиям, которые к нему спустили остальные отделы, а девопс идёт дальше пить смузи. Наверное так и буду делать. =)
Как говорил классик - "Называй меня хоть Сьюзанной, главное плати нормально". Почему так восхваляют девопс - это может быть хороший linux админ с опытом или ямл девелопер. Собеседуем людей, больше половины валятся на вопросах о LA, далее про контейнеры и оркестраторы, начинаешь лезть на уровень ниже, то все - плывем... Куда мы катимся то?
А зачем девопсу лезть на уровень ниже, вот у меня есть мэнэджэд кубер, я деплою туда приложения, кто меня пустит на тот уровень про который вы спрашиваете, я же не инфраструктурный инженер, зачем мне это надо знать?
@@rusik2293 базу надо знать. Например ситуация у вас контейнеры с таймаутами отвечают. В чем проблема? В приложении кривом, в сети кубера, в внешней сети или вообще у вас tcp mem коннекты не освобождает по какой то причине. Вот такие ямл девелоперы Нина,Илья,Харитон, Ульяна,Яков не смогут провести дебаг и имя команды будет по первым буквам коллег...
@@rusik2293 всё чаще бывают случаи когда у тебя не менеджед кубер (тот же гугл/авс повышает цены и не слабо) и их несколько в инфре, под разные проекты. тогда появляються требования понимать что у тебя "внизу", а не только отвечать на собесе - "я пишу пайпланы для деплоя"
@@evgeniyevgeniy1372 Что поделать, раз стал слишком стар. Видео посмотрел, ясно что бывает разный уровень абстракций, но база должна быть у всех. Удачи молодым!
Слов много, в основном про архитектуру и принципы её проектирования. Причём тут ДевОпс??? Все проблемы поднятые в докладе решаются грамотным Архитектором и опытными бэками\фронтами. Такое ощущение что кейсы от какого то стартапа, где каждый имеет 2-3 смежных обязанности. ДевОпсы НЕ должны лезть в архитектуру при наличии грамотного Архитектора в компании. Если Архитектора в компании нет, но она замахивается на критичные приложения со сложной интеграцией - здоровья погибшим! Доклад делал человек который "не очень верит в аналитиков, не очень верит в архитекторов"(с) и пытается их заместить кем то еще.
Вот про таких людей как вы и говорил докладчик: Я буду ансиблой тераформить и не лезьте ко мне =) понятно, что в условном банке так не будет как говорит докладчик.Но, в адекватной компании, где считают деньги, девопс может принимать архитектурные решения.
@@ПавелКозлов-ж7э у нас есть архитектурный комитет, два архтектора которые разрабатывают архитектуру приложений. если (крайне редко) в архитектуре используется устаревший компонент/сервис, то девопсы могут на это указать и предложить изменения, но ни коим образом не лезут с наыязыванием своей концепции. у них достаточно плановой (развертывания согласно проекту и архитектуре) и внеплановой (разработчики накосорезили и сломали себе стенд) работы. у всех в компании есть должностные инструкции, есть обязанности, есть зоны ответственности. или нужно чтобы девопс-инженер внедривший свою архитектуру вместо той что предложил архитектор потом отвечал за ботлнеки в огромном облачном приложении при его масштабировании? хочешь проектировать - иди в архитекторы, расти в архитекторы, кто не даёт? но зачем помимо своих основных обязанностей, которые расписаны на 2 недели вперед, еще и в архитектуру лезть? особенно если там есть кому её делать.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Здравствуйте, обращаем ваше внимание, что доклад можно обсудить со спикером на официальном канале конференции и задать в чате канала конференции свои вопросы t.me/DevOpsConfTalks
На самом деле интересное предложение, архитектор согласно разрабатываемому приложению и его функциям разрабатывает набор инструментов, девопс приходит на встречу и выражает своё фи или не согласие с использованием инструмента "по какой-то своей причине", архитектор сидит и чешет репу, как ему сделать софт согласно требованиям, которые к нему спустили остальные отделы, а девопс идёт дальше пить смузи. Наверное так и буду делать. =)
Как говорил классик - "Называй меня хоть Сьюзанной, главное плати нормально". Почему так восхваляют девопс - это может быть хороший linux админ с опытом или ямл девелопер. Собеседуем людей, больше половины валятся на вопросах о LA, далее про контейнеры и оркестраторы, начинаешь лезть на уровень ниже, то все - плывем... Куда мы катимся то?
А зачем девопсу лезть на уровень ниже, вот у меня есть мэнэджэд кубер, я деплою туда приложения, кто меня пустит на тот уровень про который вы спрашиваете, я же не инфраструктурный инженер, зачем мне это надо знать?
@@rusik2293 базу надо знать. Например ситуация у вас контейнеры с таймаутами отвечают. В чем проблема? В приложении кривом, в сети кубера, в внешней сети или вообще у вас tcp mem коннекты не освобождает по какой то причине. Вот такие ямл девелоперы Нина,Илья,Харитон, Ульяна,Яков не смогут провести дебаг и имя команды будет по первым буквам коллег...
@@rusik2293 всё чаще бывают случаи когда у тебя не менеджед кубер (тот же гугл/авс повышает цены и не слабо) и их несколько в инфре, под разные проекты. тогда появляються требования понимать что у тебя "внизу", а не только отвечать на собесе - "я пишу пайпланы для деплоя"
Вы вообще видео смотрели? Оно не про ваше старпёрство
@@evgeniyevgeniy1372 Что поделать, раз стал слишком стар. Видео посмотрел, ясно что бывает разный уровень абстракций, но база должна быть у всех. Удачи молодым!
Слов много, в основном про архитектуру и принципы её проектирования. Причём тут ДевОпс???
Все проблемы поднятые в докладе решаются грамотным Архитектором и опытными бэками\фронтами.
Такое ощущение что кейсы от какого то стартапа, где каждый имеет 2-3 смежных обязанности.
ДевОпсы НЕ должны лезть в архитектуру при наличии грамотного Архитектора в компании. Если Архитектора в компании нет, но она замахивается на критичные приложения со сложной интеграцией - здоровья погибшим!
Доклад делал человек который "не очень верит в аналитиков, не очень верит в архитекторов"(с) и пытается их заместить кем то еще.
Вот про таких людей как вы и говорил докладчик: Я буду ансиблой тераформить и не лезьте ко мне =)
понятно, что в условном банке так не будет как говорит докладчик.Но, в адекватной компании, где считают деньги, девопс может принимать архитектурные решения.
@@ПавелКозлов-ж7э
у нас есть архитектурный комитет, два архтектора которые разрабатывают архитектуру приложений. если (крайне редко) в архитектуре используется устаревший компонент/сервис, то девопсы могут на это указать и предложить изменения, но ни коим образом не лезут с наыязыванием своей концепции. у них достаточно плановой (развертывания согласно проекту и архитектуре) и внеплановой (разработчики накосорезили и сломали себе стенд) работы. у всех в компании есть должностные инструкции, есть обязанности, есть зоны ответственности.
или нужно чтобы девопс-инженер внедривший свою архитектуру вместо той что предложил архитектор потом отвечал за ботлнеки в огромном облачном приложении при его масштабировании?
хочешь проектировать - иди в архитекторы, расти в архитекторы, кто не даёт? но зачем помимо своих основных обязанностей, которые расписаны на 2 недели вперед, еще и в архитектуру лезть? особенно если там есть кому её делать.
@@ПавелКозлов-ж7э
еще в офисе камеры наблюдения надо повесить, а то некому.
ну и полы в серверной не помыты :)