Pull to refresh

Comments 23

UFO just landed and posted this here
Про BSD это просто пример был, смысл в том, что мало автоматизировать, надо еще потом использовать и уметь поменять.

А роли и комитеты нужны, чтобы развивать систему, а не просто в хаосе жить.
Про BSD это просто пример был, смысл в том, что мало автоматизировать, надо еще потом использовать и уметь поменять.

Посыл читается как: «Вы не поверите! Они не на линуксе это все сделали, а аж на фряхе!»
Я уверен, что там люди могли и сопровождать, и реструктуризировать систему. Скорее всего там даже решения общеизвестные использовались, но они были не на слуху в мейнстриме. Вот и результат — «административно запретил использовать FreeBSD».

Просто весь доклад пропитан «технологичностью компании» и всякими посылами к мейнстрим новомодностям и вообще «этот ваш энтэрпрайз — зло». Все же читается как на ладони: «Мы все понимаем в девопсе, мы его родоначальники, гоу к нам на консультацию и у вас все будет круто! У вас крутые спецы все уже сделали и все работает как часы? Они все сделали неправильно!».
кстати так и не понял за что провинилось BSD если все было автоматизировано

Я уверен, что там люди могли и сопровождать, и реструктуризировать систему

так дело ведь не в том, что там сейчас все круто, а в том, кто все это потом будет поддерживать, когда эти админы уйдут. Наверняка найти людей которые готовы сопровождать популярные дистрибутивы линукса проще, чем тех, кто разбирается в BSD.


Тут всегда вопрос баланса между "красивым" решением и "поддерживаемым". Мне вот часто приходится бить себя по рукам, когда я в порыве стремления к красоте и автоматизации хочу написать как можно лаконичнее — можно в том же баше весь скрипт упихать в одну строку с пайпами: красота, наслаждение! Но совершенно нечитабельно, и поэтому лучше развернуть в несколько строк с циклами, и комментов добавить. Питонисты тоже иногда подобным могут увлекаться)
Я вот тут недавно писал логику для gitlab-ci файла и мне понадобились динамичные имена переменных. Ну, первая мысль, конечно — eval. И тут я натолкнулся на замечательный коммент на StackOverflow:


You can use eval, but the next maintainer will curse your name. (отсюда: https://unix.stackexchange.com/a/194030)

В итоге я добился того, чего хотел, у меня получилось два вложенных eval'а, все красиво, все работает. Я посмотрел на все это, понаслаждался своим творением, потом подумал о тех, кто будет после меня это поддерживать, стер все нафиг и написал заново по-человечески. Да, получилось больше кода. Но зато это смогут прочитать и быстро понять ребята из dev отдела и тот парень, который после меня когда-то придет править этот файл.

так дело ведь не в том, что там сейчас все круто, а в том, кто все это потом будет поддерживать, когда эти админы уйдут.


Вы думаете на Линуксе нельзя построить такую систему, что без бутылки не разобраться? Запросто.

Ставить софт из исходников со своими патчами, наплодить кучу зависимых докеров. И все это «забыть» задокументировать.
конечно, согласен. Тут опять же главный вопрос это не инструмент, а его использование
UFO just landed and posted this here
так дело ведь не в том, что там сейчас все круто, а в том, кто все это потом будет поддерживать, когда эти админы уйдут. Наверняка найти людей которые готовы сопровождать популярные дистрибутивы линукса проще, чем тех, кто разбирается в BSD.

Зря вы — различие между линуксом и бсд одновременно и огромно, и минимально. Чуть больше времени для акклиматизации сотрудника и чуть больше времени, чтобы понять, что это не линуск.

Второй момент: требования могут быть разные. К примеру, винда. Девопс нельзя построить на винде? Если не нравится, то запретить? Тот же stackoverflow вроде как построен на винде. Не технологично?

Кстати, внезапно, есть еще один сайд-эффект: процент адекватно разбирающихся кандидатов-фряшников будет выше, чем кандидатов-линуксоидов. Все просто: линукс везде на слуху, вокруг тонны рецептов, и почему-то решение копипастой кандидатом воспринимается как «я знаю линукс».

Тут всегда вопрос баланса между «красивым» решением и «поддерживаемым». Мне вот часто приходится бить себя по рукам...

Только при чем тут операционная система?
Не путайте теплое с мягким. И не приплетайте сюда языки программирования. Я много чего красивого могу рассказать про PHP, JS, Perl и другие — язык никак не относится к желанию отдельного человека скукожить все в 30 строк кода.
А что вы хотели сказать заголовком? Что сисадмины не люди?
Шаткий шаг на техническом ресурсе. ;)
Я сам сисадмин ;) тут рассказ был про то, что сисадмины часто залипают в своей роли и становятся бесчеловечными и чтобы не залипать и обновлять свои знания нужна другая организация и роли и процессы и это и есть DevOps.
Ну залипший админ это «Легаси человек», который выучил узкую нишу и не желает из неё выходить ибо и так всё хорошо.
Все остальные постоянно изучают рынок и стремятся вносить рациональные предложения но натыкаются на стену непонимания со стороны легаси коллег.

