Comments 217
DevOps не персона, это больше про процессы ) и это важно понимать)
Но абсолютно согласен что на рынке много компаний которые этого не понимают, и в понимании некоторых это человек оркестр который закроет собой 3-5 ролей на проекте)
"Половина - не бывает большей или меньшей. Но, к сожалению, большая половина класса этого не понимает." (с)
По-моему это уже не про процессы, а тупо модное название для админов. Как раньше ввели в моду "разработчик" вместо "инженер-программист". По факту одно и то же, но разработчик звучит более хипстерски. С девопсами тоже самое.
Ну да. Если на вакансии дево-псов больше зарплаты я иду на дево-пса.
Я бы не стал утверждать так однозначно. Классический админ - это настройка системы вручную (в лучшем случае, в полуавтоматическом режиме). Т.е., красные глаза, моток проводов, отвертки, по плечи в пыли конфигурим сервера, рабочие станции итп. Девопс - сначала в полуавтоматическом, затем в полностью автоматическом режиме конфигурим сервера, рабочие столы итп. Все физические соединения, настройка железа, протяжка проводов, замена железа итп лежит ниже девопса. Но зато на существующей железной инфраструктуре мы разворачиваем столько рабочих мест, серверов, сервисов, сколько надо для покрытия потребности. Не хватает железной инфраструктуры - заказываем еще..
Нет, не путаю. Монтажник СКС монтирует на момент строительства премиса. Потом в дело вступает админ. Хорошо, конечно, когда админ сможет отмазаться: "Пусть кабели/патч-корды здесь тянут монтажники, а я потом подключусь". Но нет, в реальности так не работает. Или не работало когда я был "админом". Понятия "девопс" тогда вообще не было :)
Или не работало когда я был "админом"
От компании зависело очень сильно. Условно - глобальная проводка (как Вы и заметили) - больше про подрядные организации, а починить розетку - про админа. Иногда админ сам тянул проводку с перфоратором, но вопрос кто в это время тогда обслуживал рабочие места и сервера )))
Мы лет 15 назад почти всем отделом неделю тянули проводку (по расходу кабеля - около 65 км), а рабочие места обслуживал "эникей" (сервера никто не обслуживал - они работали самостоятельно в это время). Работодателю эт ообошлось неоправданно дорого, конечно, но сроки были настолько нереальные, что найти подрядчика просто не успели, вернее, изначально нанятый подрядчик (условный "ИП Медведев") зафакапил проект и слился, а объект открывать надо. Могли бы оставить "на хозяйстве" матёрого админа, но он не знал бы всех тонкостей обращения с зоопарком офисной техники, можно было оставить на хозяйстве местного старожила, числящегося к тому моменту начальником службы эксплуатации, но к нему стеснялись обращаться "молодые" сотрудники...
То, что вы описываете, - это админ на предприятии, которое может быть вообще с IT не связано. А в статье речь идёт про админов, которые веб-серверами занимаются, у них физического доступа ни к дата-центру, ни к железу вообще нет. И даже 15 лет назад не было, но назывались они тогда просто админами.
то что вы сейчас описали это недоадмин. у хорошего админа идеально всё начиная от кабель-менеджмента в серверной и заканчивая документация по автоматизированной инфраструктуре.
Что касается дево-псов то я боюсь большинство команий не знает кто это. Так как много раз звали на собесы где в вакансию девопс вкладывали всё начиная от заправки картриджей до разработки архитектуры приложения на AWS
Вручную. Шта? Дядь, ты последние 20 лет протусил в бункере, как в фильме Blast from the past?
Разработчик подразумевает аппаратно программный процесс. Программист к аппаратной части отношение не имеет.
А вообще это как и "отксерьте" и не важно что копир тошиба 😁
Надо смирится и жить дальше.
Разработчик подразумевает аппаратно программный процесс. Программист к аппаратной части отношение не имеет.
Ну это лишь одна из десятка интерпретаций, которая как и все остальные (которые пытаются описать хоть какую-то разницу между программистом и разработчиком) безумно далека от реальности. Или вы всерьёз думаете, что компания, ищущая PHP-разработчика, ожидает от него виртуозного владения паяльником?
Ну процесс то для "наукоблагозвучия" обозвали "ксерография", так что если копир и тошиба, все равно "ксерокопирует"
А вообще это как и «отксерьте» и не важно что копир тошиба 😁Всё бы ничего, но если так ошибается потенциальный работодатель, работы Вы не получите, даже если, на деле, идеально подходите под то, что требуется в данном случае. К сожалению, работодатели и кадровики, которые поинтересовались, как именно называется то, что им нужно, почему оно так называется и почему называть это более модным словом не есть правильно, никак нельзя назвать большинством.
Ща будет бамболейла, но девопс- админ и саппорт для обленившихся кодеров :))00
Ну а что, так и есть
для обленившихся кодеров
Которые хотят только непосредственно кодить
Которые хотят только непосредственно кодить
на что их собственно и нанимают
Так и админ как бы не должен заниматься поддержкой, он должен админить.
Ну так как бы настрой, чтобы работало всегда и не занимайся поддержкой ;)
Кодеры тоже дебажить не хотят.
Ну так как бы настрой, чтобы работало всегда и не занимайся поддержкой ;)Для этого есть эникей. А по-хорошему — обучение пользователей, чтобы сами могли выполнить инструкции админа по настройке почты и прочего.
Кодеры тоже дебажить не хотят.Поэтому отладочный вывод ещё на этапе разработки, доказательство алгоритмов и прочее: «ну так как бы настрой, чтобы работало всегда».
Вспомнилась пара цитат из рабочих совещаний:
Девопс - нянька для разработчика.
Программист и разработчик, это две больше разницы.
А можно пару тезисов про различие программиста и разработчика?
Заходят как-то два программиста и один javascript-разработчик в бар...
Программист программирует, а разработчик разрабатывает
Правильно.
Программист - программирует, т.е. от алгоритма на салфетке(в голове), до того, что в конце-концов получится, и как минимум , имеет представление, как и где(и сколько), оно будет работать. Разработчик - разрабатывает, как шахтёр в забое, отсюда и до вечера, не заморачиваясь архитектурой, железом, ОС, и тем, как, где(и сколько), оно будет работать.
Наверное, грубо, это даже можно выразить ещё и так: Программист может сам себе сделать ТЗ, руководствуясь знаниями и опытом, на основании бизнес-требований, а разработчик - нет, он работает по готовому ТЗ, которое ему сделал программист, который имеет представление, как, где и сколько, продукт будет работать, "отсюда и до вечера".
И ещё "грубее": Программист большу часть времени думает, а разработчик - кодит.
Вот такое моё ИМХО.
Интересно как остальные, но я понимаю эти два термина ровно наоборот. Программист - программирует, то есть пишет программу. Разработчик - разрабатывает ПО, то есть занимается и архитектурой, и программированием и всем остальным.
Фигня это всё. Есть понятие кодер для людей, которые по сути переносят алгоритм с "бумаги" в код. А программист и разработчик - это абсолютные синонимы.
Приведённые цитаты показывают, что автор той статьи слишком узко мыслит. Слышит "алгоритм" - думает "аллоцируй массив". Это даже читать смешно, не то что обсуждать. Алгоритм вполне может реализовывать бизнес-логику (которую естественно не он придумал), используя паттерны и базовые классы, существующие в проекте. По сути, кодеры - это обычные джуны, ну или как вы их называете Junior Developer'ы xD
Разрабо́тчик — специалист, занимающийся разработкой схем, механизмов, аппаратуры, программного обеспечения, сайтов и способный реализовать любой проект от стадии замысла до её реализации техническими средствами.
Как там у программиста с разработкой схем, механизмов, аппаратуры? Вообще, это действительно важное различие. Программист (классический программист) уточнил входные параметры и написал программу (на нужном языке программирования), которая выдала ожидаемый результат. Разработчик сделал так, чтобы нужный процесс заработал так, как указано в ТЗ. Добавить конвертацию входных/выходных параметров в нужный формат, задачи по запуску нужных процессов итд, итп.
Как там у программиста с разработкой схем, механизмов, аппаратуры?
Запятая в указанном Вами определении эквивалентна "ИЛИ". Если человек может полностью разработать программную систему, не вдаваясь в железную часть - он перестаёт быть разработчиком? Вряд ли
Тут гораздо важнее вторая часть фразы. "способный рализовать любой проект". Проблема в том, что очень редко в проекте требуется получить на вход простой X и выдать простой Y в одном и том же виде (в виде простой функции). Чаще приходится скрещивать ежа с ужом, добавлять различные инструменты/прослойки/прокладки. Классический программист заявляет: ребята, я под это не подписывается, моя среда не предусматривает такого (я встречал таких). Разработчик решает эти трудности тем или иным способом.
Любой проект - это оксюморон, сферический конь в вакууме. Это необходимость произвольного количества ресурсов и произвольного (=бесконечного) количества времени на реализацию проекта. К тому же, многие проекты не могут быть реализованы в одиночку. По крайней мере на практике. Слабо спроектировать ракету Ангара? Т.е., наверное, потенциально Вы можете (не сомневаюсь) это сделать, но потребуется, как я уже сказал бесконечное количество времени / ресурсов.
Если же зайти с другой стороны - посмотреть на реализованные проекты, то надо понимать, что многие проекты могли быть закрыты, потому что стали не нужны бизнесу (видел такое). Или оказались слишком дорогими. Или ещё что-то. Короче, такая трактовка определения оставляет слишком много свободы.
Классический программист заявляет: ребята, я под это не подписывается, моя среда не предусматривает такого (я встречал таких).
классический разработчик говорит "у меня на моей машине все работает"
Классический админ говорит "программа не работает, потому что разрабы наговнокодили, я разбираться не буду"
И так далее
Как раз нет. Любой проект - это не сферический конь в вакууме (у вас, кстати, проблема - вы считаете оксюморон и "сферического коня в вакууме" одним и тем же, хотя это очень разные понятия). Проект - это как раз запуск нужного программного кода в нужном окружении, с нужными условиями итп.
"У меня на моей машине все работает" - это не разработчик, это программист. Разработчик как раз и нужен для того, чтобы решить проблему в том числе разного окружения.
Касательно классического админа - да. Он часто ссылается на разрабов. Уход, в том числе, от этих ссылок делает его девопсом...
Проект - это как раз запуск нужного программного кода в нужном окружении, с нужными условиями итп.
Ух-ты, т.е. чел, умеющий скачать Chrome под свою ОС и запустить его, уже разработчик? Ясно-понятно)
Вам пытаются донести мысль, что для реализации любого проекта одного человека мало. Условно говоря, вот вы ведь разработчик?
Реализуйте, плиз, за выходные проект, который позволит любые игры под Windows запускать на GNU/Linux и на MacOS X, а то ребята из Wine не справляются. Столько человек столько лет что-то пишут, а никак не могут реализовать. Эх, видимо, ни одного разработчика среди них просто нет.
По мне так это все словоблудие. Разработчик просто более широкое понятие, так как разрабатывать можно не только ПО, но и, например, месторождения полезных ископаемых или прототип автомобиля. Но в IT-среде разработчик и программист - тождественные понятия
Таким макаром проктолог тоже в своём роде "разработчик" :)
p.s. шутка, конечно, но как говорится, в каждой шутке не только шутка
Ща будет бамболейла, но девопс- админ и саппорт для обленившихся кодеров :))00
Представьте ситуацию, когда ваш продукт состоит из двух десятков модулей, а список джобов в дженкинсе приближается к сотне, меняясь при этом почти каждый день. И чтобы протестировать какую-то разрабатываемую фичу - надо сначала развернуть стенд из как минимум половины этих модулей в амазоне в кастомной конфигурации. Сможет разработчик этой фичи сам правильно все подергать в дженкинсе, чтобы среда развернулась и накатились все тестовые данные? Как показывает практика - как минимум не с первого раза. Да еще и нужен человек, понимающий почему конкретно этот джоб в дженкинсе сломался и как его чинить. И в плане работ по проекту починка дженкинса почему то отсутствует, менеджер для разработчика эту задачу указать забыл...
Тут всё несколько глубже. DevOps - человек, растёт из того же места, что и модное заблуждене под названием SCRUM. В котором из ролей всего ничего Product Owner, Scrum Master и Scrum Team. И все равно, что в этот Scrum Team нужны: разработчики, тестировщики, бизнес-аналитики, дизайнер ...
К чему это я всё? А к тому что это классная абстракция-прослойка удобная для рубахи парня - менеджера. Недавно вычитал на просторах, как бедным менеджерам без технического образования и бэкграунда тяжело живётся разбираясь между всеми этими разношёрстными трудягами из-за кого не попадают сроки или упал прод. И мол вот она серебрянная пуля - а мы скажем, что нет между ними разницы и помогут нам тут SCRUM и DevOps. И сразу жизнь у менеджера стала сладкая, сразу понятно у кого перфоманс просел. И руководить сразу проще стало, а что SCRUM ведь про self-organized team. Так и появились мифы о Universal Soldier(aka Cross-functional Team) и DevOps - человек.
Лучшая ложь - это та, в которой есть примерно 15% правды.
. Так и появились мифы о Universal Soldier(aka Cross-functional Team)
это не миф. Кросс-функциональная команда - это попросту команда, которая укомплектована всеми ролями. Не обязательно универсальными солдатами. Т.е. какая-то специализация при любом раскладе будет. Но при этом команда полностью готова к разработке и поддержке своего продукта.
У T-shaped engineering оттуда же ноги растут.
А зачем менеджер самоорганизующейся команде? Там уже есть своё управление по идее.
Менеджер самоорганизующейся команде нужен в качестве прослойки для общения с остальными. Что бы команда занималась разработкой своей части продукта, а не тратила время на пинания окресных лопухов в поисках чего либо нужного.
Перевести таски с одного "языка" на другой - работа менеджера.
Найти кто отвечает за другой кусок проекта, от которого проблемы - работа менеджера.
Принять инфу о проблеме, оформить и передать команде - работа менеджера.
Пнуть условного Васю - и то работа менеджера, а не коллеги Пети.
Саморганизация убирает только микроменеджмент из рабочих обязанностей менеджера. Majesty, с менеджеров в качестве игрока, все равно остается.
Более того, в нормальных компаниях админ всегда и был саппортом для разработчиков. Чего бомбить-то, работа такая - кому-то всегда саппортишь, сам по себе ты особо не нужен.
Подпишусь под каждым словом автора. Особенно после того, как стал участвовать в собеседованиях со стороны нанимателя. Но как известно, фарш невозможно провернуть назад поэтому ситуация с неймингом профессии уже не изменится. Есть один несомненный плюс происходящего: "бывшие админы" стали получать внезапно настолько нормальные зарплаты, что некоторые разрабы стали переходить в девопсы. Мне кажется нужно спокойно делать свое дело и смириться с тем, что в целом в бизнесе хватает и более токсичной идиотии, чем ситуация с DevOps. HR как не понимали ни черта так и не будут понимать в большинстве своем. В ИТ как ломились все подряд, так и будут ломиться еще больше. Владельцы бизнесов как велись на маркетинговый буллшит про облака и что угодно еще, так и продолжат вестись на него. Значение имеет лишь несколько "простых" вещей: циферка на счете и возможность разрулить ситуации в той компании, где ты сейчас работаешь (в том числе повлиять на процесс найма и организации работы инженеров). А про то, чтобы повлиять на ИТ индустрию в таком ключе, забудьте, она настолько разрослась, что во многом всем правит хайп.
Хороший (действительно хороший) админ = девопс. Потому что хороший админ и раньше пользовался всеми доступными средствами автоматизации. У него была задача - настроить так, чтобы оно все работало самостоятельно без его участия месяцами, а в случае неисправности (непредвиденной ситуации) - починить все при минимальном участии админам в минимальные сроки. При переходе в девопса не меняется практически ничего, возможно, объемы обслуживаемых ресурсов и (не всегда) используемые инструменты (возможно, как раз в связи с пунктом выше).
Хороший (действительно хороший) админ = девопс. Потому что хороший админ и раньше пользовался всеми доступными средствами автоматизации
Вообще нет. Много админов пользовалось terraform ? А cloudformation ? А kubernetes тоже сможет настроить и продебажить в случае проблем. Например, я за 15 лет работы именно сисадмином вообще не касался этого. Ну вот просто не было необходимости.
А если глубоко копнуть облака, то там столько всего. И человек просто прочитавший офф доку - не сможет настроить сервис или выполнить интеграцию с другим
В лучшем случае - они запускали пару раз докер и пару раз ансибл с парой тасков. Ничего не имею против сисадминов, раньше и сам им был, но сравнивать их некоректно. У них просто разные направления
много ли девопс-инженеров сможет продебажить кубернетис?
Сложный вопрос. Вот буквально на днях у коллеги была странная проблема, которая решилась только переустановкой кластера в DigitalOcean. Что-то там сломалось в недрах, симптоматика ясна, но т.к. решение managed, то починить в нем ничего нельзя, саппорт провайдера молчит как Рыба об лёд (ну, и время ответа там составляет часы, иначе что-то типа премиум пакета поддержки покупайте).
Главное, что бизнес проблема решена. Все happy. Но осадочек остался
Меня, если честно, больше интересует вопрос — много ли девопс-инженеров сможет продебажить кубернетис?
Не каждый, но те кто смогут, выставят вам такой ценник - что в большинстве случаев фирма скажет, что лучше мы наймем 2-3х админов, которые если что просто переустановят с нуля ))
Ну и мой посыл был в том, что с k8s надо много работать и желательно не на локальной машине в песочнице. И вот откуда у сисадмина возьмется такой опыт. В принципе это относится и к terraform/облакам/etc
Учитывая основную задачу девопса - скрещивать ежа с ужом, то стадия яйца для такого рода профессий - это упорный ленивый человек с пытливым умом (профильное образование будет плюсом если там учился, а не оценки получал) с опытом обслуживания гетерогенных распределённых систем в пару лет в роли подавана. Личинка это наличие у такого человека ещё пары лет опыта на ниве автоматизации,интеграции, и поддержки упомянутых систем. Идеально - устроится работать в предприятие, которое начинает масштабироваться с непредусмотренной для этого архитектурой и бизнес-процессами.
какая-то стадия личинки, согласитесь?
потому что эта стадия называется "linux администратор" в компаниях типа веб-хостинга. Так же как и с насекомыми, когда личинка очень не похожа на взрослую особь и проходит стадию метаморфозы.
Кубернетес точно так же как и любой программный продукт требует администрирования. Так что, да, раньше был администратор UNIX, теперь администратор кубернетес )))) Другой вопрос, что это сразу обычно называют девопсом и заходят с козырей. Но если подход остался тем же, что и тогда.... ну какой это девопс.
PS. Я из тех админов-ретроградов. Контейнеры начал ковырять в конце прошлого года только — жизнь заставила.
Ладно HR'ы могут ерунду нести.
Но вот же AWS у которого аж сертификация есть на DevOps Engineer: https://aws.amazon.com/ru/certification/
Неужели они тоже не в курсе того что значит DevOps?
Или может с приходом облаков роль чистого админа снизилась и отчасти перешла облачным провайдерам и с точки зрения критичности для бизнеса на первый план вышли задачи на стыке разработки и администрирования и это как раз тот самый DevOps?
В том же AWS систему на миллионы пользователей может обслуживать буквально 3-4 человека. А для бизнес не всегда важно "дешевле", может быть намного важнее "гарантированный уровень качества" и снижение рисков "завтра админ выбыл из команды и всё сломалось"
Чем плохо админить офисные компы за зарплату девопса? :)
Но обычно что-то типа такого — не сильно большая контора, но деньги у людей нормальные есть. Нужен «специалист общей практики», как тут ниже написали. Сеть, юзеры, видеонаблюдение, битрикс…
«Я слышал, что в Москве админам платят 25 тысяч, потому я готов тебе платить 15. По рукам? Куда-куда я пошёл?»
К сожалению, реалии показывают, что бизнес в большинстве случаев ориентируется на "дешевле прямо сейчас" и есть подозрение, что в чем-то они правы (хотя на этом месте мой внутренний инженер орет благим матом). НЕ в последнюю очередь на это влияют финтопы, мнение которых, как известно, всегда весомее для бизнеса, чем мнение CTO, например.
Думаю то что вы называете "дешевле прямо сейчас" бизнес называет "эффективное использование ресурсов", "снижение рисков" и "эластичность ресурсов" при гарантированном уровне сервиса.
Без облака невозможно на время своей акции распродажи нарастить в 5 раз пропускную способность интернет магазина на 3 дня.
Без серверлесс невозможно дешево обеспечить какую-то ресурсоёмкую функцию, которая вам нужна раз в неделю на 15 минут, понадобится самому как-то координировать нагрузку.
Без SaaS вы не получите качественно организованный сервис на малый объем потребностей.
Что потребуется сделать для того чтобы организовать самому какой-нибудь аналог CDN или AWS Global Accelerator и представить страшно )
В каком-то смысле это всё про "дешевле" и про "прямо сейчас", но что в этом плохого?
Мне кажется, вы - инженер) Т.к. описали исключительно верные случаи применения озвученных вами технологий. Проблема в том, что бизнес часто применяет инструменты неправильно, запихивая в облака вообще все подряд, например. Почему так происходит, думаю всем понятно.
Возможно потому что не все компании догадываются или могут себе позволить привлекать специалистов уровня AWS Certified Solutions Architect – Professional и AWS Certified DevOps Engineer – Professional, которые понимают возможные варианты решения тех или иных задач и плюсы/минусы каждого, включая стоимость решения.
В итоге в облака едет что попало и как попало.
Это тот же самый Гугл, который выводит SRE инженеров и говорит, что именно SRE имплементируют (реализуют) девопс? Ну, ок
Да если и 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
А в чем проблема с DevOps Engineer? если хотите противопоставить - они же не делают курс Admin Engineer - у них вполне себе есть SysOps Administrator курс сертификации для админов
Автор утверждает, что не бывает "девопс-инженер", это методология.
А у меня нет проблем с DevOps Engineer, я по нему к сертификации готовлюсь сейчас.
Автор пытается понять, чем в лучшую сторону девопс-инженер отличается от обычного, нормального админа, не застрявшего в прошлом веке и знакомого с облаками, CI/CD, контейнеризацией приложений и т. д. Чем они обычно отличаются в худшую — я перечислил ближе к концу статьи :)
Тогда мои извинения, я это видимо не так понял тут:
Умом-то я, разумеется, понимал всех обратившихся ко мне в личку людей, автоматически трансформируя фразу "нужен девопс" в "процессы в нашей команде предполагают тесное взаимодействие между отделами, и сейчас мы ищем человека, который взял бы на себя часть работы по эксплуатации"
····················
Каждый должен заниматься своим делом
Если такой инженер бывает, то зачем чего-то трансформировать? Почему не может быть его "своим делом" работать на стыке между админами и разработкой?
Если такой инженер бывает, то зачем чего-то трансформировать? Почему не может быть его «своим делом» работать на стыке между админами и разработкой?
В том-то и дело, что если, в соответствии с обсуждаемым нами примером, в компании уже есть девопс (методология, предполагающая тесное взаимодействие) и разработка с эксплуатацией его уже придерживается — мне не очень понятно, откуда может взяться нужда в ещё каких-то людях, которые будут заниматься исключительно задачами «на стыке». Зачем они в такой ситуации? Любая, простите за некрасивое слово, «прослойка» — будет, имхо, заведомо уступать в эффективности.
Моё недоумение вызвала тяга рекрутёров найти именно такого вот, который сконцентрирован «на стыке», но на этом его компетенции заканчиваются.
Вы так пишете, как будто этот "стык" нынче толщиной с волос.
На мой же взгляд с распространинием концепии IaC + инструментов контейнеризации + развитием CI/CD там всё вообще размылось и этот "стык" может охватывать до 25% всей разработки.
Вот допустим мы настраиваем пайплайн так, что на каждый MR в репозитории кода будет поднят свой контейнер в AWS Fargate с версией системы для ревью и создана отдельная БД с тестовыми данными - это что по вашему? Разработка? Администрирование?
Ну допустим, а если там не просто контейнер + бд, а уже целый набор всякого добра, типа NoSQL serverless базы, s3-хранилища, sns-топики для доставки уведомлений об изменениях + несколько serverless-лямбд и это под api gateway всё и load balancer'ом, и это достаточно часто меняется - это всё еще администирование или уже куда-то в разработку начинает просачиваться?
Думаю, что озвученную вами задачу я начал решать бы в обнимку с разработчиком (ну или периодически бегая к нему за уточнениями). Скорее всего, его помощь потребовалась бы только в самом начале — чтобы в целом понять, как оно работает.
Но это не отменяет того факта, что у нас есть человек, хорошо разбирающийся в разработке и человек, хорошо разбирающийся в эксплуатации. Откуда у сферического девопс-инженера без бэкграунда возьмётся знание всего этого (помимо обучающих лаб GCP/AWS/etc) — под вопросом.
Откуда у сферического девопс-инженера без бэкграунда возьмётся знание всего этого (помимо обучающих лаб GCP/AWS/etc) — под вопросом.
10+ лет в индустрии? Причём желательно ещё и чтоб этот человек хоть немного интересовался разработкой? Хотя бы на минимальном уровне? У нас был пример, когда прям админы-админы автоматизировали свою работу на Python и даже для техподдержки целый мини портал для управления ssl сертификатами набабахали
Ну 10+ прям необязательно. Для начинающего девопса на мой взгляд 1-2+ вполне уже норм будет, если человек постоянно новое осваивал и практический опыт имеет в эти 1-2 года.
3-5+ это уже очень хороший уровень можно наработать, практически на передний край выйти по уровню знаний.
Другое дело, что некоторым стаж не помогает. Не так давно собеседовал человека с опытом 25+ лет, он был ведущим разработчиком, руководил командой разработки, и он не понимает что такое транзакции в БД.
Автор пытается понять, чем в лучшую сторону девопс-инженер отличается от обычного, нормального админа, не застрявшего в прошлом веке
Возможно тем, что девопс, что называется, проактивен? Т.е. это не тот случай, когда его нужно просить что-то сделать ("сначала создай мне задачу в Jira, и согласуй ее с моим начальником"), а наоборот - он сам предлагает что-то поменять (узнает у разрабов какие сервисы и как мониторить, настроит заббикс, расскажет об этом специалистам поддержки, ...).
Или вы считаете что админы всегда настроены улучшать процессы и технологии даже если их никто не просит об этом?
вы считаете что админы всегда настроены улучшать процессы и технологии даже если их никто не просит об этом?
Нормальный админ ленив не потому, что ничего не хочет делать, а потому что пытается сократить работу до минимума. Если ни у кого нет запроса на изменения, то могу напомнить про преждевременные оптимизации.
Нормальный конечно проактивен. Всю жизнь так и было. Приходили и говорили "вот у вас тут жопа растёт, пока ещё пасмурно, но скоро станет такой мохнатой, что Солнце закроет". Потому что его мониторинг показывал, что потребление памяти скоро будет уже ни в какие ворота (даже для облака, просто дорого станет), так что он вежливо интересовался "эй, на баркасе, у вас там всё нормально? Вот этот процесс поджирать стал". Бывает, конечно, что тимлид бэка отвечал что-то вроде "всё ок, бизнес-требования изменились, с финдиректором согласовано, жгите деньги". Но зачастую разработчики издавали слабый писк: "ой, и правда, сорян, протупили, не нужны там такие SELECT * FROM blablabla; сейчас исправим на SELECT id, title FROM blablabla LIMIT 10;"
А не делающий то что вы в своем комментарии описали, это не администратор, а много раз упомянутый в комментариях к этому посту эникейщик, который что-то там как-то настроил и всем в последнюю пятницу июля рассказываший, что он "тоже админ".
Ничем не отличается. Но сегодня это так называется. Такова жизнь. Может, они и неправы в теории, и ИМХО большинство неправы в том, что всовывают в продакшен вещи, которые появились полгода назад. С другой стороны - нам сейчас платят больше чем разработчикам, так что жаловаться грех.
Не вижу смысла идти против течения.
(мне 58 лет, DevOps Freelancer)
В лучшую и худшую для чего? Эти понятия никогда не существуют в вакууме, они всегда относительно какой то ситуации иди задачи.
Нам нужен офтальмолог и чтобы немножко гинеколог...
Про корочки проктолога еще забыли.
Да не, скорее просто фельдшер. Если у вас не медицинское учреждение, то вам не нужен ни гинеколог, ни офтальмолог - вам нужен штатный медик общей практики, который способен сделать прививку, оказать общемедицинскую помощь, в случаях заболеваний отдельных органов примерно поставить диагноз и назначить симптоматическое лечение типа "не смотрите на свет 10 дней и засуньте туда марлю с порошком из аптечки", составить журнал болезни и, если не помогло, сдать пациента врачам при первой возможности, сохранив его живым и не слишком нездоровым. Врач общей практики.
То же и с айтишником общей практики. Если у вас не айти-компания, вам нужен эдакий фиксик-помощник общей практики, а не специалист по разработке ПО.
Согласен на 150% Только я бы сказал терапевт+офтальмолог+гинеколог в небольших районных больницах такое к тому-же бывает! Только если внезапно срочно нужно сделать операцию на глазах она делается ... сами знаете через что!
Проблема знакомая и мне кажется состоит из двух частей:
Для generic HR - довольно существенное пересечение кейвордов, и не важно что при таком подходе senior admin окажется при таком подходе junior devops'ом (и наоборот).
Девопсы бывают разные, но использование облаков в построении инфраструктуры во многом снижает требования к фундаментальным знаниям (там нужнее условные курсы AWS чем Таненбаум). Вот собственно поэтому и снижается роль "эксплуатации" в процессах и знания у людей несколько специфичны и вообще из другой оперы.
p.s. Я то вообще хадупсы с etl'ями кручу по финтехам, и то постоянно пытаются вакансии девопсов подсунуть и искренне удивляются когда отвечаю им что это не совсем мой профиль)
Определения позиции DevOps как человека конечно не существует. Можно назвать его инженером практик DevOps. Но практический эффект HR фокусов с именованием позиций таков, что если уж рынок начал предлагать такие деньги за то чтобы выполнять функции того же админа у которого в CV записаны акутуальные куберенетесы, прометеусы и т.д, то надо этим пользоваться. Как сказали в одном из профильных чатов: "Больше всех выиграет та компания, которая поймет, что можно просто брать качественных админов вместо девопсов. Немного боевого опыта и новых технологий и полноценный девопс готов."
Плохие рекрутеры попадались или сама компания не понимает кто им нужен, видимо. Потому что у вакансии DevOps есть достаточно четкий перечень требуемых навыков и опыта работы с технологиями и инструментами. И как человек непосредственно учавствующий в наеме DevOps специалистов, могу сказать, что есть обратной сторона того, что озвучил автор поста. Приходят админы с большим опытом на вакансию (опомнившись после условно 8 лет существования практики DevOps, что это востребованно и там платят хорошие деньги), они сами идут туда, полагая, что их "мощного бэкграунда" в виде понимание принципов работы сетей и линуксов и знания базовых инструментов типа ansible и terraform (в лучшем случае), достаточно чтобы называть себя DevOps и получать как DevOps. Нет, это не так). Этого не достаточно. И не достаточно знания перла или питона).
Говорить что девопс это философия, методология - я не буду. Но на практике, весь опыт приобретенный таким матерым классическим админом, который спит с циской в обнимку и знает все интимные подробности ее консольной конфигурации, в перерывах между работой читает системные логи и дамп трафика в wireshark, с закрытыми глазами собирает блейд за 30 секунд и всё такое прочее - он не нужен. Достаточно вменяемых базовых знаний по сетям и линуксам. Этого будет за глаза для 99% **задач бизнеса**. Им не нужны такие знания, потому что уровень абстракции совсем другой. Намного важнее действительно хорошо влаедть практиками по организации CI/CD пайплайнов, по умению приготовления кубов, обвязки для создания обсервабилити и мониторинга и хороших навыков траблшутинга, понимания как правильно выстраивать архитектуру микросервисов, приготовления правильного алертинга, знание облачных платформ и широкого перечня инструментов вокруг всего этого.
А еще админы, в своем подавляющем большинстве, чаще всего, действительно такие как описаны в посту. Мое мнение вряд ли можно назвать предвзятым, я сам проработал лет 10 системным администратором Linux. Я сужу по многим знакомым с прошлых работ поддерживая связь, которые так и остались в этой сфере, сужу по тем кто приходит спустя годы ко мне на собеседования на вакансию DevOps. Везде есть исключения, но мой опыт говорит о неповоротливости, негибкости, отсутствии желания осваивать большое количество сложных инструментов, о закостенелости взглядов и суждений.
Это альтернативная точка зрения) не претендую на ее однозначную истинность. Но мой опыт работы в сфере за долгие годы каждый раз подтверждается. Намного разумней будет взять молодого джуна с горящими глазами, решившего идти по стопам девопса, чем брать таких вот админов, который тебе среди ночи протараторит без ошибок строение заголовка TCP пакета побайтно.
Ну а проблема с тем, что рекрутеры приходят сами к админам и не понимают, кто же такой DevOps - это и косяк руководства, и сильная нехватка кадров на рынке, что приходится заглядывать в смежные области, и отсутствие нужной квалификации для понимания того кто нужен и погоня за модными тенденциями без осознания необходимости и пр. и пр.
опыт говорит о неповоротливости, негибкости, отсутствии желания осваивать большое количество сложных инструментов, о закостенелости взглядов и суждений.
Сужу по себе — и согласен. Тут и лень, и принцип «работает — не трожь», и привычка — если железку я вижу и могу залезть в неё с отвёрткой или на своём почтовике я могу любые свистелки прикрутить, то в облачном сервисе — только то, что владелец разрешил.
Ну и, само собой, место работы сказывается и обязанности вообще. Одно — когда ты в айтишной конторе работаешь и другое — когда на производстве, где приоритеты совсем другие.
Вон, сейчас задача — древнюю конструкцию на информиксе прикрутить к 1С. При этом сделать так, чтобы «всё само», потому что нажать кнопочку импорта юзеру тяжко. Облака тут не спасут…
Вон выше написал, что до контейнеров только в конце года добрался — да и то не сильно по своей воле, жизнь заставила.
Согласен. DevOps - это не админ с бэкграундом, а специалист, разбирающийся в современных инструментах. Это и облака, и системы поставки конфигурации среды. При этом, девопсу достаточно знать администрирование поверхностно. Вообще, весь пост выглядит красиво, за исключением того, что, действительно, бизнесу сейчас не нужна оптимизация среды исполнения и сети. У большинства хостеров есть платные услуги администрирования. Железо стоит дешевле, чем время сисадмина. Вполне понятно, что человека это закусило: как же так, столько лет опыта, а сейчас он мало кому нужен только потому, что сейчас yaml developer получает в два-три раза больше него самого. Что я могу сказать: это рынок. И изучать актуальные технологии сейчас необходимо. Не исключено, что и лет через 10-20 программисты станут вымирающей профессией, а появятся какие-нибудь "инстансеры", умеющие работать с системами, самостоятельно создающими код.
DevOps - это не админ с бэкграундом, а специалист, разбирающийся в современных инструментах. Это и облака, и системы поставки конфигурации среды. При этом, девопсу достаточно знать администрирование поверхностно
Но при этом, если у специалиста есть бекграунд сисадминства, то как правило, получается более технически грамотный devops
Да, и я работал с такими специалистами. В то же время, хороших админов, которые неделями не могут разобраться в особенностях деплоймента кода, я тоже видел. И здесь вопрос возвращается к пресловутому уровню абстракции: одно дело уметь поднять и настроить сеть, а другое - знать особенности готового инструмента и его конфиг с командами. У чистых сисадминов необходимость разбираться в устройстве микросервисов, может вызывать отторжение. А когда руководство решает вынести в облака всю инфраструктуру, зачастую складывается ситуация, когда ручками уже ничего и не надо настраивать. Поэтому, компании ищут девопсов, а не администраторов. Когда же у компании есть потребность в ручной настройке серверов и сети, нужен админ.
Намного важнее действительно хорошо влаедть практиками по организации CI/CD пайплайнов, по умению приготовления кубов, обвязки для создания обсервабилити и мониторинга и хороших навыков траблшутинга, понимания как правильно выстраивать архитектуру микросервисов, приготовления правильного алертинга, знание облачных платформ и широкого перечня инструментов вокруг всего этого.
Согласен. Но, как и написал топикстартер, хороший сисадмин (который инженер, а не аникейщик) это умел и делал и до переименования.
А так - я вот старый (58 лет), и по-прежнему с бородой, и даже свитер ношу - но переименовался и очень доволен. (серьезно говоря, я больше доволен что стал фрилансером, но у меня эти две модификации совпали)
Я почти согласен с вами. Но есть спорный момент =).
То что вы описываете это больше похоже на закостенелось. С возрастом у многих начинает проявляться. У некоторых довольно рано почему-то. Это не характеристика админов - это характеристика старения людей в целом.
Тоже покажу на личном примере =). Несмотря на опыт, меня Iac со всеми его проявлениями привел в восторг еще до появления термина DevOps. В одной из контор пытался внедрить puppet с хранением конфигураций отдельно в mercurial. Идея с хранением выросла из практик моего превого места работы ( @merlin-vrn не даст соврать - там конфиги и скрипты хранились в svn, когда это еще не было мейнстримом, так сказать). Был непонят, т.к. зачем писать манифесты полдня, если можно вот сейчас зайти поправить конфиг и забыть (и не вспомнить, когда придется заново настраивать) =). Но мое время все же пришло ).
Я понимаю почему многие админы не умеют облака и кубернетис - в их организационной стуктуре оно в целом не сильно нужно. Однако packer, terraform/vagrant, ansible и gitlab сильно упрощают работу, если часто надо разворачивать новые сервисы или восстанавливать старые. А ELK и Graphana еще и красоты добавляют =). Эти инструменты уже стандарт для современного админа.
Это не значит, что админу не нужно знать все эти, скажем честно, уже некоторое время назад ставшими стандартами для индустрии технологии. Просто применять их в каждом случае совершенно необязательно.
Так о чем и речь, что для нормального классического админа все эти перечисленные штуки - просто еще один молоток, который он за свою карьеру выучит. И сколько он их выучивал уже, и забыли. И это забудут и новое придет.
Это. Просто. Очередной. Молоток. Сколько их было и сколько их еще будет.
Ну просто в 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'нутым названием.
А дело ещё в том, что надо было ещё маленькими в зародыше давить меняющих картриджи в бухгалтерии эникейщиков (IT technician), которые с каких-то щей всю дорогу называли себя "администраторами". Естественно, однажды наступил момент, когда настоящим админам окончательно надоело ассоциироваться с этим шлаком (кому "обидно", а кому попросту "стыдно"), а тут еще очень кстати какое-то новое название придумали и все туда побежали :)
Ну а дальше, это уже удел компании — понять who is who.
Третий борется с проблемами производительности с помощью увеличения количества ядер и памяти, выданных виртуалке.
Часто это единственно верный способ. И в большинстве случаев бизнес не даст вам неделю-другую на дебаг. Так что я не был бы так категоричен
Но согласитесь, это же странно и вызывает вопросы к джава-разрабам? Кто они - java software engineers, которые должны ориентироваться в контексте задачи и, помимо составления алгоритмов ещё знать примерно, как работает jvm или это code monkey, которые git commit && git push и отстаньте от меня? Если первое, то, наверное, справедливо, что стрелочка поворачивается и в другую сторону?
Они же не могут заранее предугадать, в каких условиях будет работать их детище. Где-то база находится на том же сервере и ничем другим не нагружена — можно забить на пинг до неё и настройки пула коннектов, а где-то до неё нужно долго и печально лезть через 100-мегабитный линк. Где-то на ПО микроскопическая нагрузка, а где-то наоборот лютый rps.
Можно, конечно, в каждом случаё дёргать разработчиков — но, имхо, специалисты эксплуатации для того и нужны, чтобы разбираться в подобных вещах. Я знаю кучу прекрасных кодеров, которые примерно ни в зуб ногой относительно того, как настраивается вакуум и bgwriter в СУБД, сеть, как работает oom-killer в линуксе и т. д. И слава богу — потому что это не их стезя, пусть оставят подобные вещи специально обученным людям. Например, мне :)
Нет, минуточку — при чём тут разрабы-то вообще? Они к проду могут вообще доступа не иметь. Их дело — закодить без ошибок, выдать рекомендации по ресурсам, рантайм-опциям, не знаю, докер-конфиг для сборки окружения там…
А вы предлагаете девопс инженеру дебажить джава приложение на проде. Делать профилирование и выдавать разработчикам рекомендации по тюнингу JAVA_OPTIONS ?
Я знаю кучу прекрасных кодеров, которые примерно ни в зуб ногой относительно того, как настраивается вакуум и bgwriter в СУБД, сеть, как работает oom-killer в линуксе
Для этого есть DBA/сетевики/админы. Как правило, это не задачи разработчиков
Вполне возможно, что дело действительно в каком-то узком месте в коде, но чтобы перейти к этому предположению, нужно исключить более банальные варианты — недостаток выданной процессу памяти, фигово затюненный сетевой стек ОС и т. п.
И да, я считаю, что админ должен как минимум покурить графики мониторинга, продиагностировать причины этих тупняков и попытаться с ними справиться самостоятельно.
Мониторинг вам показал, что ваше java приложение потребляет слишком много CPU/RAM/HDD. Что дальше будете делать ?
сколько можно переливать из пустого в порожне одну и туже тему - не можешь бороться так возглавь и будет счастье:)
Админы нужны и будут нужны. Только нужно эволюционировать.
Когда-то можно было мечтать об автоматизированном создании виртуалок, автонастройке софта и либо ваять свои километры скриптов чтобы как-то облегчить работу. Сейчас инструментария валом просто. Достаточно скачать приложение, изучить несложный синтаксис и можно увеличить свою производительность в разы.
DevOps-ы в разработке живут. А остальным конторам ведь тоже надо инфраструктуру админить.
Пойдем не совсем по порядку =)
Тема ЦОД vs локальные железки холиварная. Предлагаю не заглядывать в эту бездну. Эти два варианта существуют, т.к. есть условия где один из вариантов будет лучшим выбором чем другой. А можно еще и миксовать.
Почему админ не может пользоваться ansible и terraform? Удобные инструменты для облегчения рутины админа.
Не прометеусом единым. Можно ведь использовать zabbix и писать не экспортеры, а userparameter-ы и скрипты под них =). Да и под прометея есть push-gateway, кстати. В мониториге больше важны правильные метрики, а не инструмент. Инструментов много и можно выбрать по вкусам и целесообразности.
Кубернетис за рамками разработки и веб-сервисов не очень сильно распространен. Не везде его использование целесообразно.
Админить инфраструктуру значит админить инфраструктуру. Где-то это 20 компьютеров, файлопомойка и мини-атс, а где-то распределенная сеть филиалов с отказоустойчивостью и резервированием.
В примере я упомянул также и распределенную сеть филиалов некоего предприятия. Попробуйте представить что там по две стойки хотя бы в 3-4 филиалах, всего филиалов 140.
Предлагаю этот спор далее не продолжать. Предвзятое отношение не располагает к продуктивной беседе.
remote hands на местах? Потому что ездить одному человеку или даже бригаде по 140 филиалам, да еще и в разных городах - попросту нереально
Именно так. Но это, в данном случае, непринципиально. Товарищ пытается доказать, что админы ненужны и вымрут, т.к. нечего администрировать =). Я просто привел контрпример.
ну, это не совсем админы. Для "поменять диск в сервере" или "воткнуть патчкорд в сетевку" достаточно инженера техпода или какого-нибудь инжира из подрядной конторы. Для "заменить память в сервере" потенциально еще может приехать сертифицированный инженер из вендора, но это точно не для всех компаний... потому что там денег за сервис изначально заплачено прилично... По-всякому бывает
Эм... мы друг друга не очень понимаем похоже. Эникейщики на местах не отменяют необходимость админа или даже бригады админов для этого всего зоопарка. И непонятно откуда вы взяли свои примеры. Я их не приводил.
Даже если нет штатного админа, то есть из аутсорсерской конторы или приходящий, т.к. все равно требуется человек, с профильными знаниями, принимающий решения.
мне кажется, но слово администратор вообще используется в неправильном контексте. Вы абсолютно правы, что нужен некий чувак, который со стороны заказчика будет контролировать все эти бригады и все такое. Но это запросто может быть менеджер (не в плане как "менежер по продажам"), а не технический специалист. Да, технические познания нужны, чтобы исполнители не водили вокруг нос и делали то, что надо. Но тем не менее. А администратор - это чувак, который держит все в порядке, на самом деле.
Даже если нет штатного админа, то есть из аутсорсерской конторы или приходящий, т.к. все равно требуется человек, с профильными знаниями, принимающий решения.
да, но это может быть не "администратор" в классическом его смысле. Или может попробовать подискутировать на тему является ли эникейщик администратором )))
нет, есть еще регуляторка.
Банки, например.
Крупный бизнес типа Газпрома, Х5, Аэрофлота.
Что еще захочет свой почтовик?
В остальном согласен - многие используют облачные сервисы, в частности, зарубежом, но там нет "происков внешних врагов" и необходимости строить свою критическую инфраструктуру
Но в таком предприятии одним сервачком с сендмейлом уже не отделаешься.
да, но в другом ключе - потребуется еще среда виртуализации, VDI, стопицот всяких странных средств, PowerBI, Tableau, 1C, SAP и прочее
Там нужен лютый эксперт именно по почте.
ну, не лютый, но эксперт или специалист. Возможно, который будет шериться с другими задачами (например, настройкой слак, зум и прочих средств коммуникаций)
Один пример. Кейс более чем стандартный.
Итак.... Две сети филиалов магазинов одинакового профиля.
Первая сеть: в каждом магазине своя БД склада и настроена синхронизация с головным филиалом. Продавцы работают всегда с локальной версией и иногда запрашивают остатки у других филиалов.
Вторая сеть: БД по складам одна в ЦОД-е (даже в нескольких) и все рабочие места на тонких клиентах.
А теперь ситуация: экскаватор докопался до коммутационного колодца и порвал оптику идущую в ТЦ. Какой магазин продолжит работать и зарабатывать денежку?
К трактору прикапываться не надо =). У отвала интернета может быть много причин. Вплоть до того, что просто не оплатили.
Про почтовый сервер не понял. Какая-то очень мелкая проблема взята и очень древний софт для примера. Вам нужно освежить знания. Давно уже не нужен (а когда-то был нужен? о_О) отдельный специалист по электронной почте и даже переписывать ничего не надо =).
Толщина канала для терминалов по числу касс и всей БД с остатками товаров слегка разная. можно под столом и резервные терминалы с симками держать. Или у своих же курьеров отобрать. А чеки с кассы через месяц слить, когда инет починят.
Я могу ошибаться насчет нынешних платежных систем, но еще лет 5 назад была возможность оффлайн-оплаты с автоматической или полуавтоматической выгрузкой данных в банк.
Насчет налички у вас опять странная выборка, как и с облаками. С 40-50% еще можно согласиться. Но не 90. Да и сколько из этих 40-50% поленятся сходить до банкомата?
Насчет налички у вас опять странная выборка, как и с облаками. С 40-50% еще можно согласиться. Но не 90. Да и сколько из этих 40-50% поленятся сходить до банкомата?
Зависит от страны. В России, с тех пор как бабушкам принудительно выдали пластик для пенсий, наличкой платят намного реже. Не 90% конечно, но и далеко не 40-50%, как раньше.
С походом в банкомат ситуация получается аналогичная. Если ты торгуешь не уникальным товаром, то люди банально уйдут к конкурентам, который, зачастую, находится ближе банкомата. Аналогично и в ситуации, когда товар уникальный, но не так уж и особо нужным от-прям-щаз.
Раньше когда у меня была проблема с окружением или я понимал что не смогу настроить нормально прод (ну, или что чаще, мне неохота было это делать), я шёл к админу. Сейчас, в такой же ситуации я иду к девопсу. Да вместо работы с конфигами, пакетами и bash скриптиками теперь у меня докер, конфиги и другие скриптики, а на проде вообще часто происходит магическая дичь, глубоких деталей которой мало кто понимает, и я подозреваю что где то в глубинах aws уже зародился сильный ИИ и он там всем управляет, заодно периодически подкидывая ещё один уровень абстракции между собой и тем с чем работает человек чтобы отгородить себя и код от человеческих рук разной кривизны. Но суть та же, админ, девопс, человек решающий задачи окружения, платформы на которой будет выполняется софт, мониторинга, выяснения и решения проблем со всем этим, в идеале ускорением и повышением стабильности, и автоматизации. И не важно, пишет ли он скрипты на баше или конфиги в ямле, собирает серверы, компилит из исходников, или творит магию поднимая готовые площадки в облаке парой кликов (предварительно хорошо разобравшись где и что поднимать и как оптимальное для задачи настроить) , выводит top на отдельный монитор, или настраивает графики мониторинга в графане. главное чтобы разбирался. Разбирался на том уровне на котором нужно для проекта. Я 5 лет привыкал называть админов девопсами, только привык, пожалуйста, не заставляйте меня привыкать обратно.
Раньше у вас был админ, который понимал, что происходит начиная от схемы электропитания сервера, заканчивая версией ядра и его модулей — сейчас девопс пушит конфиги в облако и всё работает само. Понимает ли он, что происходит там «унутре»? Надеюсь, что да — но не уверен. Мой опыт показывает, что вся магия обычно заканчивается, как только что-то перестаёт работать, как предполагается — и если рестартом контейнера и выдачей ресурсов это не решается, наступают тяжёлые деньки.
Уровни абстракции и знания необходимые для проекта. Знания что внутри это конечно хорошо, если есть основные, если нет то толку. Вас никто не пустит с паяльником в дата центр, даже если вы знаете что и как чинить и отлично разбираетесь в железе. Там есть свои люди которые разбираются. Вас никто не пустит на нижний уровень aws, даже если вы поняли где там проблема, а даже если пустят, оно наверняка сложнее чем просто машина с *nix. Если вы хорошо знаете что под капотом вам это возможно поможет, раз в год, чуть-чуть, в диагностике. Но если вы не знаете как работать на нужном уровне (а не ниже) то вы просто не сможете делать нужные задачи. Всего знать не возможно, все упирается во время. Но хуже другое, все упирается в мышление, в фокусы, в подходы к решению. И вот они вообще несовместимы. Они просто конфликтуют друг с другом. Всегда какой то уровень основной а остальные дополнительные знания и навыки. И да, если это никак не мешает работе проекта, то проще и быстрее наверное перезапустить контейнер, почему нет?
@ky0 апплодирую вам! Факт в том, что так с любыми должностями в ИТ. Людей не хватает, HR гребут все, что плохо лежит ) Без разбора. Поэтому я за то, чтобы все-таки рядом с HR был кто-то из руководства команды отдела ИТ.
Devops is a mask I put on to earn more
Ха-ха-ха - вот что я вижу справа от статьи -
-Извините, когда мне позвонили из вашей фирмы, мне сказали, что у вас есть вакансия девопса и что вы возьмете меня без собеседования.
-Да, и что? -На моем рабочем месте лежит фурсьют и бикини...
-Ну, вы же будете работать девопсом.
-Извините, на какую букву вы ударение поставили?
Такс, даже, если предположить, что понятие девопс это маркетинговый ход админов, что похитрее и не хотят работать за еду, на что жалуемся? Вот он шанс в разы улучшить благосостояние ;)
Админы - занимаются инфраструктурой для пользователей
DevOps - занимаются инфраструктурой для программ (проектов)
Всегда думал, что это устоявшиеся термины, и мешать их в одну кучу - такое себе. Например админ не должен знать как настраивать CI/CD, а девопс должен. Если в офисе перестал работать интернет - идут к админу. Если упал прод - идут к девопсу.
Другое дело, что в какой-нибудь маленькой компании могут нанять админа и требовать от него все - чтобы еще и сайт корпоративный сделал, но это уже нишевые проблемы.
В любой девелоперской компании. К примеру в офисе строительной фирмы на 3 компьютера такой уровень абстракций избыточен.
Однако многие инструменты, которые ассоциируют исключительно с DevOps-ами и разработкой уже давно должны быть в арсенале многих сисадминов. Это я про Packer,Terraform, Ansible/Puppet/SaltStack, ELK, Grafana (на какую систему мониторинга вешать это уже вкусовщина).
CI\CD - это общее место в любой компании, разрабатывающей продукт. Не каждая ИТ-компания - продуктовая.
CI/CD — это сейчас настолько общее место в любой IT-компании
Вам повезло с компаниями. У меня противоположность - только в одной компании из всех (штук 5) где работал, был настроен CI/CD. При чем девопса там не было, просто сами настроили.
Возможно особенности вебразработки на php - средний уровень очень низкий.
Админы бывают разных специализаций. Есть админы, которые строят сети. Есть админы, которые администрируют БД. Есть админы, которые занимаютя инфраструктурой для пользователей и т.д.
И девопса можно назвать админом, специализирующемся на инфраструктуре для развертывания приложений =).
И девопса можно назвать админом, специализирующемся на инфраструктуре для развертывания приложений
И всё было бы прекрасно, если бы его должностные обязанности на этом заканчивались. Но если нет человека, который подставит костлявое плечо, когда «что-нибудь пойдёт не так» — по моему опыту, отлично разбирающиеся «в развёртывании приложений» начинают паниковать. Потому что, в сотый раз — нет соответствующего бэкграунда.
Картинка справа. Без комментариев.
Админы будут нужны как раз в этих самых aws и т.д.
DevOps не стал спасительнйо палочкой на пересечении нескольких граней IT,но со скрипом взвали на себя CI\CD , предоставив девелоперам больше времени на написание статей на хабре))) Надежда на универсального бойца ,решающего все проблемы не оправдалась и теперь вся надежда на SRE))) А посему замечена интересаная тенденция не на разделение направления admin\DevOps , а на совмещение . Совмещение разработки и DevOps не прижилось , попытка решать проблемы разработки силами DevOps не прижились, посмотрим что выйдет из совмещения admin\DevOps )))
>Совмещение разработки и DevOps не прижилось
Проблема в том, что я когда учился, как раз думал именно о совмещении разработки и DevOps практик. Что буду писать код и помогать разработчикам.
Устроился на этой неделе на работу джуном в достаточно крупную контору, меня закинули в техподдержку и сказали, что твоё дело будет реагировать на инциденты, писать код не придётся.
Я человек, а не метадология.
Статья ни о чем, очередное нытье.
Если по делу - автор, ну, камон, серьезно - не сможешь отладить приложение на проде? Даже, если привлечь разработчиков? "Девопс" же не человек, который прямо 100% знает специфику приложения, а тот, кто может решать проблему и привлечь при необходимости дополнительные ресурсы, скоординироваться с другими отделами и работать на результат. Противоположность - этот как раз те самые админы-бородачи, которые устали от жизни и руководствуются принципом "работает - не трогай". И саботируют любые изменения. В конце-концов зарплаты 'девопсов' могут быть ВЫШЕ разработчиков средней руки.
Что хуже - девопса как такового как человек быть и не может. Всегда будет специализация - либо в мониторинг, либо в билд (релиз) инжиниринг, либо cloud engineer (всегда мечтал брать монолит, паковать в докер и деплоить в амазон, ага-ага), либо куда-то еще. Но любой смежный опыт будет полезен и экономить время как на решение задач, так и на коммуникацию со смежными отделами.
Поэтому в общем-то проблемы нет.
Предпоследний абзац про облака рассмешил. Похоже, вы знакомы с ними только заочно. Как по мне, эта статья - крик души человека, который не хочет развиваться, но ему обидно, что его профессию недооценивают.
Люди работающие на глобальном рынке указывают на то, что в русскоязычном мире полносью упускают суть "Dev" в "DevOps", в том смысле, что по задумке такой инженер на не менее чем 50% занят продуктовыми задачками. Не инфраструктурой, не саппортом, а развитием фич. И именно оставаясь наполовину разработчиком, участвуя в митингах команды и общаясь с менеджером продукта, он понимает реальные нужды и способен расследовать сложные инциденты, не упрощая реакции на все проблемы до нехватки ресурсов инфраструктуры.
В подавляющем большинстве случаев в русскоязычном мире под DevOps-инженером понимается просто "Ops".
Что тоже нужно и безусловно важно, и должно хорошо оплачиваться, но не является DevOps-ом :)
Именно! Когда я сказал, что хочу учиться прогать и быть на проекте, на меня посмотрели удивлённо:
https://habr.com/ru/post/646581/#comment_23974789
В целом, моё политическое кредо в отношении IT-индустрии можно выразить вполне нехитро - "Каждый должен заниматься своим делом".
Вот вам и нехитрый ответ: тот, кто с этим не согласен, тот и становится DevOps
Это один из моих любимых вопросов)
Какой процент современных молодых и не очень 'девопсов', upper-middle level, требующих от $5000 net денег - знают kernel/networking Linux stack и прочие 'кишочки' собственно на upper-middle level?
По моей практике админы это вот такие вот хардкорщики, знающие до мелочей TCP и по ночам прошивающие микротики взглядом. Реже это эникейщики которые отвечают за оборудование, выдают логины в актив директори, и настраивают новым сотрудникам vpn и слак.
Девопсы же слабо шарят в низкоуровневом железе, зато шарят за CI/CD, номад вс сварм вс кубернетес, когда что лучше, гитлабы всякие настраивают и могут помочь разработчикам написать грамотный докерфайл. Шарят они хуже потому что обычно вычислительные мощности покупаются в облаке — если не авс, то тогда какой-нибудь селектел или ещё какой нишевый провайдер, где местные админы уже порешали все вопросы на этом уровне.
Это просто то, что я наблюдал, и какое разделение подразумевалось в командах/компаниях
шарят за CI/CD
Ща вас пуристы языка за это покарают, как меня в одном из соседних тредов. Как по мне проехались в https://habr.com/ru/company/globalsign/blog/596401/comments/ :)
Если все в девопсы уйдут, кто сети админить будет? Кто будет строить все эти маршруты, коммутации, всякие L2/3 и прочие BGP с OSPFвми?
Кто будет MS Exchange поднимать и а AD ковыряться?
А сетки по VLANам делить, да 40+ отделов по всей стране разруливать?
Все таки, стоит разделять Devops от Net admins
А вообще, именно с сетевиками, я так понимаю, недоразумение из сабжа пересекается меньше всего — возможно, пока что. Но зайчатки, кстати, уже появляются — когда я проходил лабы GCP, мне там попадались такие штуки, как настройка туннеля с помощью трёх переменных с обеих сторон — имени туннеля, айпишник пира и PSK. И ещё поднятие глобального CDN`а с анонсом его префикса из нескольких мест на планете «в один клик».
Разделять может и стоит, но пока разница в зарплатах и условиях работы колоссальна - будет переток.
Хотя есть ещё кое-что: инфраструктурщики имеют доступы, которые разработчикам не нужны (в идеале никакие не нужны, что касается прода). И, соответственно, в первую очередь ответственны за reliability, то есть должны быть более легкодоступны, чем разработчики.
разница между IT-специальностями не только в должностных обязанностях, но и в соответствующем складе умаХорошо заметили даже в отношении dev & ops. Мне лично очень не подходит operations, даже VPN на VPS настроить. Хороший operations, я думаю, должен быть более «обстоятельным», чем разрабочик.
Сейчас очень много посторонних людей в ай-ти: «потому что там плотют!»
Пэтэушники с дипломом щюкатура-маляра, бывший военный на пенсии и прочая и прочая.
Скажите, как относиться с админутым девопсам, поднимающим Moodle на докере? 🤪
А что не так с "имеет место быть" и "доброе время суток"? Вполне себе валидные выражения, казалось бы.
Админ это на винде телефонию настроить, актив директори там, сеть, 1с шареную папку сделать. Роутеры настроить, все такое, обслуживание офиса. А девопс это AWS, Kubernetes, Terraform, Linux, тот кто обслуживает инфраструктуру веб приложений/сайтов. Все ведь просто, так сложилось, смысл спорить. Мнение одного человека не перевернёт представления массы.
Вот о чём я выше и писал. Когда каждого эникейщика звали "администратором", а настоящих админов это бесило, поэтому с радостью побежали по-другому называться.
Описанное в комментарии - это не "одной ногой". Это в чистом виде эникей как он был.
Но ведь админ не разрабатывает. А то, что я видел на рынке и требуется от т.н. девопса — это именно разработка с нуля, интеграция чужого сервиса или раздирание уже существующего монолита, который за х2.5 ценник от обычного сеньёра в рекордные сроки выкатит MVP-прототип, который можно вытащить вперёд конкурентов на рынок и, в случае успеха, какое-то время сдерживать наплыв новых пользователей за счёт горизонтального масштабирования в облаке, пока уже полноценная команда допереписывает соответствующие куски (или пишет с нуля, под руководством архитекторов). Ну а если не выстрелило — идея хоронится, при этом существенно экономится на затратах.
То есть именно что фронтэнд-бэкэнд универсал, который блочными кубиками реализует модульный продукт, криво-косо закрывающий задачу бизнеса, чтобы занять рынок, но недостаточно проработанный, чтобы называть его production-ready решением с поддержкой и доработкой.
раз человечество пережило "ксерокс = копир", "имеет место быть" и "доброе время суток", то и это переживёт
А переживёт ли оно популярное словосочетание "более лучший" ?
Пожалуйста, прекратите называть админов девопсами