Если сервис падает по одной причине, то виноват не Девопс, а владелец сервиса (зачастую лид команды, что этот сервис написала). Как раз метология Девопс You Build - You Own. а то что Опс отвечает, за то что написали разработчики - как раз старая метология
ну я бы не сказал, что Девопс не виноват, невиновных не бывает) если Девопс оказался не виноват, значит он умеет выкручиваться. так или иначе, как я понял, его задача установить и устранить причину. если сам не может - поставить задачу ответственным лицам, на которых каждый раз будет ссылаться, если они ничего не сделали и только в этом случае "не виноват". но по умолчанию как раз виноват. у девопсов зп как бы повыше идут, чем у сисадминов, и от них требуется немного большее, соответственно.
так если в 2х словах- то любой нормальный админ девопс- он и в программах разбирается, и писать может и запустить, но... не каждый админ захочет за всё нести ответственность!!
надо подключать стороннюю фирму например по автоматизации и безопасности у которой есть практика прохождения сертификации. и под их чутким руководством или делать или не делать.!У меня на фирме сейчас так.Мне надо выкатить.Есть их стандарт. Все сделал. Деплой упал.Смотрю у них баг. Пишу.Сказали закостылить.И поставили себе в задачи починить конкретно мою проблему.Костыль в последствии убирается.
Работаю как DevOps инженер уже почти 20 лет, просто раньше это немного иначе называлось. на самом деле настоящий DevOps интенсивно работает на новом месте ну максимум 3 месяца, а потом полностью переходит в режим ожидания. На данный момент я числюсь на полный день в двух компаниях, по факту работаю примерно 2-3 часа в неделю и получаю чуть более $10k в месяц ))
ЗЫЖ чувак из ролика не DevOps, он не создает целостные автоматизированные системы сборки, тестирования и публикации приложений, не разрабатывает их, а просто администрирует и отвечает за разрозненный набор инструментов, собственно по этому ему и звонят в 5 утра, а он бежит обслуживать свои костыли ))
Определённо точно - если ты плохой DevOps. А так - с определённой степенью внеурочка и работа в отпуск характерна для профессии, но случаи этого скорее редки.
Если сервис упал, то надо вместе с разрабом (обычно это делается по умолчанию и пишется такой подробный документ, как Стандарты Разработки) договариваемся о том, как логируем, что логируем, куда логируем. Это действительно работа девопса. Также прометей ставится почти всегда и для выяснения того, почему падает, достаточно стандартных статистик. Девопс должен понимать основные параметры. Для более тонкой настройки производительности обычно используется Егерь. И чтобы сервисы падали бесшовно, да, нужно понимать как устроен кубер. Для availability самый простой и надежный способ - это поднимать количество реплик. Он (кубер) сам перераспределит нагрузку, когда какой-либо под упал.
Может мне не в фронтэндера нужно было идти, а в дэвопс? Сейчас учусь на фронта, работаю сисадмином и меня жутко бесят однотипные действия. Практически все автоматизировал баш скриптами и clickerman(на рабочем пк) Когда падал сервер из-за брака жд дисков, стресс был, но как то без хватания за голову все разрулил.
Ну вот я был сисадмином, ушел в девопс. Хотя на меня начали в какой-то понемногу скидывать эти обязанности. С программированием и так был знаком, опыт имелся. А сейчас в компании решили нас называть sre. Ну прикольно, название поменяли, концепт тот же. Хоть пашущей кобылой называйте, главное платите и повышайте зп
боюсь спросить, а что делают руководители софтовых фирм, если девопс занимается внедрением разработок разрабов. Из высоких кабинетов этих руководителей что-то видно в направлении внедрения?
@@---lu8bo которые недалекие devops сами не могут куда-то поставить. Забавно. Конечно это шутка, отлично понимаю значение босса. В том числе уровень посмотри что там за проблема.
@@andreichemeris4141 согласен, т.к. это уже пройденный этап. О чем ни разу не жалею. Вы не правы по незнаю. К сожалению, чтобы не лишиться иллюзий знаю не из кино.
@@sergejchap62 задачи ставит подчиненный или владелец? Даже если все идет от подчинённого, все идеи и решения окончательное слово за БОССОМ который может только до 10 считать
На самом деле DevOps инженер создает систему автоматической сборки, тестирования и публикации приложений. А чувак из ролика, как вы правильно поняли, не создает целостные системы, а просто сисадминит набор разрозненных инструментов и окружений разработки. В этом разница. По факту DevOps, если это действительно инженер, работает буквально первые пару месяцев, внедряет систему, а потом кайфует, но таких мало, в основном кругом сплошные админы ))
Вобще то правильно налаженная работа вообще не оповещает о инцидентах....а ппц приходит только в 1 случае: если разраб что то накосячил и код еше на Деве приказал долго жить!!!!На проде косяк происходит после релиза фичи которая по базе пересчитывает данных 2ТБ по каждому отдельному пользователю или еще что о в этом роде...и тогда RDS начинает лочится, очередь выстраивается и начинается авто разворот дополнительных НОД которые разгребут этот завал!!!!А девопс просто нервно наблюдает за происходящим! И да у ДевОпс фулл админские права вообще ко всему что можно!И Амазон кошмарить и код разрабов на гите подкручивать что б накатилось...полуправ не бывает.
вы какой-то идеальный мир описали. такого не бывает. горит железо, а делать на все HA нецелесообразно. Лицензии истекли. Роскомнадзор залочил aws. и т.д и т.п. Цель уменьшит проблемы. Но глуп тот, кто думает что можнот уменьшить их до 0%
это потому, что он не девопс, а обыкновенный админ. последние лет пять куча админов решила, что если они научились админить миникуб и писать скрипты в ансибл, то стали девопсами или сре инженерами. админ он и есть админ, он не создает целостных систем разработки которые способны функционировать самостоятельно, а просто обслуживает набор разрозненных инструментов, серверов и окружений.
@@PetrOsetr это всё потомушта настоящий devops работает максимум три часа в неделю, а все остальное за него делает созданная и внедрения им система )) такшто иди уроки учи, умник ))
@@uk267i Извини, дядь, я тут занят - работы много: нужно CI подкрутить, интеграцию между системами в разных облаках настроить, ну и ещё по мелочи того, чем настоящие девопсы не занимаются =))
@@PetrOsetr вот именно. у админов миникуба всегда так. отслуживающий персонал. максимум три грамма инженерной мысли и куча костылей в которых никто не разберётся
По моему 30-45 вполне себе норм, жизненный опыт, стрессоустойчивость, умение общаться. реальная оценка происходящего, четкое понимание зачем пришёл и чего хочешь. Тут правда не все компании готовы взять из за молодого коллектива или других каких-то причин. Но если нравится надо действовать, попробовать самостоятельно для погружение в тему, пройти стажировку для большего понимания.
@@w1nt3rh83r так я же и говорю - он и есть сисадмин. он даже сам себя не хочет назваеть девопс инженером, потому как даже не понимает, кто это такой. так вот девопс инженер строит автоматизированные системы беспрерывной разработки и бесперебойной эксплуатации програмного обеспечения. а этот просто админит кучу разрозненных серверов и инструментов. понятно объяснил?
@@uk267i да забей, я тож сисдамин, но тот же кубер, кафку настроить, ансибл вдобавок. Назвали в какой-то момент девопс, стал девопсом, сейчас зовут сре. Эссенция одна, название другое. Чем бы дитя из верхов не тешилось, лишь бы зарплату рисовала все больше
@@w1nt3rh83r ну вот. а я уже 20 лет девопс инженер, построил 23 полностью автоматизированные ситсемы разработки и эксплуатации. последнее время на рынке из-за таких вот как вы админов, которые нихрена не понимают, такой бардак, что даже зарплаты снизились )) раньше мне лекое платили по 10 штук баксова, а теперь приходится на трех работах сразу работать, что бы выйти на нормальный уровень по зп.
@@uk267i ну тут не моя моя вина, сам понимаешь. Просто нагрузку накидывают, учишься, в итоге перетекаешь, дальше более молодое поколение учишь на свое место, а сам порастаешь мхом 3к Бачей при
Я уже почти 20 лет работаю как DevOps. Раньше это называлось построение автоматизированной системы сборки, тестирования и публикации программного обеспечения. Т.е. в задачи девопс инженера входит разработка и создание такой системы. К сожалению сейчас большинство девопсов это админы разрозненных инструментов разработки, а не разработчики целостных систем.
Дядя Вова, а можете поподробнее рассказать как раньше работа шла? Просто сейчас и вправду единственное, что делаем это кубер мониторинг CICD и терраформ ансибл, но все это готовые инструменты в которых нужно разбираться, а не самому что-то новое изобретать Я два года только девопсом кручусь и честно не представляю это по другому
@@gelderdasgeld3244 если коротко, то сейчас стало модно просто переименовывать сисадмина в девопсов, ну или, совершенно ошибочно, полагать, что девопс это такой продвинутый админ который освоил докер ансибл и даже умеет устанавливать и настраивать Дженкинс. Проблема собственно в том, что на самом деле системный администратор, как и любой другой администратор, ничего не создаёт, а просто обслуживает и настраивает, а вот в термине девопс ключевое слово дев - разработка, а именно разработка системы автоматической сборки, тестирования и публикации программного обеспечения. Инструменты в принципе не так и важны, важен системный подход. Многие просто, как заправский админы, накидывают в кучу несвязный набор инструментов, зачастую с дублирующим и даже противоречащим друг другу функционалом и гордо называют себя девопсами, хотя по факту они не разработали ничего от слова совсем, кругом сплошные костыли и ничего без этого админа не едет, стоит ему простудиться и команда разработчиков не сможет выкатить релиз вовремя... В общем и целом главное системный подход. Разрозненный набор инструментов в сумме даёт результат не превышающий производительность самого слабого звена, а вот правильно разработанная система создаёт эффект синергии и ее производительность в десятки раз больше и эффективнее любого из инструментов в отдельности, а особенно сильно она приводит производительность человека. Как то так. Инструменты не так и важны, что бы построить полноценную систему работающую бес сбоев годами достаточно одного единственного git сервера. Например у вас есть гит сервер с кодом, там уже есть встроенный функционал позволяющий создавать и запускать скрипты через гитхуки, сам гит установлен на Линукс сервере, а это значит, что там уже из коробки есть контейнеризация, срабатывает хук, собирает lxc контейнер, проводит тесты и публикует куда надо...
@@gelderdasgeld3244 если ещё короче, то в современных реалиях даже особо не надо въезжать в тонкости работы linux и docker, можно совершенно просто, буквально за пару дней создать контейнер с парой исполняемых скриптов, который будет собирать, тестировать и деплоить любой код ссылку на репозиторий которого вы обьявите в виде переменной при запуске этого контейнера. Это буквально пара скриптов на bash, go или python и один единственный контейнер docker:git
Крутой мужик. Спасибо за интервью!🤚
В it сейчас не хватает таких ребят. С искрой, задорных и простых. Спасибо.
Если сервис падает по одной причине, то виноват не Девопс, а владелец сервиса (зачастую лид команды, что этот сервис написала). Как раз метология Девопс You Build - You Own. а то что Опс отвечает, за то что написали разработчики - как раз старая метология
разраб надеятся на GC . а девопс потом лезет и насильно чистит....со словами 3 год одна и та же проблема,может наконец что о сделаете...
вы на все 100% админ ))
ну я бы не сказал, что Девопс не виноват, невиновных не бывает) если Девопс оказался не виноват, значит он умеет выкручиваться.
так или иначе, как я понял, его задача установить и устранить причину. если сам не может - поставить задачу ответственным лицам, на которых каждый раз будет ссылаться, если они ничего не сделали и только в этом случае "не виноват". но по умолчанию как раз виноват.
у девопсов зп как бы повыше идут, чем у сисадминов, и от них требуется немного большее, соответственно.
так если в 2х словах- то любой нормальный админ девопс- он и в программах разбирается, и писать может и запустить, но... не каждый админ захочет за всё нести ответственность!!
надо подключать стороннюю фирму например по автоматизации и безопасности у которой есть практика прохождения сертификации. и под их чутким руководством или делать или не делать.!У меня на фирме сейчас так.Мне надо выкатить.Есть их стандарт. Все сделал. Деплой упал.Смотрю у них баг. Пишу.Сказали закостылить.И поставили себе в задачи починить конкретно мою проблему.Костыль в последствии убирается.
Создается впечатление, что DevOps не для тех, кто хочет иметь выходные и отпуски. Это так и есть?
если в выходные не выкатывать релизы и не заливать изменения в конфиги в ночь на субботу, то выходные проходят тихо, вне работы.
@@sergo4220 у некоторых нормальная практика выкатывать в пятницу, что б на выходных клиенты не страдали.
Работаю как DevOps инженер уже почти 20 лет, просто раньше это немного иначе называлось. на самом деле настоящий DevOps интенсивно работает на новом месте ну максимум 3 месяца, а потом полностью переходит в режим ожидания. На данный момент я числюсь на полный день в двух компаниях, по факту работаю примерно 2-3 часа в неделю и получаю чуть более $10k в месяц ))
ЗЫЖ чувак из ролика не DevOps, он не создает целостные автоматизированные системы сборки, тестирования и публикации приложений, не разрабатывает их, а просто администрирует и отвечает за разрозненный набор инструментов, собственно по этому ему и звонят в 5 утра, а он бежит обслуживать свои костыли ))
Определённо точно - если ты плохой DevOps.
А так - с определённой степенью внеурочка и работа в отпуск характерна для профессии, но случаи этого скорее редки.
Если сервис упал, то надо вместе с разрабом (обычно это делается по умолчанию и пишется такой подробный документ, как Стандарты Разработки) договариваемся о том, как логируем, что логируем, куда логируем. Это действительно работа девопса. Также прометей ставится почти всегда и для выяснения того, почему падает, достаточно стандартных статистик. Девопс должен понимать основные параметры. Для более тонкой настройки производительности обычно используется Егерь. И чтобы сервисы падали бесшовно, да, нужно понимать как устроен кубер. Для availability самый простой и надежный способ - это поднимать количество реплик. Он (кубер) сам перераспределит нагрузку, когда какой-либо под упал.
Может мне не в фронтэндера нужно было идти, а в дэвопс? Сейчас учусь на фронта, работаю сисадмином и меня жутко бесят однотипные действия. Практически все автоматизировал баш скриптами и clickerman(на рабочем пк)
Когда падал сервер из-за брака жд дисков, стресс был, но как то без хватания за голову все разрулил.
ansible, chef, salt или боже упаси - puppet, не , зачем, наш путь, даешь автоматизацию на clickerman! :D
У девопса тоже однотипные действия))
Круто и позитивно!
смска? в телегу сообщение - скрипт в одну строчку да и заббикс вродь модулем умеет в телегу
Ну вот я был сисадмином, ушел в девопс. Хотя на меня начали в какой-то понемногу скидывать эти обязанности. С программированием и так был знаком, опыт имелся. А сейчас в компании решили нас называть sre. Ну прикольно, название поменяли, концепт тот же. Хоть пашущей кобылой называйте, главное платите и повышайте зп
Как называется книга по DevOps?
лучше смотреть курсы.
зачем в начале роликов показывать бесмысленные отрывки из интервью? очень раздражает
У телевизионщиков научились, типо в следующей серии / в этой программе
чотко! Лайк от СЕООНЛИ
боюсь спросить, а что делают руководители софтовых фирм, если девопс занимается внедрением разработок разрабов. Из высоких кабинетов этих руководителей что-то видно в направлении внедрения?
Они ставят задачи
@@---lu8bo которые недалекие devops сами не могут куда-то поставить. Забавно. Конечно это шутка, отлично понимаю значение босса. В том числе уровень посмотри что там за проблема.
@@sergejchap62 если незнаете, что делает руководителем, это лишь значит что руководителем Вам не стать
@@andreichemeris4141 согласен, т.к. это уже пройденный этап. О чем ни разу не жалею. Вы не правы по незнаю. К сожалению, чтобы не лишиться иллюзий знаю не из кино.
@@sergejchap62 задачи ставит подчиненный или владелец? Даже если все идет от подчинённого, все идеи и решения окончательное слово за БОССОМ который может только до 10 считать
Инженер по развёртыванию и вводу в эксплуатацию программных комплексов, ясно.
Так, чем автоматизирующий сисадмин отличается от девопс-инжинера?))))
На самом деле DevOps инженер создает систему автоматической сборки, тестирования и публикации приложений. А чувак из ролика, как вы правильно поняли, не создает целостные системы, а просто сисадминит набор разрозненных инструментов и окружений разработки. В этом разница. По факту DevOps, если это действительно инженер, работает буквально первые пару месяцев, внедряет систему, а потом кайфует, но таких мало, в основном кругом сплошные админы ))
Всем привет, ищу DevOps-инженера, официальное трудоустройство, крупная страховая компания, белая заработная плата, полный соц.пакет😁
Вобще то правильно налаженная работа вообще не оповещает о инцидентах....а ппц приходит только в 1 случае: если разраб что то накосячил и код еше на Деве приказал долго жить!!!!На проде косяк происходит после релиза фичи которая по базе пересчитывает данных 2ТБ по каждому отдельному пользователю или еще что о в этом роде...и тогда RDS начинает лочится, очередь выстраивается и начинается авто разворот дополнительных НОД которые разгребут этот завал!!!!А девопс просто нервно наблюдает за происходящим! И да у ДевОпс фулл админские права вообще ко всему что можно!И Амазон кошмарить и код разрабов на гите подкручивать что б накатилось...полуправ не бывает.
вы какой-то идеальный мир описали. такого не бывает. горит железо, а делать на все HA нецелесообразно. Лицензии истекли. Роскомнадзор залочил aws. и т.д и т.п. Цель уменьшит проблемы. Но глуп тот, кто думает что можнот уменьшить их до 0%
толковый пацан
старнно что у вас 24/7 работаете вы а не NOC инженер
это потому, что он не девопс, а обыкновенный админ. последние лет пять куча админов решила, что если они научились админить миникуб и писать скрипты в ансибл, то стали девопсами или сре инженерами. админ он и есть админ, он не создает целостных систем разработки которые способны функционировать самостоятельно, а просто обслуживает набор разрозненных инструментов, серверов и окружений.
@@uk267i ёмаё, ты тут под каждым постом поставил себе цель отписаться? )))
@@PetrOsetr это всё потомушта настоящий devops работает максимум три часа в неделю, а все остальное за него делает созданная и внедрения им система )) такшто иди уроки учи, умник ))
@@uk267i Извини, дядь, я тут занят - работы много: нужно CI подкрутить, интеграцию между системами в разных облаках настроить, ну и ещё по мелочи того, чем настоящие девопсы не занимаются =))
@@PetrOsetr вот именно. у админов миникуба всегда так. отслуживающий персонал. максимум три грамма инженерной мысли и куча костылей в которых никто не разберётся
В 32 года есть смысл идти в DevOps?
В 33 пошёл
По моему 30-45 вполне себе норм, жизненный опыт, стрессоустойчивость, умение общаться. реальная оценка происходящего, четкое понимание зачем пришёл и чего хочешь. Тут правда не все компании готовы взять из за молодого коллектива или других каких-то причин.
Но если нравится надо действовать, попробовать самостоятельно для погружение в тему, пройти стажировку для большего понимания.
@@stoksful А по зп можно узнать как там дела обстоят ?) видел вакансии вплоть до 350-400к зп ))
@@dung9004 зп плохие 250 всего но в остальных еще хуже
@@dung9004 договориться можно, вопрос только в стеке и что делать умеешь. Так то если подумать, то это всего лишь 5000 долларов, это немного..
Если у вас есть дежурство и вам звонят в 5 утра, то вы не DevOps, не SRE, а сисадмин. Уж извините за прямоту ))
Да просто он алерты настроил, чтобы сисадмину они не приходили, вот и встает))
@@w1nt3rh83r так я же и говорю - он и есть сисадмин. он даже сам себя не хочет назваеть девопс инженером, потому как даже не понимает, кто это такой. так вот девопс инженер строит автоматизированные системы беспрерывной разработки и бесперебойной эксплуатации програмного обеспечения. а этот просто админит кучу разрозненных серверов и инструментов. понятно объяснил?
@@uk267i да забей, я тож сисдамин, но тот же кубер, кафку настроить, ансибл вдобавок. Назвали в какой-то момент девопс, стал девопсом, сейчас зовут сре. Эссенция одна, название другое. Чем бы дитя из верхов не тешилось, лишь бы зарплату рисовала все больше
@@w1nt3rh83r ну вот. а я уже 20 лет девопс инженер, построил 23 полностью автоматизированные ситсемы разработки и эксплуатации. последнее время на рынке из-за таких вот как вы админов, которые нихрена не понимают, такой бардак, что даже зарплаты снизились )) раньше мне лекое платили по 10 штук баксова, а теперь приходится на трех работах сразу работать, что бы выйти на нормальный уровень по зп.
@@uk267i ну тут не моя моя вина, сам понимаешь. Просто нагрузку накидывают, учишься, в итоге перетекаешь, дальше более молодое поколение учишь на свое место, а сам порастаешь мхом
3к Бачей при
Я уже почти 20 лет работаю как DevOps. Раньше это называлось построение автоматизированной системы сборки, тестирования и публикации программного обеспечения. Т.е. в задачи девопс инженера входит разработка и создание такой системы. К сожалению сейчас большинство девопсов это админы разрозненных инструментов разработки, а не разработчики целостных систем.
Файнали ви фаунд зем - тру девопс инжинир, антил нормал висиэс, тест каверейдж энд мониторинг системс вос евер криейтед. Володимир, куд ю тейк сом ю тайм энд тейк парт ин ауа кодкэмп митинг, плиз? Ин Сениор Пиздабол секшен?
@@SmartAss766 уроки иди учи ))
Дядя Вова, а можете поподробнее рассказать как раньше работа шла?
Просто сейчас и вправду единственное, что делаем это кубер мониторинг CICD и терраформ ансибл, но все это готовые инструменты в которых нужно разбираться, а не самому что-то новое изобретать
Я два года только девопсом кручусь и честно не представляю это по другому
@@gelderdasgeld3244 если коротко, то сейчас стало модно просто переименовывать сисадмина в девопсов, ну или, совершенно ошибочно, полагать, что девопс это такой продвинутый админ который освоил докер ансибл и даже умеет устанавливать и настраивать Дженкинс. Проблема собственно в том, что на самом деле системный администратор, как и любой другой администратор, ничего не создаёт, а просто обслуживает и настраивает, а вот в термине девопс ключевое слово дев - разработка, а именно разработка системы автоматической сборки, тестирования и публикации программного обеспечения. Инструменты в принципе не так и важны, важен системный подход. Многие просто, как заправский админы, накидывают в кучу несвязный набор инструментов, зачастую с дублирующим и даже противоречащим друг другу функционалом и гордо называют себя девопсами, хотя по факту они не разработали ничего от слова совсем, кругом сплошные костыли и ничего без этого админа не едет, стоит ему простудиться и команда разработчиков не сможет выкатить релиз вовремя... В общем и целом главное системный подход. Разрозненный набор инструментов в сумме даёт результат не превышающий производительность самого слабого звена, а вот правильно разработанная система создаёт эффект синергии и ее производительность в десятки раз больше и эффективнее любого из инструментов в отдельности, а особенно сильно она приводит производительность человека. Как то так. Инструменты не так и важны, что бы построить полноценную систему работающую бес сбоев годами достаточно одного единственного git сервера. Например у вас есть гит сервер с кодом, там уже есть встроенный функционал позволяющий создавать и запускать скрипты через гитхуки, сам гит установлен на Линукс сервере, а это значит, что там уже из коробки есть контейнеризация, срабатывает хук, собирает lxc контейнер, проводит тесты и публикует куда надо...
@@gelderdasgeld3244 если ещё короче, то в современных реалиях даже особо не надо въезжать в тонкости работы linux и docker, можно совершенно просто, буквально за пару дней создать контейнер с парой исполняемых скриптов, который будет собирать, тестировать и деплоить любой код ссылку на репозиторий которого вы обьявите в виде переменной при запуске этого контейнера. Это буквально пара скриптов на bash, go или python и один единственный контейнер docker:git
great
Сиёжа Шадрин
в нос не смотрите.