Тем более внедрение к примеру автоматизации развёртывания (chef… etc) по мнению «Легаси людей» невелирует их ценность для работодателя и если он чувствует что работодатель к нему относится без должного поклонения, то будет сабботировать весь процесс автоматизации — из-за боязни того что его заменят скриптом. :)
С разработчиками, конечно, залипание или не случается вовсе, или случается на порядок реже.
не думаю, скорее имеется ввиду процесс становления сисадмина инфрастуктурным инженером. сам прошел этот путь, поэтому меня заголовок всем устраивает :)
Давно я столько воды не читал.
Ребят, подобными статьями вы отбиваете желание ходить на конференции. Я понимаю, что доклад был рекламным, но может стоило составить материал по более полезному выступлению?

Коротко паре моментов доклада:
Я несколько раз сталкивался с тем, что такие люди строили DevOps на FreeBSD. Получалась закрытая система, которую они сами написали, и только они понимали, как она работает.

При чем тут BSD? Да хоть на солярисе все построить — это никак не относится к делу.

NoSQL не круче SQL, более того, на состояние 3-4 года назад он гораздо хуже SQL. SQL-базы разрабатывались 20 лет, а NoSQL-базы — 1 год.

У меня сложилось впечатление, что знания автор черпает из новостной ленты и конференций.

Ну и про ярлыки уже написали. Осталось добавить, что нельзя всех под одну гребенку собирать.

P.S. Ну и «От сисадмина к человеку» звучит как «От обезьяны...»

Кажется, многие недовольные названием комментаторы не встречались/не работали с сисадминами, старательно заужающими свою зону ответственности. Так возникают сисадмины, которые с точки зрения взаимодействия не только "сисадмин и ничего больше, чё пристал? (И относитесь ко мне, как к человеку)". Так возникают сисадмины, которые пишут в хелпдеск, а их хочется послать к сисадмину, ибо он знает, что надо делать.


Сисадмины! Будьте (старательно) людьми! Не замыкайтесь в рамочку!


P.s. я, кстати даже к упомянутым субъектам отношусь, как к людям, и стараюсь помочь. Чтобы самому не уволиться из людей в чисто разработчики. Да и кто из нас в своём уме?

Я вот работал с такими сисадминами, но позже понимаешь, что дело не в профессии/должности, а банально в людях. Как людям позволяют себя вести — так люди и будут вести себя. Кому не по душе — тот уходит (что сделал и я).
Я читал разные статьи и краткие описания термина DevOps. Может быть, я туповат, конечно, но я не могу белее-менее однозначно понять, что это. Технология, процесс, должность, специализация, состояние души?
Культура производственных процессов
А когда вакансия называется «DevOps»? Их не дофига, но встречаются довольно часто. Это наниматели сами не понимают, кто им требуется? Или они хотят нанять того, кто сделает кнопку «За… ись»? Вопросы риторические, наверное…
Наниматель дал задание рекрутерам найти побольше админов. Концепция DevOps слишком сложная, чтобы понять её за пару минут неквалифицированным рекрутером. Но рекрутер знает, что если назовет вакансию «DevOps» (даже если она не совсем понимает, что это вообще значит, даже если это неправда), то это может выполнить план по набору админов. Причем админов с высоко актуальными кейвордами в резюме (всякие CI/CD, скриптовые языки, итп).
Я несколько раз сталкивался с тем, что такие люди строили DevOps на FreeBSD. Получалась закрытая система, которую они сами написали, и только они понимали, как она работает. Я, несмотря на мой сисадминский опыт, не мог разобраться, а если я не мог, то как разработчик должен был понять, как деплоить через эту CI-систему? В итоге я административно запретил использовать FreeBSD в компании


Еще один эффективный менеджер. Отлично. «Я не понял как это работает и поэтому запретил». Средними веками повеяло.
И это при том, что буквально в соседних абзацах рассказывается, что ценность в людях, в культуре, что взаимодействие должно быть. Ну так, следовательно, нужно было не запрещать технологию, а организовать документацию и распространение этих знаний для остальных. Обучение должно быть, подтягивание уровня низших до уровня высших, а не нивелирование всех под одну гребенку.
Sign up to leave a comment.