Ну тут скорее хайп порождает зп, а не наоборот. На самом деле — если компании, которая занимается разработкой, реально удается найти грамотного спеца. Который владеет не только инструментарием, но и хотя бы общий язык может со всеми участниками процесса найти. Не говорю уж о чем-то большем. Там один обычно не вывозит, даже в небольших компаниях. То такая компания получает реальное преимущество над остальными. И деньги там платятся далеко не просто так.
Странное сравнение с андройд-разработчиком. Если брать методологию. То более корректный пример был бы со скрам-мастером. Там правда человек который следит за соответствием интерпритации (скрам) такой методолгии как agile. Но все же. Вы когда-нибудь встречали скрам-инженера? Я нет.
Девопс-евангелист — тоже довольно расплывчатая роль. Но более простая для понимания. Это человек, который работает с разработчиками, продакт-менеджерами и владельцами проекта. В направлении изменения процессов разработки. Построению взаимодействия всех заинтересованных отделов и бизнеса. Выправлениям целей. И прочее-прочее. Если продолжать аналогию со скрам-мастером — это как раз этакий центр обучения методологии. К сожалению только вот нет у него такой классной штуки как манифест в скраме. Есть только довольно расплывчатые 3 пути.
Знаете. Я не хочу обидеть тех кто считает себя devops-инженерами. В том числе потому, что уже года 4-5 как, так или иначе именуюсь этим термином. Но сам себе врать не хочу. Девопс — это не человек. Это больше про процессы. Про построение взаимодействий и т.д.
А когда очередной раз слышишь, что девопс — это инструменты — docker, kuber, ansible, jenkins, gitlab-ci, etc и дополнительно умение работать с облаками. Становится грустно.
Радует только, что разработчики с которыми я работаю чаще понимают, что это не так.
Ну да. Тут непростой вопрос. Методолгия часто довольно рпсплывчатая штука. Есть большой набор книг на эту тему. Есть бережливое производство. Есть "три пути" девопс. Но нет четкости в имплементации. Именно поэтому sre-инженеры есть. Там гугл постарался наделить их недостающими в методологии подходами. Хотя понятие sre рынок сейчас тоже коверкает как только хочет.
А кто-такой девопс-инженер? Чем он занимается? Dev-инфраструктурой и ci, как администратор тестовых сред? Выкаткой в прод, как релиз-инженер? Поддержкой продакшена, как operations-инженер? Думаю можно продолжать. И все это будут другие роли.
Девопс — это методология направленная на ускорение поставки "инкремента" путем сращивания процессов разработки, operations и на самом деле многих других подразделений. Выставления общих целей. Так чем должен заниматься devops-инженер при таком подходе?
Нет людей devops-инженеров. Devops — это методология. И основу ее составляют далеко не инструменты.
Наверное есть devops-евангелисты, но не более. Все остальное — это извращенное недопонимание рынка.
Долгое время главным игроком в сфере безопасного хранения данных оставалась технология RAID.
Эту технологию сейчас кто-то смог обогнать по частоте применения? Интересно было бы прочитать кто. Даже если это произошло в какой-то конкретной сфере.
Очень буду ждать сравнения классических технологий RAID и вашей разработки. Хотя не до конца понимаю зачем свою реализацию противопоставлять самой технологии. Не правильнее ли запатентовать свой кастомный уровень.
Про людей тоже согласен, что странно, но всякое бывает. Но уязвимость все равно опасная. Как вариант, можно заражаться с зараженной виндовой машины уже внутри сети.
Да. Мы используем. У нас настроен мониторинг порядка десятка различных метрик, от поргового значения количества появления критикал сообщений в системе до анализа скорости ответа наших сервисов. Уведомления летят в слак в основном. Критичные дублируются смс-ками. С точки зрения сотни метрик и удобства. Сложный вопрос. Конфиги в нем пишутся на yaml-е так-что вопрос привычки. У нас ansible, поэтому нас устраивает. Просто добавляем на каждую метрику отдельный файлик в репозиторий, а гитлаб-ci прогоняет тесты и выкатывает все на хост с elastalert-ом.
По комьюнити и информации -на самом деле не густо. Плюс некоторые задачи у них решаются очень своеобразно. К примеру, чтобы не уведомлять в выходные, надо писать свое дополнение на питоне. Но все что нам нужно, мы в итоге смогли найти и разобраться.
Есть еще ElastAlert. Написан на питоне. Он бесплатный и довольно простой. Badoo его в итоге себе на пхп зачем-то переписали, но они все время так поступают.
Ну тут скорее хайп порождает зп, а не наоборот. На самом деле — если компании, которая занимается разработкой, реально удается найти грамотного спеца. Который владеет не только инструментарием, но и хотя бы общий язык может со всеми участниками процесса найти. Не говорю уж о чем-то большем. Там один обычно не вывозит, даже в небольших компаниях. То такая компания получает реальное преимущество над остальными. И деньги там платятся далеко не просто так.
Странное сравнение с андройд-разработчиком. Если брать методологию. То более корректный пример был бы со скрам-мастером. Там правда человек который следит за соответствием интерпритации (скрам) такой методолгии как agile. Но все же. Вы когда-нибудь встречали скрам-инженера? Я нет.
Девопс-евангелист — тоже довольно расплывчатая роль. Но более простая для понимания. Это человек, который работает с разработчиками, продакт-менеджерами и владельцами проекта. В направлении изменения процессов разработки. Построению взаимодействия всех заинтересованных отделов и бизнеса. Выправлениям целей. И прочее-прочее. Если продолжать аналогию со скрам-мастером — это как раз этакий центр обучения методологии. К сожалению только вот нет у него такой классной штуки как манифест в скраме. Есть только довольно расплывчатые 3 пути.
Знаете. Я не хочу обидеть тех кто считает себя devops-инженерами. В том числе потому, что уже года 4-5 как, так или иначе именуюсь этим термином. Но сам себе врать не хочу. Девопс — это не человек. Это больше про процессы. Про построение взаимодействий и т.д.
А когда очередной раз слышишь, что девопс — это инструменты — docker, kuber, ansible, jenkins, gitlab-ci, etc и дополнительно умение работать с облаками. Становится грустно.
Радует только, что разработчики с которыми я работаю чаще понимают, что это не так.
Ну да. Тут непростой вопрос. Методолгия часто довольно рпсплывчатая штука. Есть большой набор книг на эту тему. Есть бережливое производство. Есть "три пути" девопс. Но нет четкости в имплементации. Именно поэтому sre-инженеры есть. Там гугл постарался наделить их недостающими в методологии подходами. Хотя понятие sre рынок сейчас тоже коверкает как только хочет.
Да. Однако!
А кто-такой девопс-инженер? Чем он занимается? Dev-инфраструктурой и ci, как администратор тестовых сред? Выкаткой в прод, как релиз-инженер? Поддержкой продакшена, как operations-инженер? Думаю можно продолжать. И все это будут другие роли.
Девопс — это методология направленная на ускорение поставки "инкремента" путем сращивания процессов разработки, operations и на самом деле многих других подразделений. Выставления общих целей. Так чем должен заниматься devops-инженер при таком подходе?
Нет людей devops-инженеров. Devops — это методология. И основу ее составляют далеко не инструменты.
Наверное есть devops-евангелисты, но не более. Все остальное — это извращенное недопонимание рынка.
А какие задачи вы решаете в рамках поддержки инфраструктуры разработки?
Очень буду ждать сравнения классических технологий RAID и вашей разработки. Хотя не до конца понимаю зачем свою реализацию противопоставлять самой технологии. Не правильнее ли запатентовать свой кастомный уровень.
Про людей тоже согласен, что странно, но всякое бывает. Но уязвимость все равно опасная. Как вариант, можно заражаться с зараженной виндовой машины уже внутри сети.
Да. Мы используем. У нас настроен мониторинг порядка десятка различных метрик, от поргового значения количества появления критикал сообщений в системе до анализа скорости ответа наших сервисов. Уведомления летят в слак в основном. Критичные дублируются смс-ками. С точки зрения сотни метрик и удобства. Сложный вопрос. Конфиги в нем пишутся на yaml-е так-что вопрос привычки. У нас ansible, поэтому нас устраивает. Просто добавляем на каждую метрику отдельный файлик в репозиторий, а гитлаб-ci прогоняет тесты и выкатывает все на хост с elastalert-ом.
По комьюнити и информации -на самом деле не густо. Плюс некоторые задачи у них решаются очень своеобразно. К примеру, чтобы не уведомлять в выходные, надо писать свое дополнение на питоне. Но все что нам нужно, мы в итоге смогли найти и разобраться.
Есть еще ElastAlert. Написан на питоне. Он бесплатный и довольно простой. Badoo его в итоге себе на пхп зачем-то переписали, но они все время так поступают.