Comments 108
Как только количество серверов переходит определенный порог системы управления конфигурацией оказываются незаменимы.
А если работать в компании, у которой активное R&D то все волшебные аббревиатуры, внезапно расшифровываются, и тебе все эти системы ставить и настраивать.
Когда пытаюсь объяснить людям далеким от IT чем же я таким занимаюсь использую аналогии вроде «человек-клей» и тому подобную фигню.
— Зарплаты на рынке — так это ок — рынок же
— Что специалит, который выстраивает процессы стоит дорого?
— То, что кадровики вместе сис.админов нанимают дивопсов?
Ну так они так и нанимают — на 90к со сменным графиком.
немного о том, что в действительности ожидают от соискателей;
немного о неправильных подходах в компании и подмене понятий,
в общем обо всем понемногу.
```
DevOps — (в теории) персона, не понаслышке понимающая все процессы цикла разработки — разработку, тестирование, понимающая архитектуру продукта, способная оценить риски безопасности, знакомая с подходами и средствами автоматизации, хотя бы высокоуровнево, помимо этого понимающая также пред и пострелизную поддержку продукта. Персона способная выступать адвокатом как Operations, так Development, что позволяет выстроить благоприятное сотрудничество между этими двумя столпами. Понимающая процессы планирования работ командами и управления ожиданиями заказчика.
```
Вся остальная статья вокруг того, что люди неправильно называют других спецов.
Ну или растят своих специалистов под эти требования.
А вы с кем сравнивали?
Как в одном из чатов утверждают — с финскими уборщицами?
Как только мы уходим в сеньёров — devops/sre далеко не самая дорогая позиция.
Я не говорю о стоимости ИТ-специалистов в мире, сравнивать зп между странами в лоб, будет некорректно, и не говорю о разнице в ней между США, Финляндией, Россией, Англией и т.д., естественно разница высока, но и стоимость жизни, равно как размер налогообложения.
Относительно дороговизны — все понимают, что при переходе в Senior грейд, рамки между стоимостью специалистов стираются и Senior DevOps Engineer может стоить столько же, сколько Senior Render Engineer, Senior C++ Developer и т.д. Но Senior должен быть действительно Senior, а не обычный тулзист.
Нет людей devops-инженеров. Devops — это методология. И основу ее составляют далеко не инструменты.
Наверное есть devops-евангелисты, но не более. Все остальное — это извращенное недопонимание рынка.
Вот, интересно получается, devops-евангелисты есть, а devops-инженеров нет.
А кто-такой девопс-инженер? Чем он занимается? Dev-инфраструктурой и ci, как администратор тестовых сред? Выкаткой в прод, как релиз-инженер? Поддержкой продакшена, как operations-инженер? Думаю можно продолжать. И все это будут другие роли.
Девопс — это методология направленная на ускорение поставки "инкремента" путем сращивания процессов разработки, operations и на самом деле многих других подразделений. Выставления общих целей. Так чем должен заниматься devops-инженер при таком подходе?
Девопс — это методология, однако, devops-евангелисты есть, а devops-инженеров нет.
Да. Однако!
Нет людей devops-инженеров. Devops — это методология.
Тогда, следуя Вашей логике:
Нет людей android-разработчиков. Android — это операционная система. Нет?
Девопс — это методология направленная на ускорение поставки "инкремента" путем сращивания процессов разработки, operations и на самом деле многих других подразделений. Выставления общих целей.
Так чем должен заниматься devops-евангелист при таком подходе?
Странное сравнение с андройд-разработчиком. Если брать методологию. То более корректный пример был бы со скрам-мастером. Там правда человек который следит за соответствием интерпритации (скрам) такой методолгии как agile. Но все же. Вы когда-нибудь встречали скрам-инженера? Я нет.
Девопс-евангелист — тоже довольно расплывчатая роль. Но более простая для понимания. Это человек, который работает с разработчиками, продакт-менеджерами и владельцами проекта. В направлении изменения процессов разработки. Построению взаимодействия всех заинтересованных отделов и бизнеса. Выправлениям целей. И прочее-прочее. Если продолжать аналогию со скрам-мастером — это как раз этакий центр обучения методологии. К сожалению только вот нет у него такой классной штуки как манифест в скраме. Есть только довольно расплывчатые 3 пути.
Я недавно был в Пушкинском музее на выставке коллекции картин импрессионистов Щукина. Картины очень дорогие. Вот, теперь в замешательстве. Получается, нет никаких импрессионистов. Импрессиониизм — это же направление в искусстве, а не человек. Подождите, может, инструменты у них какие-то особенные? Да, вроде, нет — обыкновенные: кисти, краски. Значит, они всё-таки — просто художники. Подождите. А, может, и художников тоже нет, а все эти люди на самом деле — обыкновенные моляры? У тех тоже инструменты — кисти и краски.
А такая высокая стоимость картин этих моляров — это всё из-за хайпа.
Вы все очень сильно расширяете. Думаю надо довести все окончательно до абсурда и прийти выводу, что художник — человек. Ну и что человека нет. И знаете. Тут на границе с абсурдом я с вами полностью согласен. И не придраться ни к чему совсем. Вы правы.
Спасибо большое, за расширение кругозора. Слово инженер заиграло новыми красками для меня.
Полезены ли все эти рассуждения. По мне так они еще более запутывают и так, к сожалению, замученое рынком направление. Так что, я предпочту воздержаться от такого подхода. И остаться при своем мнении.
Ни в коем случае не хотел Вас в чём-то переубедить. Хотел всего лишь понять, как выражение "Devops — это методология" обосновывает утверждение "Нет людей devops-инженеров". (При этом devops-евангелисты почему-то всё-таки есть.) ???
Далее мне вот, ещё что не понятно. Почему из факта владения devops-инженером необходимыми для выстраивания процессов по методологии devops инструментами делается вывод, что "основу ее (методологии) составляют далеко не инструменты"? Тем самым, как я понял, подразумевается, что devops-инженером незаслуженно называют человека, просто владеющим определёнными инструментами. Согласитесь, что, если devops-инженер, не будет владеть соответствующими инструментами, то и процессы он необходимым образом выстроить не сможет. Это же очевидно.
Я бы сказал так, devops-инженер — это не только про инструменты. Инструменты — суть необходимое условие для devops-инженера, но недостаточное. Это же тоже очевидно.
Конечно, если видеть в devops-инженере только инструменты, то могут возникнуть вопросы. Но только чьи это проблемы-то: devops-инженера или того, кто до конца не разобрался и так видит?
И ещё. А почему сисадмин-то? Почему не разработчик? В слове devops "dev" стоит на первом месте, между прочим.
Про разработчика согласен — спокойно может быть человеком, который продвигает девопс в компаниях.
Про девопс-инженера. Выстраивание процессов — это совместная работа нескольких подразделений. Не может этим заниматься один человек.
Точнее, к сожалению, последнее время так многие как раз и стараются поступать. Берут себе девопс-инженера и такие давай. Выстраивай. И что может этот человек. Настроить ci. Написать деплой. Обложить прод мониторингом. Роли, которые он выполняет в этот момент я перечислял выше.
Но если зайти с другим подходом. Когда несколько команд с лидером, назовем его PO. Собираются. Нам надо ускорить разработку. Нам надо выкатывать фичи чаще. Как мы можем построить свою работу для этого? Хм. Ну давайте разбираться с гибкими методологиями разработки. Давайте пройдем обучение по одному из фреймворков (скрам, канбан). Давайте поймем суть 3-х путей. Выстроим линию поставки, наделаем петель обратной связи, будем шарить знания и не будем искать виноватых. Давайте будем все стремиться делиться компетенциями, чтобы говорить совместно на одном языке.
В первом случае человек есть, а девопса как такового нет. Копи-паста бездумная.
Во втором — человека нет. А девопс есть. Ну или можно сказать, что все там девопс-инженеры, и опс, и дев, и тестировщик, и PO, и т.д. Но их можно тогда называть и agile-инженерами, и еще как-то.
Когда я повторяю эту фразу про методологию, я не стремлюсь кого-то обидеть. Я просто хочу обратить внимание рынка на второй вариант.
Следуя Вашей логике получается проджект-менеджер есть, а проекта как такового нет. Одна копи-паста безумная. Ну а что, проект — это же совместная работа нескольких подразделений. Не может этим заниматься один человек. Далее по ходу пьесы (зачем-то) следует перечисление ролей, которые он выполняет. Это в первом случае.
Во втором случае Вы описали Лебедя, Рака и Щуку.
Ну, и информация для размышления касательно обоих случаев: как Вы считаете, выстраивание какого-либо процесса (с дальнейшим его поддержкой, развитием, изменением и т.п.) с одной стороны и участие в самом этом процессе с другой стороны — суть одно и то же или всё-таки разное?
На тренингах по скраму есть понятие копипаст скрам. Это как раз когда менеджера проекта берут, основные атрибуты добавляют, а мысли и идеологии не придерживаются. Так что да. Бывают пооекты, где менеджер есть, а проекта в полном понимании нет.
Как раз таки и пытаюсь вам объяснить, что выстраивание процесса — это коллективное действие. Один человек не может вместо коллектива этим заниматься. Максимум, что он может — это обучать этот коллектив. Находить единомышленников, работать в направлении внедрения девопс практик. Находить совместно с колегами нужные инструменты. Внедрять их тоже, но опять же понимая зачем это все нужно и доносить это понимание или приобретать с остальными вместе.
Если вам удобно такого человека называть девопс-инженером. То почему бы и нет. Просто термин так себе по-моему. И рынком уже сильно скомпроментирован, к моему сожалению.
Я же пытаюсь Вам донести, что в любом коллективном действии без человека, который это действие колективное возглавляет, получается "колхоз". Согласен, выражался я иносказательно, если Вы это не поняли, назвав это всё Лебедем, Раком и Щукой.
Ну да. Это один из вариантов. Возглавить. В моем случае в самом начале моего пути, года 4-5 назад, когда я только пришел в на новую для себя должность девопс-инженер (да я тоже не существующий специалист )) ), это возглавлял на тот момент PO нашего стартапа. Был ли он сам тогда девопс-инженером — нет. Двигал ли он девопс практики — да! Еще как. Сам того тогда до конца возможно не понимая.
А про возглавить. Очень спорный момент. Вся гибкая разработка строится на горизонтальных командах. Но это уже совсем другая история.
Колхоз или что-то вроде "самоорганизованной кроссфункциональной команды профессионалов" из скрама и прочего аджайл.
Согласитесь, что, если devops-инженер, не будет владеть соответствующими инструментами, то и процессы он необходимым образом выстроить не сможет. Это же очевидно.
Это ошибка. Можно строить процесс чужими руками, например. Спускаешь сверху задание — хочу пайплайн доставки кода. А деталями реализации пускай технарь занимается, которого автор статьи называет "тулистом"
Это ошибка. Владеть и пользоваться — суть разные вещи.
У меня, например, пайплайны в основном разработчики сейчас выстраивают и используют. Причем в нескольких продуктовых командах. И владеют и используют. Вот только скажи им, что они девопс-инженеры, похлопают по плечу и скажут — харе троллить. Мы мол разработчики, которые работают с использованием девопс-практик.
А мне только и остается, что стараться синхронизировать их знания, на их же митапах, чтобы практики в зоопарк не превращались. Людей-то много.
Не, ну, если выстраивание паплайнов — суть девопс, кто ж будет с Вами спорить.
Вы когда-нибудь встречали скрам-инженера?
https://www.scrumalliance.org/get-certified/developer-track/certified-scrum-developer
Это не совсем то. В скраме есть три роли. Владелец продукта, скрам-мастер и девелопер. Под понятие девелопера подпадают все участники команды. Не забываем про кросс-функциональность к которой стремятся в скрам командах.
Хотя с другой стороны, если бы девопс внедрялся аналогично было бы намного лучше.
Инженер ли он или менеджер — вопрос открытый, но согласен, что вне контекста.
Вот, согласен со всем полностью.
Хочу ещё добавить, что когда такой инженер по внедрению devops-практик или для краткости — devops-инженер начинает непосредственно эти практики внедрять, он становится в прямом смысле влиятельным субъектом, потому что начинает влиять на многие процессы. Иногда особо ранимым девам или опсам трудно это пережить. От сюда и занудство крайней степени, и хайп по поводу зарплат.
Полностью с вами согласен. Вот только к пониманию простой мысли, написанной вами, весь рынок идет ужасно кривым путем. Кого только девопсом не называют, лишь бы соответствовать трендам. И это все очень печально.
Я даже не уверен что методология есть. Если посмотреть на статью про DevOps в википедии, то там сплошные "unreliable source", "citation needed" и вообще:
Academics and practitioners have not developed a unique definition for the term «DevOps.».
И обсуждаемая сейчас статья начинается с дисклеймера «это моё личное мнение».
Ну да. Тут непростой вопрос. Методолгия часто довольно рпсплывчатая штука. Есть большой набор книг на эту тему. Есть бережливое производство. Есть "три пути" девопс. Но нет четкости в имплементации. Именно поэтому sre-инженеры есть. Там гугл постарался наделить их недостающими в методологии подходами. Хотя понятие sre рынок сейчас тоже коверкает как только хочет.
То, что автор видит в них сис.админов — достаточно странная история, но есть такое заблуждение.
Знаете. Я не хочу обидеть тех кто считает себя devops-инженерами. В том числе потому, что уже года 4-5 как, так или иначе именуюсь этим термином. Но сам себе врать не хочу. Девопс — это не человек. Это больше про процессы. Про построение взаимодействий и т.д.
А когда очередной раз слышишь, что девопс — это инструменты — docker, kuber, ansible, jenkins, gitlab-ci, etc и дополнительно умение работать с облаками. Становится грустно.
Радует только, что разработчики с которыми я работаю чаще понимают, что это не так.
А когда очередной раз слышишь, что девопс — это инструменты — docker, kuber, ansible, jenkins, gitlab-ci, etc и дополнительно умение работать с облаками. Становится грустно.
Это типичная подмена понятий и карго-культ. Так что — правильно говорите — инструменты — не самоцель и процессов они не заменят.
Должность DevOps-инженера она должна быть именно про процесссы.
Автор же указывает, что сейчас админов бездумно заместили девопсами.
Ну может хоть в комментах обучим автора )
Нет людей devops-инженеров. Devops — это методология.
YuriLozaMode = on ))
Исходя из культуры и требований формируется методология.
Главное отличие DevOps — это зачастую полное отсутствие фундаментальных знаний. Спроси такого человека как устроена виртуальная память, он не скажет, зато при первом удобном случае будет Docker'ом мозги полоскать.
Мы работаем в изменяющейся отрасли. Об этом нельзя забывать. Сейчас знание докер, зачастую может принести больше денег бизнесу, чем знание того как устроена виртуальная память.
А через несколько лет все изменится еще сильнее. И мы должны это понимать и принимать.
Был бы тут umputun он бы наверное сказал — "вот она смерть сисадмина, о которой я уже не первый год говорю!" Вот только по мне так это скорее перерождение профессии.
Выскажу сугубо своё личное мнение.
Могу предположить, что если бы зарплаты devops-инженеров были ниже зарплат Девов или Опов, такого хайпа бы не было.
Какая-то неделя зависти к зарплатам devops-инженеров на Хабре.
Ну тут скорее хайп порождает зп, а не наоборот. На самом деле — если компании, которая занимается разработкой, реально удается найти грамотного спеца. Который владеет не только инструментарием, но и хотя бы общий язык может со всеми участниками процесса найти. Не говорю уж о чем-то большем. Там один обычно не вывозит, даже в небольших компаниях. То такая компания получает реальное преимущество над остальными. И деньги там платятся далеко не просто так.
И согласен, и не согласен
Микросервисная архитектура также появилась с целью упрощения всего описанного выше — меньше взаимосвязей, проще в управлении.
Каждый элемент — возможно, что и проще, но вся сложность перекочевывает на уровень взаимодействия микросервисов. А там этих связей появляется очень много. И ими действительно сложно управлять, следить за ними. Но — это единственная возможность строить действительно сложные и масштабируемые системы
появляются различные Operations:
Остаётся приложить опрос — "какой ты ОПС (или oops)" — в духе Пикабу и пр.
Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все.
И да, и нет. Чтобы эффективно и безопасно пользовать кубернетес нужна очень большая квалификация. Там очень много подводных камней, хотя и развернуть его действительно можно просто. Я уж не говорю, что обучить разрабов правильно писать софт под кубернетес — отдельная большая и нужная задача.
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.
- Это способ оправдать низкую з/п тех, кто будет админить кубернетес?
- Вообще забудьте слово "администратор". Оно вызывает неправильные ассоциации. Я уж не говорю про то, что оно существует и в других предметных областях — "администратор торгового зала", например. Говорите — инженер, техник, ну, ops, в крайнем случае.
Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.
С этим категорически согласен )
А чем-то кардинально отличается написание приложения под k8s от под Docker? Я про прикладные приложения прежде всего, уонечно
Тут зависит от подхода. Ответ — от "не отличается никак" до "нужно полностью переписывать".
Дело в том, что докер не говорит нам как именно он будет запущен — в количестве инстансов одна штука или в распределенном режиме. А кубернетес, очевидно, сразу навязывает нам историю, что у нас распределенная система, в любой момент времени любая нода может "уйти", в любой момент времени любой под (контейнер) может быть убит. И это нужно учитывать. Конкретные примеры:
- нода кубернетеса ушла, куб это пока полностью не прочухал — поздравляю, у вас есть один инстанс приложения, который не отвечает и он не будет перезапущен, пока нода не будет помечена как совсем дохлая
- приложение запускаете как деплоймент, но оно не живет в количестве инстансов более 1 штука (ну, там миграции, хранилище какое-то с эксклюзивным доступом) — я вас поздравляю — вы только сделали возможность его запуска в Н копий. Что при этом поломается — можно только догадываться.
Кратко — если у вас стейтлесс (просто обработка данных запросов по хттп или аналогично) — проблемы скорее всего нет. Если же есть хранение данных внутри сервиса — сразу начинается боль. Или если у вас потоковая обработка данных вроде кафка, чат-бот какой-нибудь, что-то с вебсокетом — то приходится делать все аккуратно, учитывая нюансы.
С этим всем можно жить, просто не ожидайте чудес и скорректируйте свои ожидания )
как выкатить обновление и не остаться ночевать в пятницу в офисе
Время идет, а люди по-прежнему наступают на старые грабли — выкатывают обновления в пятницу, а часто еще и в пятницу вечером.
Обычные малые и средние проекты себе чаще всего такого позволить не могут. А девелоперам, работающим 8x5, в выходные дни надо отдыхать, а не баги пятничного релиза ловить.
Работодателям — точнее формулировать требования и искать именно тех кто нужен, а не разбрасываться лейблами.
Работникам — Учиться.
Это все выводы из статьи? По-моему, что-то более очевидное сложно придумать. Наверное если работодатели сколько то на рынке, то что-то понимают в том кто им нужен и за какие деньги. Как и работники если на рынке, то понимают что нужно постоянно учиться.
Не публичное ПО часто есть, типа собственных CRM. Ну и "сайты" компаний
Только вот где оно, свое по?
Те же свои собственные ансибл плейбуки — вроде бы их можно выложить в открытый доступ, но, во-первых, зачем — там и так своего добра полно, во-вторых, код нужно подготовить — вырезать всю специфичную для конкретной компании историю (это не только пароли-ключи). В общем, все не так все просто.
А то, что не выложены — как бы для остального мира и не существует ) и это свои особенные для данной компании велосипеды получаются.
Может не "админы нужны", а нужен помимо CI/CD процесс постоянного совершенствования навыков (скажем, Continuous Learning — CL)? Те же админы — если не учатся в процессе работы, то очень быстро через какое-то время становятся на рынке труда неликвидами.
Хотел бы заметить, что в слове "девопс" кроме "опс" есть ещё и "дев", причём на первом месте. :)
А разработчики на каком уровне с сетью работали в коде своём?
Скажем так, неудачная идея попытка внедрить девопс путём переименования, по сути, админов в девопосов.
А во многих компаниях так и есть:( "о, умеешь ставить jenkins? Ну тогда теперь ты девопс!" Провожу много собеседований и в большинстве случаев у этих "девопсов" работа заключается в тыканьи кнопки build/deploy. При этом многие говорят, что настройкой ci/cd занималась одна команда, написанием пайплайнов и описанием файлов build framework занимаются разрабы… И многие даже на элементарные вопросы по линукс администрированию не могут ответить… Максимум мониторинг, НО, "настраивала другая команда, а я только готовые темплейты немножко поменял". И всё. Грустно. У нас девопс это серьёзный гибрид синьор админа и разраба (больше в части написания скриптов для автоматической развёртки), но и занимаемся и написанием пайплайнов и базовой конфигурации build framework и много чего еще…
Вот, согласен полностью.
По-моему, ответственность — это даже в первую очередь.
Я бы сказал так, хайп поднимают исполнители, не понимающие роль руководителя.
Всему виною деньги, деньги, —
Все зло от них, мне б век их не видать! (с) м/ф "Остров сокровищ"
Ops не может получать больше X, а DevOps может, так же как и любой другой *Ops.
есть несколько проблем которые я попытался затронуть, наверное зря я их скомкал в одной статье, потому и показалось кому-то, что вопрос именно в стоимости — это не так. Кто-то усмотрел, что я вижу в этой специальности админа — тоже некорректно.
DevOps — подход/владелец процесса, позволяющий организовать Процессы разработки (Development Operations) наиболее оптимальным способом в каждой конкретной ситуации, участвуя в таких смежных дисциплинах, как разработка, тестирование, управление поставками, планирование поставок. DevOps, не важно как персона или процесс, включает в себя функции и системного администратора, ops'a кому угодно, и билд-инженера, и даже продукт-оунера, если под продуктом подразумевается процесс поставки, и еще много различных прикладных дисциплин инженерии, в том числе управление рисками.
Это понимание достаточно большого пласта аспектов процессной организации и технических реализаций и возможных ограничений.
Как и написано в статье:
«Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officer.»
Касательно стоимости — да, человек, что способен управлять таким набором ожиданий и ограничений, назовем его DevOps, действительно может и должен стоить дорого.
Реалии же рынка таковы, что за лейблом DevOps Engineer, в действительности, часто скрываются именно системные администраторы, умеющие пользоваться теми или иными модными утилитами, зачастую не понимая их функции, назначения, возможностей.
Я собеседовал себе в команду очень большое количество «DevOps» инженеров различных грейдов и в подавляющем большинстве это были именно системные администраторы — IT operations, если угодно.
Если на стадии Junior еще можно не понимать какие-то аспекты разработки, а просто строить как видишь, руководствоваться напрямую, без осмысления, информацией от разработчиков — тоже нормально, опыт есть переосмысление ошибок прошлых, то вот на грейдах от Middle и старше это практически непозволительно.
IT Operations не просто так выставляет определенные ограничения на продуктивных средах, это тоже опыт, опыт поддержания систем в высокой доступности и некорректные действия со стороны разработчика, пусть даже по незнанию, не должны все похоронить. Так появляются регламенты, правила, к слову правило не деплоится в пятницу вечером ровно также появилось. Опыт старших грейдов персоналий участвующих в Development Operations позволяет учесть и оценить риски, возможные взаимные влияния Development и Operations, за счет чего, собственно, и достигается гибкость и скорость.
Вилки з.п. у нас достаточно широкие, я сам бился за их расширение, однако даже это не позволило набирать готовых инженеров, способных на исполнение обязанностей с минимальным обучением, их основная проблема — отсутствие именно процессных знаний, иногда даже основ.
Вакансии компаний представлены, дабы показать, что этим компаниям не нужен DevOps, наоборот, они ищут именно системных администраторов, способных покрыть ту или иную область и, если бы они точнее описали свои желания, они бы поняли, что им нужен системный администратор, способный к быстрым изменениям в инфраструктуре, читать как не закостеневший человек с политикой — «держать и не пущать».
Потому и получается например, что нам приходится брать Operations и добавлять принципы и подходы Development, также пытались в обратку, но единицам из Development интересны Operations, рассматриваются в большинстве случаев лишь как ненужные ограничения.
Спасибо за разъяснение, но это можно было озвучить в статье, чтобы не быть неправильно истолкованным. Тем более после материала от коллег из БюроБюро — https://habr.com/ru/company/southbridge/blog/468389/#first_unread
Ну, и подскажите, что у вас за компания — посмотрим вакансии. Если боитесь огласки — можно в личку.
А вы уверены, что вообще нужны отдельные DevOps люди? Что просто хороших коммуникаций и единых, скажем так, KPI между dev и ops недостаточно? У меня, как у разработчика или техлида разработчиков, вот как-то обычно с "админами" полное взаимопонимание после того как рассказываю о потребностях бизнеса, известных мне, и специфики нашего программного решения. А уж после того, как кластер настрою (логически), сделаю "скрипты" его разворачивания на новом железе и объясню его плюсы и минусы по сравнению с "деплоем по ftp" вообще, покажу как квоты задавать, масштабировать, доступы ограничивать и т. д., на руках готовы носить :)
Согласен с комментатором ниже, что всё зависит от масштаба. Скорее всего, в Вашем случае, масштаб, как мне кажется, совсем небольшой, т.к. для меня, например, странно слышать, что разработчик "рассказывает о потребностях бизнеса" админу, как и то, что он также "настраивает кластер, заводит квоты, масштабирует, доступы ограничивает" и т.п. А кодит-то этот разработчик когда? Разработка — это же творческая работа, для написания качественного кода требующая соответствующего настроя, погружения в процесс, нахождения в определённом состоянии и т.п. Все эти вхождения, погружения, настрой требуют времени, поэтому постоянное выпадание из процесса разработки очень сильно влияет и на производительность, и на качество кода. Скажем так, "забивание гвоздей микроскопом" позволительно на небольших масштабах.
Кстати, Ваш опыт яркий пример того, что в девопс часто приходят из дева.
Разработчик рассказывает админу как заводить квоты, ограничивать доступы и т. п., передавая ему кластер, настроенный с точки зрения потребности разработки. Ввязывается это по принципу "если не я, то кто?", "хочешь сделать хорошо — сделай это сам".
И да, на начальном этапе очень много времени требует.
Процитирую вас. Если мы имеем дело с кросс-функциональными самоорганизованными командами, на самом деле выделение отдельной компетенции в отдельном человеке — это глупо. Если все или большинство в команде понимают, что такое девопс — это очень хорошо. Так что ситуация, которую вы описываете, намного больше девопс, чем когда целые отделы девопс спецов набирают.
Про масштабы писали в комментариях. Для работы нескольких команд есть "надстройки" над agile-фреймворками. LeSS, к примеру. Это лучшее решение, чем отдельный человек-"синхронизатор" в каком-то вопросе. Правда внедрять все это — большая работа.
Ну похоже на то, что на прошлых проектах я был в, как минимум, почти кросс-функциональных командах, иногда с выделенными админами в составе команд, иногда вне. Если так подумать, то именно когда они были вне команды, когда их ресурсы выделялись на проект по почти остаточному принципу, то тогда я начинал настраивать процессы и инфраструктуру, так чтобы команда была кроссфункциональной, чтобы наши фичи считались бизнесом готовыми без ожидания когда у админов будет время их задеплоить, развернуть новый сервис или базу. Но ни о скраме, ни о девопсе я тогда даже не думал, можно сказать слов таких не знал.
Сейчас у нас SoS на две команды, в плане девопс небольшая диспропорция и ни одна команда даже не имеет полной общей картинки процессов. Полностью определнно закрываем 100% "что есть" и процентов 90 "что будет", но в одной команде около 80% знаний о том, что есть, в другой около 40. В одной около 40% знаний о том как должно быть, в другой около 80. В одной около 30% знаний и навыков что нужно сделать, чтобы перевести "что есть" в "что нужно", в другой около 90. но мы работаем над 100%, это явно выделенная цель. И 100% у нас не будет отдельно выделенного девопса в каждой команде, будет, в худшем случае, один человек с ролью и разработчика, и девопса. Бас-фактор для команды заметный, для проекта — гораздо менее заметный.
Не пойдут на лейтенантские должности генералы. Как не крути. Либо должность должна быть генеральской, либо выращивать генерала надо самим.
Согласен во всем, кроме разве что той части что девопс должен дебажить код и делать прочие активности связанные с работой с кодом.
Уметь — да обязан, но делать — нет. Есть владельцы этого кода, пусть они и дебажат ))) А DevOps им дебаг настраивает. Без полного понимания как это работает в коде- там делать нечего.
Опять же как сказал автор, лучшие DevOps — получается из разработчиков, а разрабы не хотят разбираться с системным администрированием. Вот здесь надо бы и обратную зависимость провести — если человек не пошел в разработчики, а пошел в сферу где сложнее и нужны знания из большего областей, значит он не хочет быть разработчиком.
Тут опять же требования могут разниться- одним достаточно у DevOps понимания что такое Garbage collector, вторым подавай глубокие знания как с ним работать. А человек работал только на проектах с .Net.
а разрабы не хотят разбираться с системным администрированием.
Обычно не хотят глубоко разбираться с системным администрированием. На самом деле всякие IaaS и PaaS значительно понижают требования к глубине системного администрирования в более-менее обычных ситуациях. А значит, по идее, отказ компаний от "селф-хостинг" или, как минимум, создание внутреннего IaaS/PaaS провайдера, значительно упростит внедрение девопс практик. Вроде логично, нет?
Они конечно могли понимать процесс разработки — никто не запрещал, но это совершенно их не касалось и не входило в их роль абсолютно.
Простой пример — сборка nginx из сорцов и опакечивание — это админская работа? Но пайплайна-то сборки и тестирования она требует!!!
Это работа девов, а вот его установка, мониторинг и конфиг — скорее админская работа. И бекап, и т.д.
Проблема в том, что нет. Это кусок инфраструктуры. И соответственно — он в зоне ответственности админов. Точно так же как и какое-нибудь платформенное решение типо kubernetes (rancher, okd) или hadoop, поверх которых бегут приложеньки разрабов, решающие конкретные бизнес-задачи. Да, иногда можно этот кусок отдать на сторону — использовать SaaS и managed варианты. Но иногда приходится работать с этим всем in-house.
И даже если где-то это будут делать админы с CI/CD этой сборки nginx, то как это связано с процессом разработки парсера финансовых данных в каком-нибудь финтеке?
Никак. Это два параллельных процесса.
Они знают как построен процесс разработки, тестирования, изменения требований и т.д. этого парсера?
По-разному
Ну максимум на них могут навесить его билд, и то скорее разрабам дадут делать.
А потом начнется очередное перекидывание ответственности — "это не у нас приложенька-печенька не работает, а ваша инфраструктура говно"
Проблема в том, что нет. Это кусок инфраструктуры. И соответственно — он в зоне ответственности админов.
А если не nginx, а собственно разработанный веб-сервер, как часть конечного продукта? Уже ответственность девов? А если nginx один раз девами пропатченный? А если постоянно патчится?
Да даже если nginx обычный, кто конфиги для него должен писать? Совместно? Админы, а девы ждать по три дня пока до них дойдёт заявка на изменение одного location? Девы, а админы материться из-за кончившегося места, из-за того, что, условно, девы решили сделать логи немного подробнее и добавили тело запроса.?
Сложный вопрос. Решается только работой вместе, постоянной коммуникацией и пониманием общих целей.
Админы, например, могут максимально рутинные задачи вроде создания локейшенов автоматизировать и дать разрабам какую-то ручку, чтобы они могли не беспокоить админов, но при этом и не сломать конфиг nginx.
Кубернетес, кстати, отчасти именно эту проблему решает. Именно как платформенные решение
Ну что же вы снова выдираете админов из контекста:)
Я же говорю, что в большинстве случаев к нам приходят именно админы:)
Я вообще пришел в DevOps с QA где и занимался на самом деле DevOps когда этого слова вообще не было.
И правильно. Сначала это действительно делали разработчики, либо QA-automation инженеры потому что это именно им и необходимо, затем решили высвободить их, так и появились Build engineer, которые автоматизировали то, что им скажут и в точности так, как им скажут. Затем выделились Configuration Management инженеры, были даже такие позиции — CM engineer, которые настраивали именно среды для запуска систем и Build Engineer'ы, которые отвечали за системы сборки. В энтерпрайзе так уже много лет, возможно малым командам было непозволительно содержать такой штат и появились именно подходы "you build it, you run it". И наверное как-то так и появились утилитарные ребята, что пишут код для написанного кода, стандартизируют подходы, и т.д. и т.п.
Была у нас пара попыток QA engineer взять, но одна отказалась, поскольку ей было не интересно заниматься этим, а другой не имел общего представления о SDLC, тест-кейс менеджменте и т.д.
Что же, скотской она становится, когда ожидания и реалии не совпадают, когда требования к реализации не соответствуют административным ресурсам, когда ответственность не совпадает с полномочиями. Большинство проблем в данной области связаны именно с административными ограничениями и/или недоработками. С техникой просто решать вопросы, а вот с людьми нет.
Относительно смысла жизни — не уверен, что он связан с каким бы то ни было типом творчества, но здесь каждому свое. Однако, и разработка, и автоматизация тоже вид творчества и умалять это не стоит.
Можно просто на коленке что-то нафигачить, а можно продумать архитектуру решения, оценить риски, сбалансировать экономические затраты и создать действительно произведение инженерного искусства.
Кто как, а я лично испытываю истинное наслаждение от хорошо реализованных систем автоматизации, нежели от полотен Рубенса или творчества композиторов.
По вопросу — смысл есть всегда, поскольку Development Operations никогда не был привязан к утилитам или операционным системам. Процессы разработки, равно как их автоматизация и оптимизация присутствуют на всех мыслимых и немыслимых платформах.
Знания Windows платформ и их администрирования достаточно сильно востребовано в разработке игр, системных утилит, из языков C/C++, C#, да и взрастить конвергентную среду с полной интеграцией Windows и Linux серверов, и рабочих станций очень распространенная задача. Например, компания использует AD, аналитики/data-science/художники работают на Windows/MacOS, девелоперы на Linux/MacOS, продакшен енв полностью на Linux — требуется прозрачная авторизация на проде, с применением групповых политик, двухфакторной авторизации, управлением ssh-ключами доступа. Как результат появляется задача — настройка федеративных отношений между AD, FreeIPA, интеграция с UbiKey.
Еще часто востребованная задача — автоматическая подготовка окружения сборки для триумвирата(Linux/Windows/MacOS), либо вообще кросс-компиляция, правда последняя обычно на Linux осуществляется=)
Пробуйте, учитесь, развивайтесь.
Никогда не понимал деления на Windows/Linux/Unix администраторов если честно.
Как минимум для нефтянки оно очень актуально. Вся инфраструктура работает исключительно под Windows, и только SAP на Linux, но его админят отдельные люди, и задачи с ними не перекрываются от слова совсем.
Т.о. за 5 лет работы с линуксом я не сталкивался вовсе, и рассматривая сейчас вакансии DevOps, «оконных» вариантов я там пока не встречал. Собственно, оттого и возник вопрос — бывают ли такие инфраструктуры в природе.
Кто такие DevOps?