Комментарии 24
В многих компаниях нет ограничений между 3 этими направлениями это делает все один человек
Думаю, что подобное разделение чистая условность. Или если хотите маркетинговый ход. Платят больше денег за то, чтобы меня называли DevOps или SRE - и ладно.
Вот я был системным администратором все последние десять лет. Я занимался плюс-минус похожими вещами в разных направлениях и в разных компаниях. Если объяснить бизнесу что на самом деле админ и 10 лет назад умел поддерживать инфру, писал какую-то автоматизацию, занимался мониторингом, то их думаю данная мысль сведёт с ума.
"В нашем сообществе сисадмины почему-то воспринимаются как «а, это те самые, которые принтер чинят?»" - ну как же без пятиминутки снобизма?
Это "ваше сообщество" - какое конкретно? Сообщество DevOps МТС?
Спасибо за комментарий 🌝
Если подняться выше заголовка, можно найти дисклеймер, в котором прямо говориться:
Все нижесказанное — мои наблюдения и собирательный опыт. Они не отражают положение дел в MWS или другой реальной компании.
Если подняться ещё выше (на 2 абзаца), можно найти упоминание какого-то сообщества:
И... кажется, в ИТ‑сообществе...
Т.к. всё вышесказанное - мнение одного человека, то, кто знает, может быть речь вообще про ИТ-сообщество айтишных человеков пауков?
Devops-инжинер - звучит гордо. Только не надо заблуждаться. Чтобы насадить культуру ДевОпс инженером должен быть психолог, т.к. речь про поведение людей и групп.
Вам же дали задачу пайплайны писать и инфру, вы не нашли другого термина, кроме как ДевОпс. Так вот, в вашем случае, если остальные это Dev, то вы - Ops.
Метрики не принадлежат какой-то роли - это про команду.
И в поманде может быть Опс и много Дев, и каждый из них может писать пайплайн и инфру, тем самым влияя на метрики.
Не рассказывайте про значения заголовков вакансий которые придумали HR, а разберитесь в терминах для начала.
Хорошо, больше заблуждаться не буду 🤷♂️
Можно ссылку на вашу статью, расставляющую точки над [ё] ?
В вашем профиле не нашёл 🥲
Ответ в духе "а чего добился ты?"
За меня это все описали другие люди. Хоть тот же DevOps Topologies почитайте или Dave Farley с Кентом Беком или Р Мартина. Изучите что они говорят про ответственность разработчиков и процессы.
И если вам автор говорит что DevOps это культура - то это культура. Не надо переопределять термин. Администратор не может в культуру. Психолог и соц инжинер может.
Культуру вот пытались инженерить в некоторых странах. Делается это через PsyOps, СМИ, книги, систему обучения, кино.
Писать пайплайны и IaC любой может. Главное чтобы мотивация была.
Попробуйте еще спросить бездушную машину: "Откуда появилась должность DevOps инжинер? Соответствует ли название должностной инструкции? Соответствует ли эта роль в принципе определению DevOps?"
Она вам без эмоций сама все и расскажет.
>Devops-инжинер - звучит гордо. Только не надо заблуждаться. Чтобы насадить культуру ДевОпс инженером должен быть психолог, т.к. речь про поведение людей и групп
Это вообще так не работает. Культуру невозможно насадить, её можно только вырастить внутри. Честно говоря реальный девопс я мало где видел, не в части наличия каких-то автоматизаций, а именно как культуру разработки и не представляю даже близко, как это делается.
Я сам участвовал в проекте, где девопс действительно насадили причём в формате безальтернативно взяли и забрали доступ от продакшена (таковы были требования ИБ). К сожалению, но по итогу понимания что это и зачем даже спустя несколько лет пришло далеко не всем. Осталось не мало людей для которых не иронично "гит не инструмент разработчика" и вообще верните нам лучше доступ к нашим базам в продакшене (речь про DWH-аналитиков, если что).
В том то и дело, что это так не работает.
Вот автор статьи приводит дора метрики. Все эти метрики будут нулевым, если разработчики не пишут код, не добавляют тесты, не пишут миграции, не умеют пользоваться версионированием апи. И какая бы там крутая автоматизация не была - все без толку.
К тому же все эти метрики существуют только на уровне команды. Отдельный человек их не делает. По тому что базовая единица поставки софта - команда.
С другой стороны если разраб делает это все - получается он девопс. Даже заменив библиотеку тестирования или миграции бд - ему придётся поправить пайплайн. Т.е. он уже вовлечен в автоматизацию. Выходит все разработчики - девопсы?
Там столько логических ошибок с этими дЕво-Псами, что если начну все расписывать, то придётся бросить работу и только и строчить статьи да ответы.
Культуру может вырастить только лидер поощряя определённое поведение, делая каждого в команде ответственным за результат. Когда разраб несёт ответственность за свою работу - он сам все автоматизирует и улучшает метрики. Ему не нужен костыль в виде пайплайнописца. Внешняя экспертиза про инфру пригодится. Счета за инфру пригодятся. Разрабы сами хотят все оптимизировать.
Забирать доступы - это не девопс. Это ото про безопастность. Возможно это и было нужно, но там много вопросов к исполнению и что дали в замен.
Я считаю это бесполезно, т.к. люди работающие с данными все равно их получат. Не из базы, так из какого-нибудь пресловутого даталейка.
Обычно это делают опсы которые считают что все вокруг овечки и не несут персональной ответственности перед работодателем. Хотя по факту, это как отобрать у дворника метлу.
Были у меня с такими ребятами долгие разговоры. Потом приходили юристы и объясняли что они не правы.
DevOps и Sre — это следующие этапы развития системного администратора
Считаю что это утверждение верно. А Вашу статью можно разбить банальным сравнением уровнем заработным плат у SysOps и DevOps/SRE специалистов. Даже в Вашей компании последним платят больше
Если сотрудник или отдел сотрудников разрабатывает и раскатывает IaC через пайплайны в различные окружения или использует подход GitOps, обеспечивает работу инфры 24/7/365, то это сисадмины, инженеры девопс или SRE? Чем сотрудники такого отдела отличаются от сотрудников другого отдела, которые делают все то же самое только для кода, например, магазина по продаже трусов?
Но суть от этого не меняется, чтобы изменился подход, он должен измениться у руководителей. А учитывая бум ИИ, сомневаюсь, что это скоро произойдет.
Это все такой рандом. Я встречал девопсов которые были архитекторами, классными разработчиками и конечно же могли хорошо настроить облачную инфраструктуру и мониторить её. А ещё я встречал девопсов, который говорил, я не разработчик, ты мне вопросы по инфраструктуре не задавай, я могу добавить переменную окружения, а ты сам решай какую тебе надо.
Есть ощущение, что есть девопсы бывшие админы - безграмотные эникейщики, когда ты бы все сам лучше сделал если бы у тебя были доступы и ты лишь тратишь кучу времени на бесполезные согласования, и есть девопсы бывшие разработчики - мощные специалисты с которыми приятно работать, и которые снимают часть нагрузки с разработчика.
Спасибо за комментарий.
Кажется, на ваш опыт в большей степени повлияла слабая научная база современных ИТ специалистов. Проблематика строится на лёгкости освоения навыков работы с инструментами/фреймворками.
Если продолжать медицинские аналогии, легко выучить, что при некоторых симптомах эффективен некоторый набор средств. Но для грамотной диагностики и эффективного лечения, необходим научный базис и специализация.
Как мне кажется, пока рынок транслирует необходимость в навыках работы с инструментами, а не необходимость получения бизнес-ценности, тенденция будет сохраняться, к сожалению.
P.S.:
Всё вышесказанное справедливо не только для сотрудников команд эксплуатации, но и для команд разработки. В качестве эксперимента, поспрашивайте разработчиков о том, что такое процесс операционной системы, предоставляет ли операционная система какой-то API или, например о том, какой транспорт использует HTTPS.
На мой взгляд это просто очередной этап эволюции "компьютерщика". Когда появились первые ПК, тогда не было айтишников, тогда были компьютерщики, которые и в железе разбирались и программы какие-то писали. Потом пошло разделение на тех, кто занимается аппаратной частью и программной. Появились программисты) потом выяснилось, что программисты разные нужны, есть прикладные, системные, веб(фронт, бэк) и т.д.
Админы тоже начали разделяться как с программистами - есть сетевые, инфраструктурные, DBA - потому что все усложняется и в рамках одной роли/одного человека уже не получается это все нормально вывозить. Поэтому выделение отдельных ролей для DevOPs инженеров и SRE - это вполне нормальный процесс. И то что один человек это когда то делал или делает сейчас - это тоже нормально, просто на тот момент требования/сложности процесса обслуживания приложения в проде были другие.
Тут аналогия как с врачами - в начале 20 века врач и от простуды лечил и операции делал. А сейчас это совсем разные специальности, даже у хирургов есть свои специализации. Просто в ИТ это идет немного быстрее, чем в медицине.
Спасибо за статью, мне зашла!
Картинку (идеального мира) со ступеньками сохранил. Хочу распечатать и на дверь отдела повесить ))
Sysadmin, DevOps и SRE: как понимать эти роли, чтобы они не вредили карьере и бизнесу