А дело было так - я ловил пескарей пару недель назад я решил начать искать работу.
Обновил резюме во всех местах, честно актуализировав навыки, ожидаемую зарплату - фотографию, правда, оставил старую. Срочности у меня никакой нет, поэтому я занял созерцательную позицию, поджидая, когда рекрутёры начнут пинговать все доступные контакты. И они очень быстро начали, хоть и не так, как я ожидал.
Заголовок статьи не оставляет простора для интриги, в нём, в общем-то, максимально сжато выражена суть нижеследующего повествования - но я всё-таки рискну отнять пару минут вашего времени, расписав более подробно мои соображения на эту тему.
Как легко догадаться, мою почту и мессенджеры сразу же заполонили предложения вида "Наймём девопса", "Нужен девопс-инженер/специалист/менеджер". Надо сказать, что с эйчарами я всегда предельно вежлив, корректен и всегда сразу задаю наводящие вопросы в попытках понять, подходит ли мне вакансия - чтобы не тратить ничьё время. Но, к сожалению, в данном случае это стремление оказалось нереализованным.
Немного бэкграунда для простоты понимания моей точки зрения. Я - мужчина в полном расцвете сил, 34 года, из которых двенадцать последних лет я админю.
Не буду в сотый раз повторять давно надоевшую всем мантру "девопс - это методология, бла-бла-бла...". Умом-то я, разумеется, понимал всех обратившихся ко мне в личку людей, автоматически трансформируя фразу "нужен девопс" в "процессы в нашей команде предполагают тесное взаимодействие между отделами, и сейчас мы ищем человека, который взял бы на себя часть работы по эксплуатации". Сердце при этом, конечно, обливалось кровью, но раз человечество пережило "ксерокс = копир", "имеет место быть" и "доброе время суток", то и это переживёт. Ну, то есть я так думал. Что проблема исключительно в неточности наименования, а не онтологическая. Ах, если бы...
В целом, моё политическое кредо в отношении IT-индустрии можно выразить вполне нехитро - "Каждый должен заниматься своим делом". Я повидал некоторое количество довольно экзотично выглядящих, если представить их в виде схемы, иерархических структур организаций - но, распутав этот лист Мёбиуса и отбросив лишнее, обычно удавалось найти традиционных трёх китов: разработку, тестирование и эксплуатацию. Бывают компании, где взаимодействие идёт со скрипом - задачи в джире пинаются туда-сюда между отделами, народ залезает в смежные области неохотно. А бывает и наоборот - и именно это, на мой взгляд, то, что можно назвать девопсом. Наверняка все помнят известную картинку:
Так вот, сейчас я столкнулся с феноменом, заключающимся в том, что круг, относящийся к эксплуатации, почему-то хотят взять - и выкинуть. В разговорах с рекрутёрами это выглядит как заявление о том, что "сисадмины им не нужны, нужны девопсы". Попытавшись уточнить, в чём они видят разницу между этими двумя понятиями, я получил следующие собирательные образы:
Классический (жест пальцами, обозначающий кавычки) сисадмин - это красноглазый бородач в свитере, среднего возраста, довольно тяжёлый на подъём, большую часть рабочего времени сидящий в серверной в обнимку со своим жужжащим хозяйством. Тикеты он обрабатывает вяло, к нововведениям относится скептически - потому что когда-то давно "всё настроил, и оно работает".
Девопс-инженер же, напротив - это молодой и перспективный специалист с горящим взглядом, всегда опрятный и вежливый, который носится как электровеник, постоянно пуша какие-то новые технологии и фишечки. У него всё в облаках, само обновляется, масштабируется и никогда надолго не падает, восстанавливаясь тоже само.
Вы можете подумать, что эти "портреты" чересчур гротескны - и будете правы, но лишь отчасти. У определённого круга рекрутёров, по моим наблюдениям, сложилась именно такая дихотомия - "ленивый ретроград-админ" vs. "всегда готовый на всё молодец-девопс".
Заявляют, что мир изменился - и теперь всё настолько ускорилось, пришло столько новых технологий, что традиционному (жест пальцами, обозначающий кавычки) сисадмину ловить нечего. А между тем - замшелый чувак, пытающийся отгородиться от всего мира лозунгом "работает - не трогай", это не просто админ - это (назовём уж вещи своими именами) хреновый админ. Нормальный админ, не говоря уж о хорошем - он же, имхо, по умолчанию должен быть на самом острие прогресса, в курсе всех 0-day уязвимостей, чейнджлогов и всего новья, способного пригодиться в работе. А сейчас нас поголовно пытаются представить как людей, когда-то давно добравшихся до фронтира - и пустивших там корни, забив на дальнейшее развитие.
Когда я только начинал, всё было на голом железе - незамысловато, негибко, но надёжно. Потом пришла виртуализация, контейнеры ОС, контейнеры приложений с докером во главе, облака, бессерверные вычисления... да что я вам рассказываю?
И на каждом этапе находились те, кто плевался.
Довольно часто это были совсем не админы - и разработчики ныли "зачем нам эти виртуалки, я привык, что всё в одной SSH-консоли", и тестировщики били себя пятками в груди, вопрошая "как мне смотреть логи этих ваших контейнеров, верните, как было - в файлике". Разумеется, плевались и админы - у меня наберётся достаточно примеров, чтобы на 146% подтвердить существование покрытых мхом админов-ретроградов. Многие и сейчас плюются, остроумно вставляя комментарии про "модные технологии" и "хипстер-дривен девелопмент". Чего скрывать - нельзя сказать, что я и сам без греха. Но одно дело - с разумной сдержанностью внедрять ещё совсем молодые технологии, а совсем другое - зацементироваться до состояния каменного голема.
Возвращаясь к моей заочной дискуссии с эйчарами (а точнее, с теми, кто с помощью них набирает персонал) - поначалу, как я уже говорил, я находился в полной уверенности, что хоть ищут и девопсов, но по факту - ищут админов. Оказалось, что нет - всё намного хуже. Ищут именно что девопсов, причём сферических.
Люди с нормальным админским бэкграудом не подходят, рекрутёрам подавай другого. Одни пишут максимально прямо, цитирую - "нам нужен немного разработчик, немного тестировщик, немного админ, немного саппорт". Вторые - "у нас уже есть девопс-мидл, но он не справляется с дебагом приложения". Третьи просто называют девопсом офисного админа, к разработке отношения не имеющего.
Честно, я не понимаю, кто эти мифические люди - умеющие всё на свете, даже в мало пересекающихся областях. Ведь что ни говори, разница между IT-специальностями не только в должностных обязанностях, но и в соответствующем складе ума, по факту диктующем, от чего вас будет переть - написания ли кода, нахождения багов и уязвимостей или от настройки каких-нибудь фаерволлов или поднятия кластеров.
Самый, наверное, яркий и простой пример - насколько не каждый специалист в IT-сфере способен трансформироваться в менеджера, несмотря ни на какие свои достижения. Лично я вот попробовал и понял, что как только организационные вопросы с конфколлами начинают занимать большую часть рабочего времени, тесня непосредственное решение вопросов и созидательную деятельность руками - я начинаю стрессовать и чувствовать себя некомфортно. Менторю вот без проблем, какие-то задачи архитектурно-прикладного плана тоже. Именно поэтому максимум, на который я претендую - это "играющий тренер" без отрыва от земли.
Как вообще можно сочетать в себе жнеца, швеца и далее по списку - я представляю плохо.
Нельзя не отметить, что за последние годы я неоднократно видел таких вот "девопсов, возникших из ниоткуда" - без фундаментальных знаний, но зато отлично разбирающихся в админках GCP/AWS/etc, лихо взгромождающих целые конгломерации с помощью конфигов Терраформа, мановением руки организующих красивые дашбоарды в Графане на потеху начальству... но плавающих в самых элементарных вопросах.
Один не привык диагностировать неисправности и всё решает методом рестарта контейнеров. Второй что-то слышал про TCP, но предложение снять дамп трафика и разобраться приводит его в ужас. Третий борется с проблемами производительности с помощью увеличения количества ядер и памяти, выданных виртуалке. Четвёртый залипает на неделю после предложения добавить JMX-мониторинг приложения и возвращается с идеей добавить парочку зависимостей в код, чтобы его модная система мониторинга "всё сделала сама". Пятый - не умеет интерпретировать LA и утилизацию процессора. Шестой - разворачивает СУБД на проде без какой-либо настройки. И так далее, и так далее - тысячи их.
Особенно гротескные формы можно встретить в случаях, когда сферический девопс сливается в экстазе с менеджером, работающим под лозунгом "всё в облака!". Нужны ли облака в данном случае, оптимальны ли они по затратам (обычно нет), получится ли вообще использовать их сильные стороны (обычно тоже нет) - никого не волнует. А сферический девопс и рад, это же его родная стихия.
И получается, что одна половина индустрии считает админов недодевопсами, вторая - девопсов недоадминами.
Посреди всего этого великолепия сижу я, разгребаю чужие косяки - а при попытке найти работу встречаю заявления, что "админы не нужны". Не надо так.
Комментарии (182)
E32_735i
20.01.2022 11:10+30Ща будет бамболейла, но девопс- админ и саппорт для обленившихся кодеров :))00
MentalBlood
20.01.2022 12:33+7Ну а что, так и есть
для обленившихся кодеров
Которые хотят только непосредственно кодить
Vulturem
20.01.2022 15:58+8Которые хотят только непосредственно кодить
на что их собственно и нанимают
crims0n_ru
20.01.2022 20:47+3Так и админ как бы не должен заниматься поддержкой, он должен админить.
Ndochp
21.01.2022 08:34+2Ну так как бы настрой, чтобы работало всегда и не занимайся поддержкой ;)
Кодеры тоже дебажить не хотят.
avegad
20.01.2022 15:28+5Вспомнилась пара цитат из рабочих совещаний:
Девопс - нянька для разработчика.
Программист и разработчик, это две больше разницы.
GrigoryPerepechko
20.01.2022 19:43+2А можно пару тезисов про различие программиста и разработчика?
MentalBlood
20.01.2022 23:06+1Программист программирует, а разработчик разрабатывает
avegad
21.01.2022 08:58-1Правильно.
Программист - программирует, т.е. от алгоритма на салфетке(в голове), до того, что в конце-концов получится, и как минимум , имеет представление, как и где(и сколько), оно будет работать. Разработчик - разрабатывает, как шахтёр в забое, отсюда и до вечера, не заморачиваясь архитектурой, железом, ОС, и тем, как, где(и сколько), оно будет работать.
Наверное, грубо, это даже можно выразить ещё и так: Программист может сам себе сделать ТЗ, руководствуясь знаниями и опытом, на основании бизнес-требований, а разработчик - нет, он работает по готовому ТЗ, которое ему сделал программист, который имеет представление, как, где и сколько, продукт будет работать, "отсюда и до вечера".
И ещё "грубее": Программист большу часть времени думает, а разработчик - кодит.
Вот такое моё ИМХО.
artoym
21.01.2022 09:42+26Интересно как остальные, но я понимаю эти два термина ровно наоборот. Программист - программирует, то есть пишет программу. Разработчик - разрабатывает ПО, то есть занимается и архитектурой, и программированием и всем остальным.
F0iL
21.01.2022 13:34Вы совершенно правильно понимаете, всё так.
Я кстати выше скидывал ссылку на очень хорошую статью с разбором этой темы, и там терминология тоже в точности такая.
Source
21.01.2022 13:50Фигня это всё. Есть понятие кодер для людей, которые по сути переносят алгоритм с "бумаги" в код. А программист и разработчик - это абсолютные синонимы.
F0iL
21.01.2022 14:47Как видно по комментариям, для вас это "фигня", а для многих других это совсем не синонимы :)
Есть кстати очень интересное мнение, что такое разделение на "кодеров" и "программистов" в плане "первые только переносят готовый алгоритм с бумаги в код" давно уже устарело и размылось, потому что так давно уже никто вообще не делает:
Правда, концепция «один придумывает алгоритмы, а другой их кодит» немного поменялась — с одной стороны стало легче, потому как в 90% задач в наше время важнее не изобретение нового алгоритма или структуры хранения данных, а грамотный выбор и оптимальное использование существующих концепций, либо их модификация под конкретные случаи. Но и без «создания алгоритмов» работать нельзя в принципе, т.к. уже никто не формулирует задания вида «аллоцируй массив, сделай цикл для прохода поэлементно, и т.д.» (такое только в школе на уроках информатики встречается), сейчас разработчик оперируя информацией о том «что есть и что должно получится» разрабатывает последовательность действий. По сути дела, даже элементарный SQL-запрос — это уже алгоритм.
Именно поэтому можно сказать, что разделение на «кодеров» и «программистов» устарело лет 20 так назад, сейчас эти понятия размылись и разделение не имеет смысла.
и поэтому разделять эти группы стоит по совсем другим критериям:
Того, кто просто придумал алгоритм и пишет по нему код, достаточно корректно будет считать "кодером", а вот того, кто занимается не только придумыванием алгоритма и кодированием, а еще написанием тестов, документации, проработкой архитектуры и API, заботится о читаемости и надежности кода, и принимает участие во многих других процессах, можно считать "программистом".
Там в статье вообще много интересных размышлений на эту тему.
Мне, честно говоря, наплевать - работать надо, а не выяснять на кого какой ярлык наклеить. Споры кто труъ, а кто не труъ, лучше оставить для средней школы.
Source
22.01.2022 01:02Приведённые цитаты показывают, что автор той статьи слишком узко мыслит. Слышит "алгоритм" - думает "аллоцируй массив". Это даже читать смешно, не то что обсуждать. Алгоритм вполне может реализовывать бизнес-логику (которую естественно не он придумал), используя паттерны и базовые классы, существующие в проекте. По сути, кодеры - это обычные джуны, ну или как вы их называете Junior Developer'ы xD
tlittle
21.01.2022 20:09-1Разрабо́тчик — специалист, занимающийся разработкой схем, механизмов, аппаратуры, программного обеспечения, сайтов и способный реализовать любой проект от стадии замысла до её реализации техническими средствами.
Как там у программиста с разработкой схем, механизмов, аппаратуры? Вообще, это действительно важное различие. Программист (классический программист) уточнил входные параметры и написал программу (на нужном языке программирования), которая выдала ожидаемый результат. Разработчик сделал так, чтобы нужный процесс заработал так, как указано в ТЗ. Добавить конвертацию входных/выходных параметров в нужный формат, задачи по запуску нужных процессов итд, итп.
gecube
21.01.2022 20:11+2Как там у программиста с разработкой схем, механизмов, аппаратуры?
Запятая в указанном Вами определении эквивалентна "ИЛИ". Если человек может полностью разработать программную систему, не вдаваясь в железную часть - он перестаёт быть разработчиком? Вряд ли
tlittle
21.01.2022 20:24Тут гораздо важнее вторая часть фразы. "способный рализовать любой проект". Проблема в том, что очень редко в проекте требуется получить на вход простой X и выдать простой Y в одном и том же виде (в виде простой функции). Чаще приходится скрещивать ежа с ужом, добавлять различные инструменты/прослойки/прокладки. Классический программист заявляет: ребята, я под это не подписывается, моя среда не предусматривает такого (я встречал таких). Разработчик решает эти трудности тем или иным способом.
gecube
21.01.2022 20:31+1Любой проект - это оксюморон, сферический конь в вакууме. Это необходимость произвольного количества ресурсов и произвольного (=бесконечного) количества времени на реализацию проекта. К тому же, многие проекты не могут быть реализованы в одиночку. По крайней мере на практике. Слабо спроектировать ракету Ангара? Т.е., наверное, потенциально Вы можете (не сомневаюсь) это сделать, но потребуется, как я уже сказал бесконечное количество времени / ресурсов.
Если же зайти с другой стороны - посмотреть на реализованные проекты, то надо понимать, что многие проекты могли быть закрыты, потому что стали не нужны бизнесу (видел такое). Или оказались слишком дорогими. Или ещё что-то. Короче, такая трактовка определения оставляет слишком много свободы.
Классический программист заявляет: ребята, я под это не подписывается, моя среда не предусматривает такого (я встречал таких).
классический разработчик говорит "у меня на моей машине все работает"
Классический админ говорит "программа не работает, потому что разрабы наговнокодили, я разбираться не буду"
И так далее
tlittle
21.01.2022 21:14Как раз нет. Любой проект - это не сферический конь в вакууме (у вас, кстати, проблема - вы считаете оксюморон и "сферического коня в вакууме" одним и тем же, хотя это очень разные понятия). Проект - это как раз запуск нужного программного кода в нужном окружении, с нужными условиями итп.
"У меня на моей машине все работает" - это не разработчик, это программист. Разработчик как раз и нужен для того, чтобы решить проблему в том числе разного окружения.
Касательно классического админа - да. Он часто ссылается на разрабов. Уход, в том числе, от этих ссылок делает его девопсом...
Source
22.01.2022 01:13Проект - это как раз запуск нужного программного кода в нужном окружении, с нужными условиями итп.
Ух-ты, т.е. чел, умеющий скачать Chrome под свою ОС и запустить его, уже разработчик? Ясно-понятно)
Вам пытаются донести мысль, что для реализации любого проекта одного человека мало. Условно говоря, вот вы ведь разработчик?
Реализуйте, плиз, за выходные проект, который позволит любые игры под Windows запускать на GNU/Linux и на MacOS X, а то ребята из Wine не справляются. Столько человек столько лет что-то пишут, а никак не могут реализовать. Эх, видимо, ни одного разработчика среди них просто нет.
Reposlav
21.01.2022 15:39+1По мне так это все словоблудие. Разработчик просто более широкое понятие, так как разрабатывать можно не только ПО, но и, например, месторождения полезных ископаемых или прототип автомобиля. Но в IT-среде разработчик и программист - тождественные понятия
gecube
21.01.2022 15:43+1Вы ещё скажите что mining бывает разный. Битка или месторождений. Только что это меняет ?
sky-walker
20.01.2022 20:09+2Девопс — это козел отпущения, который будет делать в команде всю «мусорную» и неприятную работу, которую программисты решили свалить на кого-нибудь :)))
p.s. шутка, конечно, но как говорится, в каждой шутке не только шуткаavegad
21.01.2022 09:18+1Нет шутка, вот в чём и дело. 6 лет назад с таким столкнулся, когда ещё админов, девопсами не называли поголовно. И на запросы к базе вида: select ALL from ALL union ALL, насмотрелся предостаточно. Приходилось даже пальцем тыкать, вплоть до строчки кода, где разработчики накосячили.
rstepanov
21.01.2022 12:19+2Ща будет бамболейла, но девопс- админ и саппорт для обленившихся кодеров :))00
Представьте ситуацию, когда ваш продукт состоит из двух десятков модулей, а список джобов в дженкинсе приближается к сотне, меняясь при этом почти каждый день. И чтобы протестировать какую-то разрабатываемую фичу - надо сначала развернуть стенд из как минимум половины этих модулей в амазоне в кастомной конфигурации. Сможет разработчик этой фичи сам правильно все подергать в дженкинсе, чтобы среда развернулась и накатились все тестовые данные? Как показывает практика - как минимум не с первого раза. Да еще и нужен человек, понимающий почему конкретно этот джоб в дженкинсе сломался и как его чинить. И в плане работ по проекту починка дженкинса почему то отсутствует, менеджер для разработчика эту задачу указать забыл...
Chelyuk
21.01.2022 13:59+2Тут всё несколько глубже. DevOps - человек, растёт из того же места, что и модное заблуждене под названием SCRUM. В котором из ролей всего ничего Product Owner, Scrum Master и Scrum Team. И все равно, что в этот Scrum Team нужны: разработчики, тестировщики, бизнес-аналитики, дизайнер ...
К чему это я всё? А к тому что это классная абстракция-прослойка удобная для рубахи парня - менеджера. Недавно вычитал на просторах, как бедным менеджерам без технического образования и бэкграунда тяжело живётся разбираясь между всеми этими разношёрстными трудягами из-за кого не попадают сроки или упал прод. И мол вот она серебрянная пуля - а мы скажем, что нет между ними разницы и помогут нам тут SCRUM и DevOps. И сразу жизнь у менеджера стала сладкая, сразу понятно у кого перфоманс просел. И руководить сразу проще стало, а что SCRUM ведь про self-organized team. Так и появились мифы о Universal Soldier(aka Cross-functional Team) и DevOps - человек.
Лучшая ложь - это та, в которой есть примерно 15% правды.
gecube
21.01.2022 14:05+2. Так и появились мифы о Universal Soldier(aka Cross-functional Team)
это не миф. Кросс-функциональная команда - это попросту команда, которая укомплектована всеми ролями. Не обязательно универсальными солдатами. Т.е. какая-то специализация при любом раскладе будет. Но при этом команда полностью готова к разработке и поддержке своего продукта.
vya
22.01.2022 10:40А зачем менеджер самоорганизующейся команде? Там уже есть своё управление по идее.
inkvizitor68sl
21.01.2022 14:29Более того, в нормальных компаниях админ всегда и был саппортом для разработчиков. Чего бомбить-то, работа такая - кому-то всегда саппортишь, сам по себе ты особо не нужен.
lastbit
20.01.2022 11:10+28Подпишусь под каждым словом автора. Особенно после того, как стал участвовать в собеседованиях со стороны нанимателя. Но как известно, фарш невозможно провернуть назад поэтому ситуация с неймингом профессии уже не изменится. Есть один несомненный плюс происходящего: "бывшие админы" стали получать внезапно настолько нормальные зарплаты, что некоторые разрабы стали переходить в девопсы. Мне кажется нужно спокойно делать свое дело и смириться с тем, что в целом в бизнесе хватает и более токсичной идиотии, чем ситуация с DevOps. HR как не понимали ни черта так и не будут понимать в большинстве своем. В ИТ как ломились все подряд, так и будут ломиться еще больше. Владельцы бизнесов как велись на маркетинговый буллшит про облака и что угодно еще, так и продолжат вестись на него. Значение имеет лишь несколько "простых" вещей: циферка на счете и возможность разрулить ситуации в той компании, где ты сейчас работаешь (в том числе повлиять на процесс найма и организации работы инженеров). А про то, чтобы повлиять на ИТ индустрию в таком ключе, забудьте, она настолько разрослась, что во многом всем правит хайп.
tlittle
21.01.2022 20:16+1Хороший (действительно хороший) админ = девопс. Потому что хороший админ и раньше пользовался всеми доступными средствами автоматизации. У него была задача - настроить так, чтобы оно все работало самостоятельно без его участия месяцами, а в случае неисправности (непредвиденной ситуации) - починить все при минимальном участии админам в минимальные сроки. При переходе в девопса не меняется практически ничего, возможно, объемы обслуживаемых ресурсов и (не всегда) используемые инструменты (возможно, как раз в связи с пунктом выше).
ky0 Автор
21.01.2022 20:51+1У меня от ваших слов просто гора с плеч, посреди всех этих дискуссий тут, разной степени релевантности. Получается, что я хороший админ :)
ALexhha
21.01.2022 21:23Хороший (действительно хороший) админ = девопс. Потому что хороший админ и раньше пользовался всеми доступными средствами автоматизации
Вообще нет. Много админов пользовалось terraform ? А cloudformation ? А kubernetes тоже сможет настроить и продебажить в случае проблем. Например, я за 15 лет работы именно сисадмином вообще не касался этого. Ну вот просто не было необходимости.
А если глубоко копнуть облака, то там столько всего. И человек просто прочитавший офф доку - не сможет настроить сервис или выполнить интеграцию с другим
В лучшем случае - они запускали пару раз докер и пару раз ансибл с парой тасков. Ничего не имею против сисадминов, раньше и сам им был, но сравнивать их некоректно. У них просто разные направления
ky0 Автор
21.01.2022 22:04-1Меня, если честно, больше интересует вопрос — много ли девопс-инженеров сможет продебажить кубернетис? Потому что по опыту общения (может, у меня выборка какая-то дурацкая, конечно) как раз складывается впечатление, что они, как вы выражаетесь, «запускали пару раз докер и пару раз ансибл с парой тасков». Любая задача, требующая хоть какого-то синтеза, да хоть и та же интеграция каких-то сервисов, не описанная пошагово в мануале облачного провайдера — вызывает существенные затруднения.
gecube
22.01.2022 00:17много ли девопс-инженеров сможет продебажить кубернетис?
Сложный вопрос. Вот буквально на днях у коллеги была странная проблема, которая решилась только переустановкой кластера в DigitalOcean. Что-то там сломалось в недрах, симптоматика ясна, но т.к. решение managed, то починить в нем ничего нельзя, саппорт провайдера молчит как Рыба об лёд (ну, и время ответа там составляет часы, иначе что-то типа премиум пакета поддержки покупайте).
Главное, что бизнес проблема решена. Все happy. Но осадочек остался
ALexhha
22.01.2022 02:51Меня, если честно, больше интересует вопрос — много ли девопс-инженеров сможет продебажить кубернетис?
Не каждый, но те кто смогут, выставят вам такой ценник - что в большинстве случаев фирма скажет, что лучше мы наймем 2-3х админов, которые если что просто переустановят с нуля ))
Ну и мой посыл был в том, что с k8s надо много работать и желательно не на локальной машине в песочнице. И вот откуда у сисадмина возьмется такой опыт. В принципе это относится и к terraform/облакам/etc
ky0 Автор
22.01.2022 10:23Ну, то есть бэкграунд (что-то я очень часто тут произношу это слово) всё-таки нужен, и немаленький — только вместо эникейства и прочих начальных этапов админства у девопс-инженера тоже должна быть какая-то стадия личинки, согласитесь? Вот мне и интересно, как это происходит, потому что навскидку вакансий типа «джуниор девопс, подай-принеси» я не наблюдаю, всем нужны сразу сформировавшиеся особи.
vya
22.01.2022 11:05Учитывая основную задачу девопса - скрещивать ежа с ужом, то стадия яйца для такого рода профессий - это упорный ленивый человек с пытливым умом (профильное образование будет плюсом если там учился, а не оценки получал) с опытом обслуживания гетерогенных распределённых систем в пару лет в роли подавана. Личинка это наличие у такого человека ещё пары лет опыта на ниве автоматизации,интеграции, и поддержки упомянутых систем. Идеально - устроится работать в предприятие, которое начинает масштабироваться с непредусмотренной для этого архитектурой и бизнес-процессами.
gecube
22.01.2022 12:47какая-то стадия личинки, согласитесь?
потому что эта стадия называется "linux администратор" в компаниях типа веб-хостинга. Так же как и с насекомыми, когда личинка очень не похожа на взрослую особь и проходит стадию метаморфозы.
gecube
22.01.2022 00:15Кубернетес точно так же как и любой программный продукт требует администрирования. Так что, да, раньше был администратор UNIX, теперь администратор кубернетес )))) Другой вопрос, что это сразу обычно называют девопсом и заходят с козырей. Но если подход остался тем же, что и тогда.... ну какой это девопс.
aik
20.01.2022 11:11+6Ну, девопёс — это стильно и модно. Облака — тоже. Так что либо плывёшь по течению, либо выглядишь ретроградом, либо пытаешься объяснить первой линии найма, что, хоть ты именно девопсом не работал, но с возлагаемыми задачами справишься. И фишечку запушите вежливо.
PS. Я из тех админов-ретроградов. Контейнеры начал ковырять в конце прошлого года только — жизнь заставила.
xeeaax
20.01.2022 11:13+7Ладно HR'ы могут ерунду нести.
Но вот же AWS у которого аж сертификация есть на DevOps Engineer: https://aws.amazon.com/ru/certification/
Неужели они тоже не в курсе того что значит DevOps?
Или может с приходом облаков роль чистого админа снизилась и отчасти перешла облачным провайдерам и с точки зрения критичности для бизнеса на первый план вышли задачи на стыке разработки и администрирования и это как раз тот самый DevOps?
В том же AWS систему на миллионы пользователей может обслуживать буквально 3-4 человека. А для бизнес не всегда важно "дешевле", может быть намного важнее "гарантированный уровень качества" и снижение рисков "завтра админ выбыл из команды и всё сломалось"
aik
20.01.2022 11:18+3Как я понимаю, вопрос больше в том, что девопса хотят даже те, кому нужно просто офисные компы админить. Или наоборот, разработчик, который будет ещё и админить инфраструктуру разработки. И немножечко шить.
indestructable
20.01.2022 13:32Чем плохо админить офисные компы за зарплату девопса? :)
aik
20.01.2022 13:41+1Если бы везде были такие зарплаты… Само собой, хочется ничего не делать, но при этом деньги получать.
Но обычно что-то типа такого — не сильно большая контора, но деньги у людей нормальные есть. Нужен «специалист общей практики», как тут ниже написали. Сеть, юзеры, видеонаблюдение, битрикс…
«Я слышал, что в Москве админам платят 25 тысяч, потому я готов тебе платить 15. По рукам? Куда-куда я пошёл?»
lastbit
20.01.2022 11:20К сожалению, реалии показывают, что бизнес в большинстве случаев ориентируется на "дешевле прямо сейчас" и есть подозрение, что в чем-то они правы (хотя на этом месте мой внутренний инженер орет благим матом). НЕ в последнюю очередь на это влияют финтопы, мнение которых, как известно, всегда весомее для бизнеса, чем мнение CTO, например.
xeeaax
20.01.2022 11:35+3Думаю то что вы называете "дешевле прямо сейчас" бизнес называет "эффективное использование ресурсов", "снижение рисков" и "эластичность ресурсов" при гарантированном уровне сервиса.
Без облака невозможно на время своей акции распродажи нарастить в 5 раз пропускную способность интернет магазина на 3 дня.
Без серверлесс невозможно дешево обеспечить какую-то ресурсоёмкую функцию, которая вам нужна раз в неделю на 15 минут, понадобится самому как-то координировать нагрузку.
Без SaaS вы не получите качественно организованный сервис на малый объем потребностей.
Что потребуется сделать для того чтобы организовать самому какой-нибудь аналог CDN или AWS Global Accelerator и представить страшно )
В каком-то смысле это всё про "дешевле" и про "прямо сейчас", но что в этом плохого?
lastbit
20.01.2022 11:43+2Мне кажется, вы - инженер) Т.к. описали исключительно верные случаи применения озвученных вами технологий. Проблема в том, что бизнес часто применяет инструменты неправильно, запихивая в облака вообще все подряд, например. Почему так происходит, думаю всем понятно.
xeeaax
20.01.2022 11:48+1Возможно потому что не все компании догадываются или могут себе позволить привлекать специалистов уровня AWS Certified Solutions Architect – Professional и AWS Certified DevOps Engineer – Professional, которые понимают возможные варианты решения тех или иных задач и плюсы/минусы каждого, включая стоимость решения.
В итоге в облака едет что попало и как попало.
Silvarum
20.01.2022 13:04+3Да и у Гугла есть свой Professional Cloud DevOps Engineer, который в целом можно охарактеризовать как принципы SRE, построение пайплайнов CI/CD, мониторинг, плюс умение всё это траблшутить. И даже главная задача роли есть: responsible for efficient development operations that can balance service reliability and delivery speed. Этакий Опс для Дева.
gecube
21.01.2022 15:46Это тот же самый Гугл, который выводит SRE инженеров и говорит, что именно SRE имплементируют (реализуют) девопс? Ну, ок
Silvarum
21.01.2022 16:56Ну что поделать, Гугл любит SRE. Только они не говорят, что SRE прям строго DevOps, SRE у них может быть применен и к SysOps — разница в постановке задачи.
Да если и AWSное понятие DevOps Engineer посмотреть — я его не сдавал, но в целом из гайда к экзамену там охватываются ровно те же топики, что и у Гугла:Заголовок спойлера- Domain 1: SDLC Automation
- Domain 2: Configuration Management and Infrastructure as Code
- Domain 3: Monitoring and Logging
- Domain 4: Policies and Standards Automation
- Domain 5: Incident and Event Response
- Domain 6: High Availability, Fault Tolerance, and Disaster Recover
yellowmew
20.01.2022 15:35А в чем проблема с DevOps Engineer? если хотите противопоставить - они же не делают курс Admin Engineer - у них вполне себе есть SysOps Administrator курс сертификации для админов
xeeaax
20.01.2022 15:48Автор утверждает, что не бывает "девопс-инженер", это методология.
А у меня нет проблем с DevOps Engineer, я по нему к сертификации готовлюсь сейчас.
ky0 Автор
20.01.2022 16:01+1Автор ничего подобного не утверждает. Да и как утверждать, когда за последние две недели мне это словосочетание озвучили десятки человек?
Автор пытается понять, чем в лучшую сторону девопс-инженер отличается от обычного, нормального админа, не застрявшего в прошлом веке и знакомого с облаками, CI/CD, контейнеризацией приложений и т. д. Чем они обычно отличаются в худшую — я перечислил ближе к концу статьи :)xeeaax
20.01.2022 16:15Тогда мои извинения, я это видимо не так понял тут:
Умом-то я, разумеется, понимал всех обратившихся ко мне в личку людей, автоматически трансформируя фразу "нужен девопс" в "процессы в нашей команде предполагают тесное взаимодействие между отделами, и сейчас мы ищем человека, который взял бы на себя часть работы по эксплуатации"
····················
Каждый должен заниматься своим деломЕсли такой инженер бывает, то зачем чего-то трансформировать? Почему не может быть его "своим делом" работать на стыке между админами и разработкой?
ky0 Автор
20.01.2022 17:34Если такой инженер бывает, то зачем чего-то трансформировать? Почему не может быть его «своим делом» работать на стыке между админами и разработкой?
В том-то и дело, что если, в соответствии с обсуждаемым нами примером, в компании уже есть девопс (методология, предполагающая тесное взаимодействие) и разработка с эксплуатацией его уже придерживается — мне не очень понятно, откуда может взяться нужда в ещё каких-то людях, которые будут заниматься исключительно задачами «на стыке». Зачем они в такой ситуации? Любая, простите за некрасивое слово, «прослойка» — будет, имхо, заведомо уступать в эффективности.
Моё недоумение вызвала тяга рекрутёров найти именно такого вот, который сконцентрирован «на стыке», но на этом его компетенции заканчиваются.xeeaax
21.01.2022 08:27+1Вы так пишете, как будто этот "стык" нынче толщиной с волос.
На мой же взгляд с распространинием концепии IaC + инструментов контейнеризации + развитием CI/CD там всё вообще размылось и этот "стык" может охватывать до 25% всей разработки.
Вот допустим мы настраиваем пайплайн так, что на каждый MR в репозитории кода будет поднят свой контейнер в AWS Fargate с версией системы для ревью и создана отдельная БД с тестовыми данными - это что по вашему? Разработка? Администрирование?
ky0 Автор
21.01.2022 10:29+1Администрирование, конечно. Вполне стандартная задача, концептуально решаемая один раз (ну, разве что тестовые данные надо будет актуализировать и по мелочи пайплайны править) в самом начане настройки CI. В том или ином виде применяется примерно везде, только не всегда с использованием облаков и контейнеров.
xeeaax
21.01.2022 11:29+1Ну допустим, а если там не просто контейнер + бд, а уже целый набор всякого добра, типа NoSQL serverless базы, s3-хранилища, sns-топики для доставки уведомлений об изменениях + несколько serverless-лямбд и это под api gateway всё и load balancer'ом, и это достаточно часто меняется - это всё еще администирование или уже куда-то в разработку начинает просачиваться?
ky0 Автор
21.01.2022 12:17Дак никто же не спорит, что оно может в каких-то случаях просачиваться и просачивается довольно часто.
Думаю, что озвученную вами задачу я начал решать бы в обнимку с разработчиком (ну или периодически бегая к нему за уточнениями). Скорее всего, его помощь потребовалась бы только в самом начале — чтобы в целом понять, как оно работает.
Но это не отменяет того факта, что у нас есть человек, хорошо разбирающийся в разработке и человек, хорошо разбирающийся в эксплуатации. Откуда у сферического девопс-инженера без бэкграунда возьмётся знание всего этого (помимо обучающих лаб GCP/AWS/etc) — под вопросом.gecube
21.01.2022 15:48Откуда у сферического девопс-инженера без бэкграунда возьмётся знание всего этого (помимо обучающих лаб GCP/AWS/etc) — под вопросом.
10+ лет в индустрии? Причём желательно ещё и чтоб этот человек хоть немного интересовался разработкой? Хотя бы на минимальном уровне? У нас был пример, когда прям админы-админы автоматизировали свою работу на Python и даже для техподдержки целый мини портал для управления ssl сертификатами набабахали
ky0 Автор
21.01.2022 17:01Я об этом и говорю — откуда знания в смежных областях появляются у людей с бэкграундом и 10+, мне ясно. А у сферических-то, у сферических, которые ещё с горящим взглядом и кроме
модногопростите, актуального, ничему не обучены?
xeeaax
22.01.2022 16:51Ну 10+ прям необязательно. Для начинающего девопса на мой взгляд 1-2+ вполне уже норм будет, если человек постоянно новое осваивал и практический опыт имеет в эти 1-2 года.
3-5+ это уже очень хороший уровень можно наработать, практически на передний край выйти по уровню знаний.
Другое дело, что некоторым стаж не помогает. Не так давно собеседовал человека с опытом 25+ лет, он был ведущим разработчиком, руководил командой разработки, и он не понимает что такое транзакции в БД.
pokercase651
21.01.2022 01:07+1Автор пытается понять, чем в лучшую сторону девопс-инженер отличается от обычного, нормального админа, не застрявшего в прошлом веке
Возможно тем, что девопс, что называется, проактивен? Т.е. это не тот случай, когда его нужно просить что-то сделать ("сначала создай мне задачу в Jira, и согласуй ее с моим начальником"), а наоборот - он сам предлагает что-то поменять (узнает у разрабов какие сервисы и как мониторить, настроит заббикс, расскажет об этом специалистам поддержки, ...).
Или вы считаете что админы всегда настроены улучшать процессы и технологии даже если их никто не просит об этом?
chupasaurus
21.01.2022 07:53вы считаете что админы всегда настроены улучшать процессы и технологии даже если их никто не просит об этом?
Нормальный админ ленив не потому, что ничего не хочет делать, а потому что пытается сократить работу до минимума. Если ни у кого нет запроса на изменения, то могу напомнить про преждевременные оптимизации.
cadmi
21.01.2022 11:13+2Нормальный конечно проактивен. Всю жизнь так и было. Приходили и говорили "вот у вас тут жопа растёт, пока ещё пасмурно, но скоро станет такой мохнатой, что Солнце закроет". Потому что его мониторинг показывал, что потребление памяти скоро будет уже ни в какие ворота (даже для облака, просто дорого станет), так что он вежливо интересовался "эй, на баркасе, у вас там всё нормально? Вот этот процесс поджирать стал". Бывает, конечно, что тимлид бэка отвечал что-то вроде "всё ок, бизнес-требования изменились, с финдиректором согласовано, жгите деньги". Но зачастую разработчики издавали слабый писк: "ой, и правда, сорян, протупили, не нужны там такие SELECT * FROM blablabla; сейчас исправим на SELECT id, title FROM blablabla LIMIT 10;"
А не делающий то что вы в своем комментарии описали, это не администратор, а много раз упомянутый в комментариях к этому посту эникейщик, который что-то там как-то настроил и всем в последнюю пятницу июля рассказываший, что он "тоже админ".
vitaly_il1
21.01.2022 08:57+2Ничем не отличается. Но сегодня это так называется. Такова жизнь. Может, они и неправы в теории, и ИМХО большинство неправы в том, что всовывают в продакшен вещи, которые появились полгода назад. С другой стороны - нам сейчас платят больше чем разработчикам, так что жаловаться грех.
Не вижу смысла идти против течения.
(мне 58 лет, DevOps Freelancer)
1Tiger1
21.01.2022 16:37В лучшую и худшую для чего? Эти понятия никогда не существуют в вакууме, они всегда относительно какой то ситуации иди задачи.
aliencash
20.01.2022 11:30+6Нам нужен офтальмолог и чтобы немножко гинеколог...
StjarnornasFred
20.01.2022 11:59Да не, скорее просто фельдшер. Если у вас не медицинское учреждение, то вам не нужен ни гинеколог, ни офтальмолог - вам нужен штатный медик общей практики, который способен сделать прививку, оказать общемедицинскую помощь, в случаях заболеваний отдельных органов примерно поставить диагноз и назначить симптоматическое лечение типа "не смотрите на свет 10 дней и засуньте туда марлю с порошком из аптечки", составить журнал болезни и, если не помогло, сдать пациента врачам при первой возможности, сохранив его живым и не слишком нездоровым. Врач общей практики.
То же и с айтишником общей практики. Если у вас не айти-компания, вам нужен эдакий фиксик-помощник общей практики, а не специалист по разработке ПО.
jh7
21.01.2022 08:54Это называется - врач-терапевт. И в поликлиниках так и проиходит, терапевт либо сам лечит, либо напраляет к узким специалистам.
MaxBask
21.01.2022 10:39То есть если фельдшер не справился, узких специалистов нет, потому что он за всех, он передает живого и не слишком здорового пациента следующему пришедшему на эту работу фельдшеру.
Phoen
20.01.2022 11:38+2Проблема знакомая и мне кажется состоит из двух частей:
Для generic HR - довольно существенное пересечение кейвордов, и не важно что при таком подходе senior admin окажется при таком подходе junior devops'ом (и наоборот).
Девопсы бывают разные, но использование облаков в построении инфраструктуры во многом снижает требования к фундаментальным знаниям (там нужнее условные курсы AWS чем Таненбаум). Вот собственно поэтому и снижается роль "эксплуатации" в процессах и знания у людей несколько специфичны и вообще из другой оперы.
p.s. Я то вообще хадупсы с etl'ями кручу по финтехам, и то постоянно пытаются вакансии девопсов подсунуть и искренне удивляются когда отвечаю им что это не совсем мой профиль)
ZooXan
20.01.2022 11:38+3Определения позиции DevOps как человека конечно не существует. Можно назвать его инженером практик DevOps. Но практический эффект HR фокусов с именованием позиций таков, что если уж рынок начал предлагать такие деньги за то чтобы выполнять функции того же админа у которого в CV записаны акутуальные куберенетесы, прометеусы и т.д, то надо этим пользоваться. Как сказали в одном из профильных чатов: "Больше всех выиграет та компания, которая поймет, что можно просто брать качественных админов вместо девопсов. Немного боевого опыта и новых технологий и полноценный девопс готов."
ky0 Автор
20.01.2022 11:43А почему вы по умолчанию считаете, что для трансформации «качественного админа» в девопса ему придётся постигать какие-то новые для себя технологии? Имхо, в активно развивающемся проекте команда и так с высокой вероятностью использует и контейнеры, и оркестрацию, и всё остальное — то есть по факту, админ скорее всего со всем «девопсовским набором» и так знаком. Но это не делает его из админа кем-то другим :)
ZooXan
20.01.2022 11:46+2Так я наоборот утверждаю, что разницы практически нет в условиях, когда рынок видит пропасть между админами и девопсами. А если рынок платит, то хоть одуванчиком меня называйте.
ky0 Автор
20.01.2022 11:58А, это была чужая цитата! Прошу прощения, я был невнимателен.
ZooXan
20.01.2022 12:04+3На самом деле, мне кажется, что далеко не всем админам удается поработать с контейнерами, оркестраторами и облаками на своих проектах. Лично знаю нескольких инженеров, которым приходилось самостоятельно доучивать несколько технологий, чтобы с чистой совестью повесить себе лычки девопса в резюме.
Jammarra
20.01.2022 20:16А почему вы думайте что компания будет экономить? Мне лично пофиг девопс я, админ или sre денег просить меньше не буду)
KarmicDude
20.01.2022 12:10+10Плохие рекрутеры попадались или сама компания не понимает кто им нужен, видимо. Потому что у вакансии DevOps есть достаточно четкий перечень требуемых навыков и опыта работы с технологиями и инструментами. И как человек непосредственно учавствующий в наеме DevOps специалистов, могу сказать, что есть обратной сторона того, что озвучил автор поста. Приходят админы с большим опытом на вакансию (опомнившись после условно 8 лет существования практики DevOps, что это востребованно и там платят хорошие деньги), они сами идут туда, полагая, что их "мощного бэкграунда" в виде понимание принципов работы сетей и линуксов и знания базовых инструментов типа ansible и terraform (в лучшем случае), достаточно чтобы называть себя DevOps и получать как DevOps. Нет, это не так). Этого не достаточно. И не достаточно знания перла или питона).
Говорить что девопс это философия, методология - я не буду. Но на практике, весь опыт приобретенный таким матерым классическим админом, который спит с циской в обнимку и знает все интимные подробности ее консольной конфигурации, в перерывах между работой читает системные логи и дамп трафика в wireshark, с закрытыми глазами собирает блейд за 30 секунд и всё такое прочее - он не нужен. Достаточно вменяемых базовых знаний по сетям и линуксам. Этого будет за глаза для 99% **задач бизнеса**. Им не нужны такие знания, потому что уровень абстракции совсем другой. Намного важнее действительно хорошо влаедть практиками по организации CI/CD пайплайнов, по умению приготовления кубов, обвязки для создания обсервабилити и мониторинга и хороших навыков траблшутинга, понимания как правильно выстраивать архитектуру микросервисов, приготовления правильного алертинга, знание облачных платформ и широкого перечня инструментов вокруг всего этого.
А еще админы, в своем подавляющем большинстве, чаще всего, действительно такие как описаны в посту. Мое мнение вряд ли можно назвать предвзятым, я сам проработал лет 10 системным администратором Linux. Я сужу по многим знакомым с прошлых работ поддерживая связь, которые так и остались в этой сфере, сужу по тем кто приходит спустя годы ко мне на собеседования на вакансию DevOps. Везде есть исключения, но мой опыт говорит о неповоротливости, негибкости, отсутствии желания осваивать большое количество сложных инструментов, о закостенелости взглядов и суждений.
Это альтернативная точка зрения) не претендую на ее однозначную истинность. Но мой опыт работы в сфере за долгие годы каждый раз подтверждается. Намного разумней будет взять молодого джуна с горящими глазами, решившего идти по стопам девопса, чем брать таких вот админов, который тебе среди ночи протараторит без ошибок строение заголовка TCP пакета побайтно.
Ну а проблема с тем, что рекрутеры приходят сами к админам и не понимают, кто же такой DevOps - это и косяк руководства, и сильная нехватка кадров на рынке, что приходится заглядывать в смежные области, и отсутствие нужной квалификации для понимания того кто нужен и погоня за модными тенденциями без осознания необходимости и пр. и пр.
aik
20.01.2022 12:37опыт говорит о неповоротливости, негибкости, отсутствии желания осваивать большое количество сложных инструментов, о закостенелости взглядов и суждений.
Сужу по себе — и согласен. Тут и лень, и принцип «работает — не трожь», и привычка — если железку я вижу и могу залезть в неё с отвёрткой или на своём почтовике я могу любые свистелки прикрутить, то в облачном сервисе — только то, что владелец разрешил.
Ну и, само собой, место работы сказывается и обязанности вообще. Одно — когда ты в айтишной конторе работаешь и другое — когда на производстве, где приоритеты совсем другие.
Вон, сейчас задача — древнюю конструкцию на информиксе прикрутить к 1С. При этом сделать так, чтобы «всё само», потому что нажать кнопочку импорта юзеру тяжко. Облака тут не спасут…
Вон выше написал, что до контейнеров только в конце года добрался — да и то не сильно по своей воле, жизнь заставила.
werevolff
20.01.2022 13:49+3Согласен. DevOps - это не админ с бэкграундом, а специалист, разбирающийся в современных инструментах. Это и облака, и системы поставки конфигурации среды. При этом, девопсу достаточно знать администрирование поверхностно. Вообще, весь пост выглядит красиво, за исключением того, что, действительно, бизнесу сейчас не нужна оптимизация среды исполнения и сети. У большинства хостеров есть платные услуги администрирования. Железо стоит дешевле, чем время сисадмина. Вполне понятно, что человека это закусило: как же так, столько лет опыта, а сейчас он мало кому нужен только потому, что сейчас yaml developer получает в два-три раза больше него самого. Что я могу сказать: это рынок. И изучать актуальные технологии сейчас необходимо. Не исключено, что и лет через 10-20 программисты станут вымирающей профессией, а появятся какие-нибудь "инстансеры", умеющие работать с системами, самостоятельно создающими код.
ALexhha
21.01.2022 11:02+1DevOps - это не админ с бэкграундом, а специалист, разбирающийся в современных инструментах. Это и облака, и системы поставки конфигурации среды. При этом, девопсу достаточно знать администрирование поверхностно
Но при этом, если у специалиста есть бекграунд сисадминства, то как правило, получается более технически грамотный devops
werevolff
21.01.2022 11:15Да, и я работал с такими специалистами. В то же время, хороших админов, которые неделями не могут разобраться в особенностях деплоймента кода, я тоже видел. И здесь вопрос возвращается к пресловутому уровню абстракции: одно дело уметь поднять и настроить сеть, а другое - знать особенности готового инструмента и его конфиг с командами. У чистых сисадминов необходимость разбираться в устройстве микросервисов, может вызывать отторжение. А когда руководство решает вынести в облака всю инфраструктуру, зачастую складывается ситуация, когда ручками уже ничего и не надо настраивать. Поэтому, компании ищут девопсов, а не администраторов. Когда же у компании есть потребность в ручной настройке серверов и сети, нужен админ.
vitaly_il1
21.01.2022 09:05+2Намного важнее действительно хорошо влаедть практиками по организации CI/CD пайплайнов, по умению приготовления кубов, обвязки для создания обсервабилити и мониторинга и хороших навыков траблшутинга, понимания как правильно выстраивать архитектуру микросервисов, приготовления правильного алертинга, знание облачных платформ и широкого перечня инструментов вокруг всего этого.
Согласен. Но, как и написал топикстартер, хороший сисадмин (который инженер, а не аникейщик) это умел и делал и до переименования.
А так - я вот старый (58 лет), и по-прежнему с бородой, и даже свитер ношу - но переименовался и очень доволен. (серьезно говоря, я больше доволен что стал фрилансером, но у меня эти две модификации совпали)
elve
21.01.2022 11:32+1Я почти согласен с вами. Но есть спорный момент =).
То что вы описываете это больше похоже на закостенелось. С возрастом у многих начинает проявляться. У некоторых довольно рано почему-то. Это не характеристика админов - это характеристика старения людей в целом.
Тоже покажу на личном примере =). Несмотря на опыт, меня Iac со всеми его проявлениями привел в восторг еще до появления термина DevOps. В одной из контор пытался внедрить puppet с хранением конфигураций отдельно в mercurial. Идея с хранением выросла из практик моего превого места работы ( @merlin-vrn не даст соврать - там конфиги и скрипты хранились в svn, когда это еще не было мейнстримом, так сказать). Был непонят, т.к. зачем писать манифесты полдня, если можно вот сейчас зайти поправить конфиг и забыть (и не вспомнить, когда придется заново настраивать) =). Но мое время все же пришло ).
Я понимаю почему многие админы не умеют облака и кубернетис - в их организационной стуктуре оно в целом не сильно нужно. Однако packer, terraform/vagrant, ansible и gitlab сильно упрощают работу, если часто надо разворачивать новые сервисы или восстанавливать старые. А ELK и Graphana еще и красоты добавляют =). Эти инструменты уже стандарт для современного админа.ky0 Автор
21.01.2022 12:25Вы всё правильно говорите. Единственная ремарка, которую я себе позволю — IaaC и прочий девопс сейчас настолько покрыл тонким слоем всё IT, что инструменты вроде того же Кубернетиса начали использовать в микроскопических компаниях или просто в проектах, которым он не подходит — где подобные ухищрения, имхо, преждевременны или противопоказаны. Менеджер требует «всё в облака!», но по факту часто получается, что в облаке бултыхается жалкий один экземпляр сервиса, а ни о каком автомасштабировании, умной балансировке нагрузки и т. п. и близко речи не идёт.
Это не значит, что админу не нужно знать все эти, скажем честно, уже некоторое время назад ставшими стандартами для индустрии технологии. Просто применять их в каждом случае совершенно необязательно.
cadmi
21.01.2022 18:57+5Так о чем и речь, что для нормального классического админа все эти перечисленные штуки - просто еще один молоток, который он за свою карьеру выучит. И сколько он их выучивал уже, и забыли. И это забудут и новое придет.
Это. Просто. Очередной. Молоток. Сколько их было и сколько их еще будет.
Ну просто в 1997 мы (да, я довольно старый) раскатывали shell скриптами, которые запускались вручную, несколько лет спустя раскатывали теми же скриптами, но которые уже запускались хуками из репозиториев. Где-то примерно в это же время и чуток позже энтерпрайз пацаны вдоволь наглотались какого-нить CFEngine (на минуточку, с 1993 года существует), а пацаны попроще сказали что это оверкилл и потом как-нибудь. Потом друг за другом по очереди посверкали puppet (2005), chef (2009), потом практически одновременно (2011-2012) ansible (для админов неуязвимых локалхостов и еще пары десятков ЭВМ) и saltstack (для серьезных пацанов, у которых хосты сотнями). И т.д.
Параллельно появлялись, входили в моду и умирали cacti и statsd/graphite, и далее со всеми остановками, которых в итоге затаптывали prometheus/grafana. А на смену прометею уже накатывает victoria :)
Где-то еще лет 25 назад bsd'уны в конце 90-ых изолировались jail'ами, потом всем шкетам как надо показывали своими zones solaris-папки, потом всех победил велосипедный cgroups со своими обвязками-обмазками всех сортов и вкусов (где-то вошел в моду и вышел LXC). Купечество в какой-то момент облило все заборы желтым кипятком, что контейнеры - rulezzz (фу, лет 20 по-моему уже так писать немодно, аж самого передернуло). Но контейнеры контейнерам рознь и вот уже на хабре появляются статьи, что "docker - это прошлое десятилетие, теперь podman" :)
Это колесо сансары бесконечно. И кто его крутил? Да админы же и крутили.
Неужели есть такие люди, которые всерьез думают, что админ - это тот, кто ip адрес и маску сети для интерфейса в текстовом файле указывает все 30 лет? Ну камон, бояре, вы чего...
Мы те же самые. Просто теперь у нас не bare metal и скрипты, а облака и terraform.
Переживем и новое название, посмотрим еще на пенсионной лавочке, как devops'ы будут брюзжать, что пришла молодая шпана и назвалась еще более buzzword'нутым названием.
cadmi
20.01.2022 12:26+8А дело ещё в том, что надо было ещё маленькими в зародыше давить меняющих картриджи в бухгалтерии эникейщиков (IT technician), которые с каких-то щей всю дорогу называли себя "администраторами". Естественно, однажды наступил момент, когда настоящим админам окончательно надоело ассоциироваться с этим шлаком (кому "обидно", а кому попросту "стыдно"), а тут еще очень кстати какое-то новое название придумали и все туда побежали :)
LeXaNe
20.01.2022 14:05+2Ну не знаю, работал 10 лет назад в филиале крупной государственной организации не связанной с IT и нас называли программистами (представляю, как обидно настоящим программистам, ассоциироваться с таким шлаком, как мы) )))
cadmi
20.01.2022 14:31Им было не до вас, они в это время негодовали, что их ассоциируют с вон теми "тожепрограммистами", которые формы на foxpro клепают :) (которые потом 1сниками стали)
Terras
20.01.2022 13:31Получаешь 100к — работаешь админом. Ставишь лычок — Devops — выступаешь хотелку 250 плюс и обучение. И ощущаешь на себя прессинг девушек, что хотят затащить тебя на собеседование.
Ну а дальше, это уже удел компании — понять who is who.
Flidermouse
20.01.2022 14:13А разве раньше не так было? «Тыжпрограммист» мем ещё с конца 90-х, когда сисадминов называли сосопами и/или наоборот. Да и по соотношению обязанностей к зарплате тоже. Ведь "работать в нашем банке большая честь"
ALexhha
20.01.2022 17:50+1Третий борется с проблемами производительности с помощью увеличения количества ядер и памяти, выданных виртуалке.
Часто это единственно верный способ. И в большинстве случаев бизнес не даст вам неделю-другую на дебаг. Так что я не был бы так категоричен
ky0 Автор
20.01.2022 18:20Да, согласен, бывает и такое. Но конкретно в том случае это было монолитное java-приложение, которому просто докинуть ресурсов в виртуалку недостаточно — как минимум, надо было посмотреть, что там с аргументами запуска JVM, GC, пулом коннектов к базе и т. д.
lllamnyp
20.01.2022 19:09Но согласитесь, это же странно и вызывает вопросы к джава-разрабам? Кто они - java software engineers, которые должны ориентироваться в контексте задачи и, помимо составления алгоритмов ещё знать примерно, как работает jvm или это code monkey, которые git commit && git push и отстаньте от меня? Если первое, то, наверное, справедливо, что стрелочка поворачивается и в другую сторону?
ky0 Автор
20.01.2022 19:42Нет, минуточку — при чём тут разрабы-то? Они к проду могут вообще доступа не иметь. Их дело — закодить без ошибок, выдать рекомендации по ресурсам, рантайм-опциям, не знаю, докер-конфиг для сборки окружения там…
Они же не могут заранее предугадать, в каких условиях будет работать их детище. Где-то база находится на том же сервере и ничем другим не нагружена — можно забить на пинг до неё и настройки пула коннектов, а где-то до неё нужно долго и печально лезть через 100-мегабитный линк. Где-то на ПО микроскопическая нагрузка, а где-то наоборот лютый rps.
Можно, конечно, в каждом случаё дёргать разработчиков — но, имхо, специалисты эксплуатации для того и нужны, чтобы разбираться в подобных вещах. Я знаю кучу прекрасных кодеров, которые примерно ни в зуб ногой относительно того, как настраивается вакуум и bgwriter в СУБД, сеть, как работает oom-killer в линуксе и т. д. И слава богу — потому что это не их стезя, пусть оставят подобные вещи специально обученным людям. Например, мне :)ALexhha
21.01.2022 00:23+2Нет, минуточку — при чём тут разрабы-то вообще? Они к проду могут вообще доступа не иметь. Их дело — закодить без ошибок, выдать рекомендации по ресурсам, рантайм-опциям, не знаю, докер-конфиг для сборки окружения там…
А вы предлагаете девопс инженеру дебажить джава приложение на проде. Делать профилирование и выдавать разработчикам рекомендации по тюнингу JAVA_OPTIONS ?
Я знаю кучу прекрасных кодеров, которые примерно ни в зуб ногой относительно того, как настраивается вакуум и bgwriter в СУБД, сеть, как работает oom-killer в линуксе
Для этого есть DBA/сетевики/админы. Как правило, это не задачи разработчиков
ky0 Автор
21.01.2022 10:45Мы начали этот диалог с моей цитаты про производительность. В данном примере ничего дебажить не нужно, всё работает без ошибок — просто недостаточно быстро. И да, я считаю, что админ должен как минимум покурить графики мониторинга, продиагностировать причины этих тупняков и попытаться с ними справиться самостоятельно.
Вполне возможно, что дело действительно в каком-то узком месте в коде, но чтобы перейти к этому предположению, нужно исключить более банальные варианты — недостаток выданной процессу памяти, фигово затюненный сетевой стек ОС и т. п.ALexhha
21.01.2022 11:09И да, я считаю, что админ должен как минимум покурить графики мониторинга, продиагностировать причины этих тупняков и попытаться с ними справиться самостоятельно.
Мониторинг вам показал, что ваше java приложение потребляет слишком много CPU/RAM/HDD. Что дальше будете делать ?
ky0 Автор
21.01.2022 12:30«Слишком много» — это абстрактная характеристика. Вполне возможно, что потребление соответствует нагрузке. Если же нагрузки нет или такой же экземпляр сервиса по соседству потребляет на порядок меньше — это повод снять дамп потоков и посмотреть на него (возможно, совместно с разработчиками). Но это не отменяет диагностики вне самого приложения — может, ядро на виртуалке какой-то баг словило, или какая-нибудь шара сетевая отваливалась и из-за этого всё залипло. Всякое бывает.
Korobei
20.01.2022 20:45Может посмотреть на devops roadmap, если подходишь, то и не париться и гордо называть себя супер-сеньор devops.
ky0 Автор
20.01.2022 20:55Да, я ходил по этой ссылке — и могу сказать, что больше половины указанных там технологий нанимающими в РФ девопса девопсячьими не считаются, а считаются админскими — и при упоминании в работе вызывают ужас и непонимание. Тут люди не знают, как LVM-том увеличить, а роадмап им strace с awk предлагает :)
Korobei
20.01.2022 21:08Может ссылку на резюме добавите в статью, чтобы лучше понимание было про что речь.
И в статье не увидел явного указания на то что делать-то надо, с вашей точки зрения?
С учётом того что (пере)обучить тысячи HR не реалистично.
Jammarra
20.01.2022 22:09+1Я сам как админ вынужден признать. Админы станут не нужны. Не завтра и не после завтра. Но постепенно.
Нужны офигенные инженеры разработчики которые отлично знают ос и архитектуру. И писатели ямлов. Классическим админам в современном мире места нет.
Они бы уже и вымерли. Только вот хороших разрабов которые могут все автоматизировать нахватает просто жутко.Даже за дорого. На рынке одни джуны которые умеют писать формочки.
именно поэтому на нем и есть место для недоучек типо меня которые что то там потыкали и типо умеют Кубер поднимать.
Как называть этих людей. Архитектор инфраструктуры, девопс, сре или ещё как то. Дело второе
elve
21.01.2022 11:40+1Админы нужны и будут нужны. Только нужно эволюционировать.
Когда-то можно было мечтать об автоматизированном создании виртуалок, автонастройке софта и либо ваять свои километры скриптов чтобы как-то облегчить работу. Сейчас инструментария валом просто. Достаточно скачать приложение, изучить несложный синтаксис и можно увеличить свою производительность в разы.
DevOps-ы в разработке живут. А остальным конторам ведь тоже надо инфраструктуру админить.Jammarra
21.01.2022 14:04-3Что значит админить инфраструктуру? Ставить сервера в стойки и винты менять?
Ну так это делают техники цода.
Ставить linux и т.д.? Ну это делают писатели ансибла и терраформа. И тут важнее скилл програмирования, что бы например написать свой модуль для того же ансибла. Покрыть пайплайн тестами. И т.д. А не знание шелла.
Делать сложный мониторинг? ну так это опять же делают программисты, которые могут написать свой экспортер.
Делать свой оператор для кубера или кастомизировать его политики? Ну возвращаемся к программистам.
Есть такое понятие Системный програмист. Вот про это все и там требуются глубокие знания систем и программирования.
А серверные на 5 юнитов в шкафу где надо было поддерживать уже давно отмирают. Легче где то в Селектеле или амазоне инстанс взять для бизнеса.Как отличить гамотного опытного разраба который пишет пайпы от бывшего админа? Ну на мой взгляд первое и ключевое отличие, в том что бывшие админы никогда не пишут тесты.
Типо надо 3-5 сервера задеплоить. И мы фигарим на ансибле пайп условный. А вот покрыть его тестами что бы быть уверенным что он будет делать точно то что надо. Это уже ниже нашего достоинсва. Грамотный люди из разработки же обычно об этом не забывают.
Второе отличие это например ООП про который админы не в курсе, когда бывший админ пишет скрипт эта лапша которую никто не поймет и которую потом задолбаешься расширять. А у программиста все по классам, методам и т.д. разбито. Бери и используй.Еще раз проблема только что такие грамотные разрабы хотят ЗП под лям. И их на всех не хватает. Но в целом они давно бы могли админов недоучек заменить.
Я просто как сам админ прошедший стадию отрицания не так давно пришел просто к тому что Админ это просто неграмотный мало образованный разработчик).
Что то вроде того что есть люди закончившие универ, а есть закончившие ПТУ. И с развитием IT спрос на ПТУшников просто снижается. Нужно меньше людей. но требования к ним растут.Точно так же снижается спрос на ПТУшников среди "разрабов" которые сайты на вордпресе делали и других недоучек.
elve
21.01.2022 14:43+1Пойдем не совсем по порядку =)
Тема ЦОД vs локальные железки холиварная. Предлагаю не заглядывать в эту бездну. Эти два варианта существуют, т.к. есть условия где один из вариантов будет лучшим выбором чем другой. А можно еще и миксовать.
Почему админ не может пользоваться ansible и terraform? Удобные инструменты для облегчения рутины админа.
Не прометеусом единым. Можно ведь использовать zabbix и писать не экспортеры, а userparameter-ы и скрипты под них =). Да и под прометея есть push-gateway, кстати. В мониториге больше важны правильные метрики, а не инструмент. Инструментов много и можно выбрать по вкусам и целесообразности.
Кубернетис за рамками разработки и веб-сервисов не очень сильно распространен. Не везде его использование целесообразно.
Админить инфраструктуру значит админить инфраструктуру. Где-то это 20 компьютеров, файлопомойка и мини-атс, а где-то распределенная сеть филиалов с отказоустойчивостью и резервированием.
Jammarra
21.01.2022 15:44-2То что вы перечислили относится к эникею. Эникеи да будут нужны
может я зажрался, но 20 компов и мини атс инфраструктурой не считаю. И такое "админил" лет в 19 учась в универе.
возвращаясь к тому что админ просто малообразованный айтишник который не боится этой шайтан машины.
по мне так понятие инфраструктура начинается ну где то с пары стоек.
А по поводу ансибл и терафформ. В любых крупных инсталляциях ему не хватит стоковых возможностей. А дальше нужно писать свои модули и плагины самостоятельно.
elve
21.01.2022 16:26+1В примере я упомянул также и распределенную сеть филиалов некоего предприятия. Попробуйте представить что там по две стойки хотя бы в 3-4 филиалах, всего филиалов 140.
Предлагаю этот спор далее не продолжать. Предвзятое отношение не располагает к продуктивной беседе.gecube
21.01.2022 17:02remote hands на местах? Потому что ездить одному человеку или даже бригаде по 140 филиалам, да еще и в разных городах - попросту нереально
elve
21.01.2022 18:03Именно так. Но это, в данном случае, непринципиально. Товарищ пытается доказать, что админы ненужны и вымрут, т.к. нечего администрировать =). Я просто привел контрпример.
gecube
21.01.2022 19:08ну, это не совсем админы. Для "поменять диск в сервере" или "воткнуть патчкорд в сетевку" достаточно инженера техпода или какого-нибудь инжира из подрядной конторы. Для "заменить память в сервере" потенциально еще может приехать сертифицированный инженер из вендора, но это точно не для всех компаний... потому что там денег за сервис изначально заплачено прилично... По-всякому бывает
Jammarra
21.01.2022 17:06Ну так в тем более надо централизованно в нормальном ЦОД все делать. А на места давать тонкие клиенты, например.
Есть конечно специфика предприятий например на сервере где интернет плохой. И там это не прокатит. Но это прям очень специфичные кейсы.По факту в 95% случаев любой корпаративный софт представляет из себя просто веб страницу. Которая крутится уже на серверах. Часто даже не в этой компании. А просто покупается. О чем и говорил с самого начала.
Поэтому я скорее представяю пару цодов с 500 стойками на котором крутится какое то приложение. Которое по подписке покупает 10 000 предприятий. И для обслуживания и развития которого и нужны высококласные разработчики. А самим предприятиям это все нафиг не упало, держать штат людей и пару железок.
Таже FTP помойка в 2022 году нужна как собаке пятая нога, если можно купить пространство на любом s3 совместимом хранилище хостинга.
Банальный пример. Еще лет 15-20 назад почти у каждой компании были свои почтовые сервера.
Но кому в наше время придет в голову ставить свой почтовик и искать для него админа. Когда можно сделать нормальную корп почту на гугле или яндекса. Даже не представляю. Если это не предприятие на десятки тысяч людей с нестандартными кейсами. Но в таком предприятии одним сервачком с сендмейлом уже не отделаешься. Там нужен лютый эксперт именно по почте. Который наполовину свой почтовик дико кастомезированный напишет с учетом конкретных тербований.gecube
21.01.2022 17:28нет, есть еще регуляторка.
Банки, например.
Крупный бизнес типа Газпрома, Х5, Аэрофлота.
Что еще захочет свой почтовик?
В остальном согласен - многие используют облачные сервисы, в частности, зарубежом, но там нет "происков внешних врагов" и необходимости строить свою критическую инфраструктуру
Но в таком предприятии одним сервачком с сендмейлом уже не отделаешься.
да, но в другом ключе - потребуется еще среда виртуализации, VDI, стопицот всяких странных средств, PowerBI, Tableau, 1C, SAP и прочее
Там нужен лютый эксперт именно по почте.
ну, не лютый, но эксперт или специалист. Возможно, который будет шериться с другими задачами (например, настройкой слак, зум и прочих средств коммуникаций)
elve
21.01.2022 18:22+1Один пример. Кейс более чем стандартный.
Итак.... Две сети филиалов магазинов одинакового профиля.
Первая сеть: в каждом магазине своя БД склада и настроена синхронизация с головным филиалом. Продавцы работают всегда с локальной версией и иногда запрашивают остатки у других филиалов.
Вторая сеть: БД по складам одна в ЦОД-е (даже в нескольких) и все рабочие места на тонких клиентах.
А теперь ситуация: экскаватор докопался до коммутационного колодца и порвал оптику идущую в ТЦ. Какой магазин продолжит работать и зарабатывать денежку?
К трактору прикапываться не надо =). У отвала интернета может быть много причин. Вплоть до того, что просто не оплатили.
Про почтовый сервер не понял. Какая-то очень мелкая проблема взята и очень древний софт для примера. Вам нужно освежить знания. Давно уже не нужен (а когда-то был нужен? о_О) отдельный специалист по электронной почте и даже переписывать ничего не надо =).Jammarra
21.01.2022 18:45А теперь ситуация: экскаватор докопался до коммутационного колодца и порвал оптику идущую в ТЦ. Какой магазин продолжит работать и зарабатывать денежку?К трактору прикапываться не надо =). У отвала интернета может быть много причин. Вплоть до того, что просто не оплатили.Ни один, если нет резервного интернета. Так как у 90% людей налички уже давным давно нет в наличии. И если ты скажешь "терменал не работает" То они просто развернутся и уйдут.
Поэтому в первую очередь нужно резервировать канал.
Ndochp
22.01.2022 20:54Толщина канала для терминалов по числу касс и всей БД с остатками товаров слегка разная. можно под столом и резервные терминалы с симками держать. Или у своих же курьеров отобрать. А чеки с кассы через месяц слить, когда инет починят.
1Tiger1
21.01.2022 03:15Раньше когда у меня была проблема с окружением или я понимал что не смогу настроить нормально прод (ну, или что чаще, мне неохота было это делать), я шёл к админу. Сейчас, в такой же ситуации я иду к девопсу. Да вместо работы с конфигами, пакетами и bash скриптиками теперь у меня докер, конфиги и другие скриптики, а на проде вообще часто происходит магическая дичь, глубоких деталей которой мало кто понимает, и я подозреваю что где то в глубинах aws уже зародился сильный ИИ и он там всем управляет, заодно периодически подкидывая ещё один уровень абстракции между собой и тем с чем работает человек чтобы отгородить себя и код от человеческих рук разной кривизны. Но суть та же, админ, девопс, человек решающий задачи окружения, платформы на которой будет выполняется софт, мониторинга, выяснения и решения проблем со всем этим, в идеале ускорением и повышением стабильности, и автоматизации. И не важно, пишет ли он скрипты на баше или конфиги в ямле, собирает серверы, компилит из исходников, или творит магию поднимая готовые площадки в облаке парой кликов (предварительно хорошо разобравшись где и что поднимать и как оптимальное для задачи настроить) , выводит top на отдельный монитор, или настраивает графики мониторинга в графане. главное чтобы разбирался. Разбирался на том уровне на котором нужно для проекта. Я 5 лет привыкал называть админов девопсами, только привык, пожалуйста, не заставляйте меня привыкать обратно.
ky0 Автор
21.01.2022 10:49Вы отлично описали ситуацию, спасибо :)
Раньше у вас был админ, который понимал, что происходит начиная от схемы электропитания сервера, заканчивая версией ядра и его модулей — сейчас девопс пушит конфиги в облако и всё работает само. Понимает ли он, что происходит там «унутре»? Надеюсь, что да — но не уверен. Мой опыт показывает, что вся магия обычно заканчивается, как только что-то перестаёт работать, как предполагается — и если рестартом контейнера и выдачей ресурсов это не решается, наступают тяжёлые деньки.1Tiger1
21.01.2022 12:36Уровни абстракции и знания необходимые для проекта. Знания что внутри это конечно хорошо, если есть основные, если нет то толку. Вас никто не пустит с паяльником в дата центр, даже если вы знаете что и как чинить и отлично разбираетесь в железе. Там есть свои люди которые разбираются. Вас никто не пустит на нижний уровень aws, даже если вы поняли где там проблема, а даже если пустят, оно наверняка сложнее чем просто машина с *nix. Если вы хорошо знаете что под капотом вам это возможно поможет, раз в год, чуть-чуть, в диагностике. Но если вы не знаете как работать на нужном уровне (а не ниже) то вы просто не сможете делать нужные задачи. Всего знать не возможно, все упирается во время. Но хуже другое, все упирается в мышление, в фокусы, в подходы к решению. И вот они вообще несовместимы. Они просто конфликтуют друг с другом. Всегда какой то уровень основной а остальные дополнительные знания и навыки. И да, если это никак не мешает работе проекта, то проще и быстрее наверное перезапустить контейнер, почему нет?
vervolk
21.01.2022 09:39+2-Извините, когда мне позвонили из вашей фирмы, мне сказали, что у вас есть вакансия девопса и что вы возьмете меня без собеседования.
-Да, и что? -На моем рабочем месте лежит фурсьют и бикини...
-Ну, вы же будете работать девопсом.
-Извините, на какую букву вы ударение поставили?
K0styan
21.01.2022 11:30+1Если уж человек с ходу употребляет термин "фурсьют", то он с любым ударением справится
Dmitriy_Volkov
21.01.2022 09:55Такс, даже, если предположить, что понятие девопс это маркетинговый ход админов, что похитрее и не хотят работать за еду, на что жалуемся? Вот он шанс в разы улучшить благосостояние ;)
HellWalk
21.01.2022 10:18Админы - занимаются инфраструктурой для пользователей
DevOps - занимаются инфраструктурой для программ (проектов)
Всегда думал, что это устоявшиеся термины, и мешать их в одну кучу - такое себе. Например админ не должен знать как настраивать CI/CD, а девопс должен. Если в офисе перестал работать интернет - идут к админу. Если упал прод - идут к девопсу.
Другое дело, что в какой-нибудь маленькой компании могут нанять админа и требовать от него все - чтобы еще и сайт корпоративный сделал, но это уже нишевые проблемы.
ky0 Автор
21.01.2022 10:52У вас какой-то админ, одной ногой стоящий в эникействе. CI/CD — это сейчас настолько общее место в любой IT-компании, что настраивать его не умеет, кажется, только совсем уж замшелые мастодонты.
elve
21.01.2022 11:56В любой девелоперской компании. К примеру в офисе строительной фирмы на 3 компьютера такой уровень абстракций избыточен.
Однако многие инструменты, которые ассоциируют исключительно с DevOps-ами и разработкой уже давно должны быть в арсенале многих сисадминов. Это я про Packer,Terraform, Ansible/Puppet/SaltStack, ELK, Grafana (на какую систему мониторинга вешать это уже вкусовщина).
elve
21.01.2022 11:53Админы бывают разных специализаций. Есть админы, которые строят сети. Есть админы, которые администрируют БД. Есть админы, которые занимаютя инфраструктурой для пользователей и т.д.
И девопса можно назвать админом, специализирующемся на инфраструктуре для развертывания приложений =).ky0 Автор
21.01.2022 12:33И девопса можно назвать админом, специализирующемся на инфраструктуре для развертывания приложений
И всё было бы прекрасно, если бы его должностные обязанности на этом заканчивались. Но если нет человека, который подставит костлявое плечо, когда «что-нибудь пойдёт не так» — по моему опыту, отлично разбирающиеся «в развёртывании приложений» начинают паниковать. Потому что, в сотый раз — нет соответствующего бэкграунда.
elisoff
21.01.2022 11:02DevOps не стал спасительнйо палочкой на пересечении нескольких граней IT,но со скрипом взвали на себя CI\CD , предоставив девелоперам больше времени на написание статей на хабре))) Надежда на универсального бойца ,решающего все проблемы не оправдалась и теперь вся надежда на SRE))) А посему замечена интересаная тенденция не на разделение направления admin\DevOps , а на совмещение . Совмещение разработки и DevOps не прижилось , попытка решать проблемы разработки силами DevOps не прижились, посмотрим что выйдет из совмещения admin\DevOps )))
RarogCmex
22.01.2022 08:11>Совмещение разработки и DevOps не прижилось
Проблема в том, что я когда учился, как раз думал именно о совмещении разработки и DevOps практик. Что буду писать код и помогать разработчикам.
Устроился на этой неделе на работу джуном в достаточно крупную контору, меня закинули в техподдержку и сказали, что твоё дело будет реагировать на инциденты, писать код не придётся.
gecube
21.01.2022 13:08Статья ни о чем, очередное нытье.
Если по делу - автор, ну, камон, серьезно - не сможешь отладить приложение на проде? Даже, если привлечь разработчиков? "Девопс" же не человек, который прямо 100% знает специфику приложения, а тот, кто может решать проблему и привлечь при необходимости дополнительные ресурсы, скоординироваться с другими отделами и работать на результат. Противоположность - этот как раз те самые админы-бородачи, которые устали от жизни и руководствуются принципом "работает - не трогай". И саботируют любые изменения. В конце-концов зарплаты 'девопсов' могут быть ВЫШЕ разработчиков средней руки.
Что хуже - девопса как такового как человек быть и не может. Всегда будет специализация - либо в мониторинг, либо в билд (релиз) инжиниринг, либо cloud engineer (всегда мечтал брать монолит, паковать в докер и деплоить в амазон, ага-ага), либо куда-то еще. Но любой смежный опыт будет полезен и экономить время как на решение задач, так и на коммуникацию со смежными отделами.
Поэтому в общем-то проблемы нет.
gecube
21.01.2022 13:09Еще на диаграмме трехлистника не хватает ИБ ))) которого подкрадывается где-то сбоку и говорить не пущать :-D
zolomihina
21.01.2022 13:11Предпоследний абзац про облака рассмешил. Похоже, вы знакомы с ними только заочно. Как по мне, эта статья - крик души человека, который не хочет развиваться, но ему обидно, что его профессию недооценивают.
rubyrabbit
21.01.2022 13:23Люди работающие на глобальном рынке указывают на то, что в русскоязычном мире полносью упускают суть "Dev" в "DevOps", в том смысле, что по задумке такой инженер на не менее чем 50% занят продуктовыми задачками. Не инфраструктурой, не саппортом, а развитием фич. И именно оставаясь наполовину разработчиком, участвуя в митингах команды и общаясь с менеджером продукта, он понимает реальные нужды и способен расследовать сложные инциденты, не упрощая реакции на все проблемы до нехватки ресурсов инфраструктуры.
В подавляющем большинстве случаев в русскоязычном мире под DevOps-инженером понимается просто "Ops".
Что тоже нужно и безусловно важно, и должно хорошо оплачиваться, но не является DevOps-ом :)RarogCmex
22.01.2022 08:14Именно! Когда я сказал, что хочу учиться прогать и быть на проекте, на меня посмотрели удивлённо:
https://habr.com/ru/post/646581/#comment_23974789
somber
21.01.2022 17:00В целом, моё политическое кредо в отношении IT-индустрии можно выразить вполне нехитро - "Каждый должен заниматься своим делом".
Вот вам и нехитрый ответ: тот, кто с этим не согласен, тот и становится DevOps
whiplash
21.01.2022 18:20+2Это один из моих любимых вопросов)
Какой процент современных молодых и не очень 'девопсов', upper-middle level, требующих от $5000 net денег - знают kernel/networking Linux stack и прочие 'кишочки' собственно на upper-middle level?
PsyHaSTe
21.01.2022 22:03По моей практике админы это вот такие вот хардкорщики, знающие до мелочей TCP и по ночам прошивающие микротики взглядом. Реже это эникейщики которые отвечают за оборудование, выдают логины в актив директори, и настраивают новым сотрудникам vpn и слак.
Девопсы же слабо шарят в низкоуровневом железе, зато шарят за CI/CD, номад вс сварм вс кубернетес, когда что лучше, гитлабы всякие настраивают и могут помочь разработчикам написать грамотный докерфайл. Шарят они хуже потому что обычно вычислительные мощности покупаются в облаке — если не авс, то тогда какой-нибудь селектел или ещё какой нишевый провайдер, где местные админы уже порешали все вопросы на этом уровне.
Это просто то, что я наблюдал, и какое разделение подразумевалось в командах/компаниях
gecube
22.01.2022 00:31шарят за CI/CD
Ща вас пуристы языка за это покарают, как меня в одном из соседних тредов. Как по мне проехались в https://habr.com/ru/company/globalsign/blog/596401/comments/ :)
imintsev
21.01.2022 22:48+1Если все в девопсы уйдут, кто сети админить будет? Кто будет строить все эти маршруты, коммутации, всякие L2/3 и прочие BGP с OSPFвми?
Кто будет MS Exchange поднимать и а AD ковыряться?
А сетки по VLANам делить, да 40+ отделов по всей стране разруливать?
Все таки, стоит разделять Devops от Net admins
ky0 Автор
21.01.2022 23:07Айписеки, айписеки не забудьте! :)
А вообще, именно с сетевиками, я так понимаю, недоразумение из сабжа пересекается меньше всего — возможно, пока что. Но зайчатки, кстати, уже появляются — когда я проходил лабы GCP, мне там попадались такие штуки, как настройка туннеля с помощью трёх переменных с обеих сторон — имени туннеля, айпишник пира и PSK. И ещё поднятие глобального CDN`а с анонсом его префикса из нескольких мест на планете «в один клик».gecube
22.01.2022 00:33Я "типа" "как девопс"
Айписеки, айписеки не забудьте! :)
В бытность свою как раз туннели настраивал и вполне даже мониторил. Ну, не было отдельных "сетевых админов", которые могли мне помочь. Ну, все стандартно - стронгсван и поехали после обильного чтения документации
elve
22.01.2022 10:12Разделять может и стоит, но пока разница в зарплатах и условиях работы колоссальна - будет переток.
Vilaine
22.01.2022 09:41+1У нас раньше была девопс-команда, потом переименовали в инфраструктурщиков, потому что это самое точное название. Это небольшая команда, которая помогает разработчикам как можно меньше отвлекаться на инфраструктурные вопросы и проблемы. Насколько меньше — зависит от процессов в компании. Но так или иначе разработчики будут работать с инфраструктурой.
Хотя есть ещё кое-что: инфраструктурщики имеют доступы, которые разработчикам не нужны (в идеале никакие не нужны, что касается прода). И, соответственно, в первую очередь ответственны за reliability, то есть должны быть более легкодоступны, чем разработчики.разница между IT-специальностями не только в должностных обязанностях, но и в соответствующем складе ума
Хорошо заметили даже в отношении dev & ops. Мне лично очень не подходит operations, даже VPN на VPS настроить. Хороший operations, я думаю, должен быть более «обстоятельным», чем разрабочик.
alef-a
22.01.2022 10:24Сейчас очень много посторонних людей в ай-ти: «потому что там плотют!»
Пэтэушники с дипломом щюкатура-маляра, бывший военный на пенсии и прочая и прочая.
Скажите, как относиться с админутым девопсам, поднимающим Moodle на докере? ????
AlexMayerLab
Ох как я вас понимаю))) Но все не так однозначно)))
DevOps не персона, это больше про процессы ) и это важно понимать)
Но абсолютно согласен что на рынке много компаний которые этого не понимают, и в понимании некоторых это человек оркестр который закроет собой 3-5 ролей на проекте)
Chelyuk
"Половина - не бывает большей или меньшей. Но, к сожалению, большая половина класса этого не понимает." (с)
Source
По-моему это уже не про процессы, а тупо модное название для админов. Как раньше ввели в моду "разработчик" вместо "инженер-программист". По факту одно и то же, но разработчик звучит более хипстерски. С девопсами тоже самое.
fhntv_smart
Ну да. Если на вакансии дево-псов больше зарплаты я иду на дево-пса.
Source
Главное смузи на собеседование не забудьте ;-)
tlittle
Я бы не стал утверждать так однозначно. Классический админ - это настройка системы вручную (в лучшем случае, в полуавтоматическом режиме). Т.е., красные глаза, моток проводов, отвертки, по плечи в пыли конфигурим сервера, рабочие станции итп. Девопс - сначала в полуавтоматическом, затем в полностью автоматическом режиме конфигурим сервера, рабочие столы итп. Все физические соединения, настройка железа, протяжка проводов, замена железа итп лежит ниже девопса. Но зато на существующей железной инфраструктуре мы разворачиваем столько рабочих мест, серверов, сервисов, сколько надо для покрытия потребности. Не хватает железной инфраструктуры - заказываем еще..
ky0 Автор
То, что вы описали — это где-то начало века, если не раньше. Даже лет 10-15 назад широко распространён был тезис, что «нормальный админ два раза сделает руками, а на третий автоматизирует». Ну и мотки проводов, пыль — вы с монтажником СКС не путаете?
tlittle
Нет, не путаю. Монтажник СКС монтирует на момент строительства премиса. Потом в дело вступает админ. Хорошо, конечно, когда админ сможет отмазаться: "Пусть кабели/патч-корды здесь тянут монтажники, а я потом подключусь". Но нет, в реальности так не работает. Или не работало когда я был "админом". Понятия "девопс" тогда вообще не было :)
gecube
От компании зависело очень сильно. Условно - глобальная проводка (как Вы и заметили) - больше про подрядные организации, а починить розетку - про админа. Иногда админ сам тянул проводку с перфоратором, но вопрос кто в это время тогда обслуживал рабочие места и сервера )))
Source
То, что вы описываете, - это админ на предприятии, которое может быть вообще с IT не связано. А в статье речь идёт про админов, которые веб-серверами занимаются, у них физического доступа ни к дата-центру, ни к железу вообще нет. И даже 15 лет назад не было, но назывались они тогда просто админами.
zerotail
то что вы сейчас описали это недоадмин. у хорошего админа идеально всё начиная от кабель-менеджмента в серверной и заканчивая документация по автоматизированной инфраструктуре.
Что касается дево-псов то я боюсь большинство команий не знает кто это. Так как много раз звали на собесы где в вакансию девопс вкладывали всё начиная от заправки картриджей до разработки архитектуры приложения на AWS
ttys
Разработчик подразумевает аппаратно программный процесс. Программист к аппаратной части отношение не имеет.
А вообще это как и "отксерьте" и не важно что копир тошиба ????
Надо смирится и жить дальше.
Source
Ну это лишь одна из десятка интерпретаций, которая как и все остальные (которые пытаются описать хоть какую-то разницу между программистом и разработчиком) безумно далека от реальности. Или вы всерьёз думаете, что компания, ищущая PHP-разработчика, ожидает от него виртуозного владения паяльником?
Ndochp
Ну процесс то для "наукоблагозвучия" обозвали "ксерография", так что если копир и тошиба, все равно "ксерокопирует"