Немного о том, что называют devops в РФ

Занятное это дело - автоматизация. Ещё более занятное - это когда ты в неё можешь и умеешь, имеешь прекрасное представление о том, как можно избавиться от огромного количества рутинных задач, следуя основному принципу так называемой devops-культуры, но... Вместо этого современный тренд, по крайней мере, в нашей стране заключается в страхах и опасениях по поводу полной автоматизации тех или иных технологических процессов в пользу углубленного знания особенностей операционных систем и чрезмерного дрожания над каждым мегабайтом оперативы, cpu, i-nodes, iops, swap et cetera. Безусловно, это хорошо, когда есть глубинные познания особенностей устройства операционных систем, ещё круче, когда ты знаешь все команды сразу и когда тебе задают вопрос, ты работаешь как help, только ещё круче: сразу выдаешь нужную команду со всеми необходимыми ключами применительно к любой ситуации - но возникает резонный вопрос: а останется ли место в твоей постоянной и оперативной памятях на то, чтобы тебе об этом больше никогда не думать? А не поедет ли кукухой твоя светлая головушка, если решит открыть для себя несколько иные горизонты не менее сложного по задумке приклада, чем то, где ты его разворачиваешь? А если ещё и взять стэк devops - инженера, полноценного, умеющего и в программирование, и в контейнеры, и в highload, и в межсервисное взаимодействие, и в БД (SQL и noSQL), и в ИБ, не говоря уж о мониторинге с оркестрацией с контейнеризацией и отказоустойчивостью, то гарантированно надо бронировать местечко в психоневрологическом диспансере заранее, если вдруг задашься целью выучить и запомнить все сразу, стараясь применять   "свободно, без словаря". Иногда даже интересно было бы взглянуть на тех, кто реально в это может, кто как chatGPT из памяти хреначит полноценный сервис, блюдя все принципы SOLID, оптимизируя его под масштабирование и экономию ресурсов, покрывая автотестами, никуда при этом не заглядывая и не перепроверяя себя, а потом сам же непрерывно интегрирует и деплоит в прод. ИМХО: такой человек должен получать минимум от 700к. Но, как я понял, таких людей нет, даже среди тех, кто лидит направления в бигтехах. Но HR-ы их все равно активно разыскивают, напористо и бескомпромиссно. Постепенно вникая во все реалии рынка, втягиваясь, так сказать, в процесс бытия, обретая день за днем новые навыки и знания, все чаще убеждаешься, что вроде бы знаешь всё и ничего не знаешь одновременно. В книгах ты находишь одно, на практике - другое, в общении с коллегами - третье, а истина вообще где-то между этими лебедью, раком и щукой, а тебе лишь остаётся выбрать, в чью сторону ты будешь тянуть лямку и чью линию гнуть, если вообще будешь, потому что понимаешь, что без точек опоры даже Архимед Землю переворачивать не рисковал, не говоря о том, что вообще нужна лошадь, а лучше две, чтобы телегу, наконец, начать двигать в нужном направлении. Так может всё - таки стоит задуматься о чём-то более возвышенном, предварительно автоматизировав bestpractice-подходы, не держа их в голове, или таки здравствуй, "дурка" ? P. S.: такой вот "краткий" эпос, основанный на личных наблюдениях и опыте, как своём, так и тех, кто во всём этом крутится.

repost

161

input message

напишите коммент

· 20.03

В зависимости от компании, девопс может быть как модное погоняло для сисадмина, который научился в докер или кубер, и может стейджить все процессы от тестирования, до пилота, препилота, и потом выкатывать в прод на 3 волны, до человека, которого взяли на несколько сотен тыщ в месяц, но в компании нет для него задач, потому что количество устройств уже много для одного сисадмина, но недостаточно для одного девопса.  И для того чтобы девопс нормально работал, ему нужно еще пользоваться программами, которые могут стоить немалых денег и окупается это на количестве компов от 1 тыщи. Еще проблема в том, что к примеру так можно по дефолту стейджить несрочные патчи для программ типа офиса, чтобы обновления не поломали макросы в эксельке.  И это еще не говоря про мониторинг, бекапы, где программа сама может быть бесплатная и крутая, а потом сюрприз — за восстановление бекапа заплатите несколько десятков тыщ долларов :)  Но суть в том, что допустим если компания аутсорс как это было раньше, то компания будет стремится перепродать сисадмина за бугор по цене девопса.  А если не аутсорс и девопс нужен для себя, то общее желание работодателя запихнуть в одного человека все процессы по раскатке, стейджингу, массовой установке софта на одного человека, который должен не только знать что написано в красивых книжках, но еще и в случае чего дежурить по ночам и поднимать грохнутые тачки в 4 утра, и потом писать отчет почему она грохнулась  Я молчу еще про специфику установки программ, и про то, что в России не очень любят связываться с облаками, т.к. это может чревато для бизнеса. И получается, что чаще ищут человека, который закрывает все вопросы по инфраструктуре, что почти нереально. В обучении и на курсах такие вопросы невозможно затронуть и там многое познается методом проб и ошибок, из-за чего работа получается нервной  Такое первое впечатление у меня сложилось конкретно об этой роли еще несколько лет назад до 22 года. Сейчас вроде бы компании не могут себе позволить просто взять девопса-эксперта и держать его про запас на случай "вдруг пригодится"

ответить

Солидарен целиком и полностью) но проблему вижу в отсутствии просто чёткого разграничения зон ответственности. А даже если оно, вдруг, не позволительно или невозможно, то снижайте планочку, берите двух-трех универсалов, и пусть они растут в своей экспертизе, взаимодействуя друг с другом, со всей системой и прочими подразделениями. Devops - не SRE, SRE - не devops, сисадмин Linux - ни то, ни другое, хоть и может стать и тем и другим, но все всё равно предпочитают валить все в одну кучу и на одну головушку

ответить

еще контент автора

еще контент автора

войдите, чтобы увидеть

и подписаться на интересных профи

в приложении больше возможностей

пока в веб-версии есть не всё — мы вовсю работаем над ней

сетка — cоциальная сеть для нетворкинга от hh.ru

пересекайтесь с теми, кто повлияет на ваш профессиональный путь