Кто я такой, чтобы делиться своими суждениями и утверждениями? Мне почти 47, в сфере IT профессионально работаю около 25 лет, начав самообучение со школы, с папиного i386 с сопроцессором и модемного dial-up на зюхелях (ну... все же помнят.. да? ну да же? :-) Естественно, среди моего опыта и высшее образование, и технические сертификаты, и работа во множестве компаний самого разного масштаба и разных стран. Сейчас я обладаю как негативным, так и позитивным опытом в различных аспектах IT технологий, попробовав себя как в софте, так и в железе.
Этот опыт заставляет меня поделиться информацией из той самой негативной составляющей с целью предотвратить его повторение читателями. И да, тут будет много злобы и яда к тому дерьму тем технологиям, с которыми приходится работать каждый день DevOps и даже системным администраторам. Однако статья наполнена реализмом, а вовсе не пессимизмом! :-D В ней будет раскрыта вся голая правда про лично Ваше будущее как DevOps инженера!
Моя карьера началась с работы у провайдера на горячей линии — помогать пользователям решать их проблемы с подключением к интернету. Потом были шатания от программирования на PHP и Perl до системного администрирования. Долгий путь продолжался от серверных Windows до FreeBSD с Linux как в bare metal так и в облаках и контейнерах.
Мне давно нравилось программирование, но во времена начала IT карьеры меня вводила в ступор всё набирающая популярность парадигма ООП. Переусложнённа, требующая долго разбираться в чужом, невероятно перенасыщенном громоздкими конструкциями коде. Сначала я подумал, что это во мне что-то не так, это не моё, коль меня воротит даже при взгляде на слово “public:”. Правду я осознал значительно позже, но сначала не мог понять, почему ООП вызывает такое внутреннее отторжение. Ведь и глубокое понимание, и использование ООП в коде требовалось буквально от каждого работодателя! Сделав неправильные выводы я начал искать свой собственный путь ронина в других околоайтишных сферах. Именно знания разнообразных операционных систем, маршрутизации и опыт в виртуализации привели меня на профессиональную стезю DevOps инженера. Эта стезя меня вбросила в AWS (Amazon Web Services) за неимением альтернатив в те времена.
Работая так более 10 лет и занимая при этом ведущие технические роли в сфере DevOps крупнейших компаний и банков я словил себя на мысли, что мне это никогда вовсе и не нравилось! И занимался я этим исключительно по причине хорошей зарплаты (при этом тихо завидуя разработчикам, например за несопоставимый уровень ответственности за продакшн).
Нда…. На самом деле меня просто тошнит от DevOps! Эта специализация — редкостное дерьмо и я готов обосновать своё нелицеприятное утверждение!
Первая причина — усложнения. Усложнения всего того, что могло бы быть простым. Усложнения усложнений! Надо больше абстракций! Просто так надо! Просто это модно! Просто так делают все! Потому что вот так! Потому что Кубернетис…
Всегда находится какой-то великий и могучий интеллект к которому прислушивается руководство и который укажет как надо делать «правильно». К сожалению, это ни разу не Оккам. И жизнь показывает — мнением DevOps инженера при этом даже не удосужатся поинтересоваться.
Мало развернуть приложение на EC2-инстансе и обновлять его по ssh. НЕТ! Его обязательно нужно запихать в Docker контейнер, а контейнер в свою очередь всунуть в кластер ECS и обмазать всё в CloudFormation! Был упомянут ECS??? О нет! ECS был уже вчера!!! Сегодня нужен только EKS! Он глючный и плохо интегрирован в остальной зоопарк AWS? Ну и что!? Зато все вакансии для DevOps только с опытом EKS не менее 10 лет. И плевать, что сама технология работает только 6. Любые аргументы против воспринимаются руководством только как саботаж со стороны подчинённого!
Об основной цели вынуть побольше денег из заказчиков AWS сто́ит умолчать, но упомянуть о побочных проблемах в виде сбоев на каждом слое абстракции и не забыть о том, что никто об этом недоразумении не позаботится кроме DevOps. И именно DevOps будет потом за всё отвечать и за всё отгребать всё разгребать!
Вторая причина. Нужно понимать 300500 технологий, иметь в них опыт и всё равно при смене работодателя на техническом собеседовании осознать, что из всего опросного листа можешь уверенно ответить только на половину. Остальное либо уже забыто, либо вообще никогда не встречалось даже по названию. Не менее 300 технологий на одном рабочем месте! Карл! И это не преувеличение хоть цифра и навскидку! А дальше — хуже!
Третья причина. Перспективы углубления знаний в том самом пресловутом количестве технологий. В жизни DevOps инженера мало знать 300 технологий. Через год такой инженер должен будет знать ещё 300, потому что за год выйдет именно столько изменений и старые технологии уйдут на второй план. Жил себе был Elastic Load Balancer, для решения глюков с которым уже понастроено 500 костылей, но НЕТ, он больше не нужен! Построим новые костыли и назовём их теперь Application Load Balancer и Network Load Balancer — любитесь! Как насчёт старых добрых опенсорсных HAproxy плюс BGP на Quagga? Нет, не слышали! Да и зачем такое знать клиентам, если на on premise нельзя их поиметь на деньги?!
Если работодатель пожелает резервировать свою инфраструктуру помимо AWS ещё и в GCP то инженеру придётся разбираться ещё с 3000 технологий, потому что там всё своё и абсолютно непохожее, начиная от терминологии и заканчивая GUI на пару с IaC. Что, опять смена работодателя?! Учите ещё 300 технологий! Например, разберитесь с terraform, но этого сразу будет мало, там же сложная инфраструктура! Поэтому нужен terragrunt, как же без этого, как же без усложнений с дополнительными слоями абстракции? Неужто мало? Но не надо беспокоиться — у следующего работодателя не будет ни первого, ни второго. У него CloudFormation на 30 000 строк IaC кода и всем предыдущим опытом останется только подтереться. Что, опять новый работодатель и опять terraform? Классно же, ведь проходили уже? Но за 3 года забивания головы другими 300 нанотехнологиями уже забываешь нюансы того самого terraform’a и банальные вопросы на собеседовании ставят в тупик…
Как оно в жизни: приходишь в компанию в помощь крутому 20 летнему девопсу, который там уже лет 100 работает и всё-всё знает. В результате оказывается, что от того девопса давно хотели избавиться и он через неделю уходит в закат на вторую работу о которой никто не подозревал, не оставив после себя ни паролей, ни ключей доступа к облаку. Пыхтишь по 12 часов в день без выходных чтобы превратить в конфетку всё то дерьмо проблемную инфраструктуру на которой крутится приложение в продакшене под большой нагрузкой. Терять трафик (значит терять клиентов) категорически нельзя ни при каких условиях, поэтому все изменения делаешь в 3-4 часа ночи по причине минимальной нагрузки на ресурсы. На твой сон и стресс всем плевать, мол, всё оплачено и «ты же понимаешь...». С нуля переделываешь инфраструктуру, переписываешь from scratch весь IaC, автоматизируешь деплоймент новых версий приложения через CI/CD, не спишь ночами когда DDoS и… Как только всё стабилизируется — компания начинает считать, что слишком много тебе платит, а с поддержкой на самом деле может справиться даже джун или те же фулстэки (подумаешь, пару кнопок нажать). И с этого момента всё в карьере DevOps начинается по-новому кругу… кругу ада. И увы, но это даже не самый печальный сценарий…
Подводя итог декады хочу признать, что я спустил в унитаз 10 лет своей профессиональной карьеры, в течение которых я пытался расти и развивать знания как технический инженер в сфере DevOps. 10 лет накопленных знаний, которые через 3-5 лет станут бесполезными! Всё настолько поменяется, что ничего из ныне востребованного НИКОМУ уже не будет нужно.
Пророчу. Придёт какая-нибудь контейнеризация на базе виртуализации написанная не на Go, но на Си и как следствие работающая в 10 раз быстрее... и Kubernetes перестанет существовать! Гугля скинется с майкрософтом, купит Amazon и всё что там есть переедет в GCP/Azure, будучи уничтоженным накорню. Не верится? А кто сейчас помнит про Skype? Ведь до покупки майкрософтом это был лучший мессенджер, который до сих пор никто не смог превзойти по целому ряду уникальных технологий, взять хотя бы распределённые вычисления о которых даже никто не подозревал... Эх...
Что ещё может произойти? Да что угодно! И с нами и с вами произойдут китайцы, например! Но что бы ни происходило, ни у одной из технологий, на которой сейчас базируются знания современных DevOps инженеров, не будет будущего уже в ближайшее десятилетие. Этих технологий просто уже не будет существовать или они перейдут в разряд невостребованных. Остались сомнения? А ну, кто сейчас вспомнит очень популярные в своё время операционные системы AIX, HP-UX (существующие по сей день, кстати) и что произошло с теми инженерами, которые потратили десятилетия своей жизни работая с ними и совершенствуя в них свои знания?
Никогда! Никогда и ни за какие деньги не становитесь DevOps инженером! Это забивание бесперспективным мусором своего мозга и кратчайший путь к выгоранию.
Но что же делать? Разве вообще есть будущее в IT на фоне успехов AI? На этот вопрос персонально я могу ответить только экстраполируя свой индивидуальный опыт на своё же ближайшее будущее и приводя личные рассуждения, которые меня в конце концов привели к текущему окружению и новой профессии.
Я переквалифицировался и стал программистом Си. Всё верно, чистый Си. Ни C++, ни С# — всё это совершенно разные языки, безуспешно пытающиеся использовать имя самого успешного и востребованного, но не имеющие ничего общего с оригинальным Си в своём первозданном виде.
Как уже было упомянуто, повсеместное засилие ООП у меня вызывало недоумение и абсолютное отторжение. Тогда не получалось обосновать даже самому себе зачем так всё усложнять и почему несмотря на проблемы все упорно продолжают прыгать на грабли. Но время шло, я уходил всё дальше от программирования в DevOps и инжениринг операционных систем, но при этом раз за разом мыслями возвращаясь к теме разработки. И вот однажды меня прорвало — я сел и целеустремлённо погрузился в язык программирования, к которому ещё со времён PHP проявлял искренний интерес. Конечно же это Си! На PHP значительно повлиял синтаксис Си (и на самом деле PHP полностью написан на Си), только по этой причине PHP удостоился чести быть тут упомянутым. На этом его персональные достоинства заканчиваются.
Язык программирования Си увидел мир (Hello world) 52 года назад. О да, более полувека! И по сей день остаётся одним из лидирующих во всей отрасли (TIOBE Index). Именно на Си помимо PHP были написаны Perl и Java, Lua и Ruby, а так же ряд других языков. Только впоследствии были добавлены недостатки в виде гарбидж-коллектора, слабой типизации и другие «костыли», приводящие к значительному падению производительности и неконтролируемому расходу памяти под нагрузкой. Особенно в продакшене! Или что ещё хуже — под паразитным трафиком. И не надо мне рассказывать обратного! Уж кому-кому, но мне больше никто не сможет обосновать преимущества перед недостатками вышеупомянутых ЯП, а так же таких как NodeJS, Go, Python, C# и подобных наколеночных поделий «великих мастеров программирования» из другой вселенной, в которой не существует понятий QOS, Scalability, High load и Low Latency.
Си меня заинтересовал в первую очередь отсутствием каких либо ограничений. Ну кто будет писать драйверы на Java или PHP? Правильно, их пишут на Си! GUI? Пожалуйста! Супермейнфреймы? Не проблема! Создавая разнообразные программы я осознал, что это действительно язык вообще может всё! Он может предельно эффективно использовать ресурсы как mp3 плеера с простым чипом, трудиться в виде программ на Вашем лептопе, так и использовать все аппаратные возможности гигантских вычислительных кластеров. Работая с Си мне удалось ощутить радость от открывающихся возможностей и не найти ни одного недостатка. Да, Си не идеален абсолютно, у него есть свои сложности. Например, синтаксис механизма разыменований до сих пор иногда заставляет меня рыдать. Но это только сложность, это НЕ недостаток! Со временем я понял, что все аргументы против Си надуманы теми, кто его просто не знает или ищет оправдание своей безалаберности — один такой шутник ляпнул про ногу, прострелянную с помощью Си (Бьерн Страуструп) а толпа оголтелых подхватила это как знамя и неоспоримую аксиому. Тот же самый шутник пушил всему миру ООП и неплохо в этом преуспел, даже лучше чем любой наркодиллер. И что же оказалось в этой пресловутой парадигме не так? А то, что она просто НЕ НУЖНА!!! И это открытие меня поразило до глубины души. Оказывается, это не во мне проблема, просто мир вокруг сошёл с ума и каждый эффективный менеджер в сфере IT сидит с умным лицом и рассказывает, что без ООП обойтись невозможно. Но он это делает не со зла. Просто у него проблемы с критическим мышлением и отсутствие опыта, которые он компенсирует уверенным взглядом и хорошо поставленным голосом. При этом все умные книжки в один голос вещают, что только с ООП как раз и надо начинать строить любое ПО, особенно для решений бизнес-задач. И вот с этого момента управляемый подобным менеджером бизнес уходит во все тяжкие: винда, .NET, 50 Gb RAM и 10 CPU для программ уровня «Привет мир», и конечно на десерт — вся инфраструктура в облаках с расходами превышающими on premise на один порядок и выше, и вендор-лок в придачу. Может я малость приукрашиваю ради красивого словца, но таких примеров из жизни — легион! Потом проходит время и появляются конкуренты, которые умудрились построить инфраструктуру чуть удачнее и предложить цены уже ниже себестоимости вышеупомянутых монстров с ООП. И всё, бизнес коллапсирует, а эффективный менеджер ищет новую цель для улучшения личного благосостояния и очередного повышения ЧСВ.
На самом деле оказывается, что НЕ нужно буквально ничего, что проповедует ООП! Почему? Да потому, что и без этого всё превосходно работает! ООП «помогает» в работе с огромными проектами? Ерунда! Ядро Linux насчитывает миллионы строк кода и оно написано на Си в простой и понятной детям императивной парадигме, без каких-либо ненужных постулатов в виде инкапсуляций, наследования и полиморфизма; без всех тех костылей типа сеттеров и геттеров, которые являются последствием усложнённых усложнений.
За полвека для Си разработаны тысячи удобных инструментов, от IDE, до отладчиков, статических анализаторов и компиляторов на любой вкус и аппаратную платформу. Ориентируясь в Си даже на начальном уровне освоения уже невозможно просто так взять и выстрелить себе в ногу. Даже самый топорный современный компилятор сразу предупредит о проблеме в строке if (variable = NULL), а такие инструменты как sanitize или valgrind подскажут где проблема с контролем памяти, если это случайно упустит программист. Си универсален. Си 100% переносим и платформо-независим на уровне исходного кода. Он уже просуществовал полвека и будет существовать в своём мало-трансформирующемся виде ещё очень, очень долго!
Будущее Си — парное программирование с AI. Я достаточно интенсивно использую в своей работе современные AI технологии и прекрасно осведомлён как об их достоинствах, так и о недостатках. Пока AI далеки от самостоятельного написания полноценных программ и ограничиваются созданием кода уровнем чуть сложнее «Hello world». Пока нельзя просто так взять и описать для AI программу на 10 000 строк, которую он сгенерирует за секунды. Но учитывая тенденции развития эта ситуация рано или поздно изменится и изобретательские генеративные возможности превзойдут человеческий мозг. Это будет не сейчас и не завтра, но это неизбежно случится. А что же будет когда всё это произойдёт? Программисты уйдут на пенсию? Возможно да, но только потому что им надоест писать на старости лет :-D
На рынке останутся те, кто настолько хорошо разбирается в программировании, что сможет формулировать задания для AI с учётом глубокого понимания алгоритмов; сможет корректировать программы написанные AI, а так же контролировать результат что именно было написано и создавать юнит-тесты, по которым AI будет самостоятельно генерировать код.
На самом деле ничего нового! То же самое можно наблюдать сейчас в современных командах, в которых проповедуют любой из видов парного программирования. Только в будущем человек будет объединён с AI более тесно и такой пары будет достаточно для написания качественного кода.
К чему всё это было сказано? К тому, что в противовес постоянно изменяющемуся и даже, не побоюсь этого слова, ДЕФОРМИРУЮЩЕМУСЯ миру технологий DevOps, мир программирования на Си стабилен и будет таковым ещё очень долго — на век читателей точно хватит. Поэтому отказ от DevOps с переходом в программирование вообще и программирование на Си в частности, стало моим личным выбором. И я рад поделиться своим опытом с читателями.
Комментарии (130)
Wakeonlan
30.04.2024 10:38+6А пожалуй соглашусь, все это похоже на усложение ради усложнения. Классическое нет цели, только путь. Микрософт погряз в перестановке иконок в офисе и смене положения меню пуск в ос. Надо же чем то людей занять, пусть -(плац ломом подметают)- пусть запускают десятую итерацию виртуализации. Это признак стагнации и отсутствия новых идей, но может эра ИИ как то сподвигет мир на более конструктивные действия.
opusmode
30.04.2024 10:38+7Это похоже на усложнение для неспециалистов. А для специалистов очевидно, что это не усложнение, а нормальный процесс работы и есть вполне себе нормальное понимание, зачем так и что будет, если так не делать.
Но, как обычно, находятся умники, которые на ровном месте знают всё лучше всех и вот сейчас-то они расскажут, как делать сложные вещи правильно.
VenbergV
30.04.2024 10:38+2Ох! если бы оно было так.
Заказчик взял сервера в аренду и заказал на них Proxmox кластер.
При профилактических работах, через месяц, видим на кластере Proxmox развернутый k8s. И отдельные VM с LXD контейнерами вперемешку.
Еще через полгода заказчик просит проработать переезд всей инфраструктуры Proxmox в Yandex Cloud. Без изменений в самой инфраструктуре.
А при проработке ТЗ на переезд, со "специалистами" заказчика, пришлось долго объяснять, что FC SAN это не оптоволокно, которое в iscsi может само превратится. И за это надо платить отдельно.
ky0
30.04.2024 10:38+2А что плохого в развёрнутом на виртуалках Кубе? Наоборот, очень удобно мигрировать ноды при техработах или в случае выхода железа из строя. А контейнеры - для каких-то standalone-сервисов, которым важнее низкий оверхед по ресурсам, а не изоляция и live migration, например.
scarab
30.04.2024 10:38Проксмокс сам умеет мигрировать виртуалки в обоих случаях. Не так красиво, как в vSphere, но для маленьких инсталляций вполне сойдёт.
ky0
30.04.2024 10:38Я именно про это и говорю - что можно на время техработ не тушить ноду Кубера, а прямо в онлайне силами Проксмокса просто двинуть виртуалку на соседний сервер.
outlingo
30.04.2024 10:38Если вместо того, чтобы задрейнить ноду, вам проще ее мигрировать, то возникает предположение, что у вас что-то не так в консерватории и вы храните стейт там, где ему не место.
ky0
30.04.2024 10:38+1Вы всё правильно говорите - но бывают ситуации, когда железом, гипервизором и Кубом занимаются разные люди.
IvUs
30.04.2024 10:38+21Почему-то вспомнился Ф.Кривин "если бы я был горностаем"
Про Си прям набор сопливых легенд. "Си 100% переносим и платформо-независим на уровне исходного кода." Ну что, удачи. Осталось только найти работодателя-фаната pure C.
Caefah Автор
30.04.2024 10:38+2Сам удивился что это возможно, но вспомним рейтинг TIOBE. И как результат анализ рынка на linkedin по моему региону:
* 30 вакансий в день Senior DevOps Engineer. На каждую вакансию около 5000 резюме
* 1 вакансия в 3 дня Pure C Developer, на каждую максимум 10 резюме
Посчитаем вероятность:
30/5000 = 0,006
0,3/10 = 0,03
Можно сделать смелое предположение, что найти работу Pure С разработчика почти на порядок проще.
Fedorkov
30.04.2024 10:38+1Если верить TIOBE, Фортран на 10 месте по популярности, а TypeScript - на 48.
найти работу Pure С разработчика почти на порядок проще.
Вам было сложно найти себе работу? Если нет, то ваши расчёты нерелевантны.
Revertis
30.04.2024 10:38+17Насчёт ООП вы не правы от слова совсем. Вы его не поняли, не поняли то, где его очень удобно применять. Например, при написании библиотеки GUI.
Насчёт Си - вы слишком сильно радуетесь, и слишком верите всем этим инструментам в плане безопасности - 75% уязвимостей связано с ошибками управления памятью, и аргумент опыта и внимательности просто не работает. Если компилятор не ловит такие ошибки, то жопа обязательно будет.
Так что лучше уж изучить Rust, хотя бы будете писать безопасные программы. Кстати, в Расте нет ООП ;)
Caefah Автор
30.04.2024 10:38Ой, ну всё! Уже и сюда его вставили, этот Rust! Mozilla Firefox был прекрасным браузером, но ровно до тех пор, пока его не переписали на этот самый невероятный Rust, после чего Firefox превратился в тормознутое дерьмо: что CPU жрёт как не в себя, что RAM. Достаточно открыть 5 окон с десятком вкладок и всё, от 32Gb RAM ничего не осталось и Load Average 15!
Раньше долго мигрировал на MF, теперь не знаю как от него избавиться...хотя бы будете писать безопасные программы
Я пишу безопасные программы и на Си тоже. Достаточно понимания каких ошибок нельзя допускать. Для этого есть книжки и даже не сильно толстые.
И ни какой Rust не спасёт от логических ошибок, сделанных самим программистом. В результате код на любом языке станет небезопасным.Revertis
30.04.2024 10:38+15Mozilla Firefox был прекрасным браузером, но ровно до тех пор, пока его не переписали на этот самый невероятный Rust, после чего Firefox превратился в тормознутое дерьмо
Сразу видно человека, который совершенно не в курсе как пишется ПО.
Во-первых, там переписано на Раст очень мало, например только движок CSS (Stylo) и какие-то кодеки. Во-вторых, как будто одновременно со вставкой этого движка НИЧЕГО другого в браузере не менялось, да? :) Никакие другие стандарты не реализовывались, UI не переделывался, и т.п.
Достаточно открыть 5 окон с десятком вкладок и всё, от 32Gb RAM ничего не осталось и Load Average 15!
У меня месяцами ФФ открыт с десятками вкладок, обвешан кучей расширений, и жрёт не больше 3-4Гб. Что-то вы готовить не умеете.
Я пишу безопасные программы и на Си тоже. Достаточно понимания каких ошибок нельзя допускать.
Да-да, инженеры Гугла и Микрософта тоже крутые, но даже у них тысячи ошибок и CVE в основных продуктах. Этот аргумент НЕ РАБОТАЕТ.
И ни какой Rust не спасёт от логических ошибок, сделанных самим программистом.
С этим никто не спорит.
uhf
30.04.2024 10:38+4У меня месяцами ФФ открыт с десятками вкладок, обвешан кучей расширений, и жрёт не больше 3-4Гб
Они все сейчас выгружают неактивные вкладки из памяти, то есть совсем. Хорошо, если на диске в кэше останется, а то иногда откроешь старую вкладку - а там уже 404. Оптимизация, которую мы заслужили.
xkb45bkc4
30.04.2024 10:38а то иногда откроешь старую вкладку - а там уже 404
Мне хром постоянно предлагает оптимизировать память и выгружать вкладки, видать не зря я отказываюсь.
Dimly
30.04.2024 10:38+1Не.. ФФ реально ногами писанный. Я его все еще использую, вместе с остальными, но буквально недавно исправленный баг, с которым я более года промучался - открытый на паузе сезонвар (видео) отьедал за пару часов 10+ гигов. И хто не кеш фидьма, хз что это. Оставлять надолго ФФ было категорически нельзя, если афк. Сейчас глянул - уже норм, но было же.
Когда будет группировка вкладок? Запуск несколько инстансов с разными профилями? Это все нужно.
ivan386
30.04.2024 10:38Несколько окон Firefox с разными профилями давно использую одновременно. Или речь о том чтобы в одном окне вкладки с разными профилями были?
Frankenstine
30.04.2024 10:38Когда будет группировка вкладок?
https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/
mmaks17
30.04.2024 10:38+14Человек занимался не любимой работой, соответственно делал все от балды тяп ляп и не разбирался зачем оно все нужно.
А тем кому нравится тоже уходить да )?
Caefah Автор
30.04.2024 10:38+1соответственно делал все от балды тяп ляп и не разбирался зачем оно все нужно
Напротив, делал всё тщательно и старательно, как и должно быть у перфекциониста. Проактивность, личная ответственность и все остальные атрибуты современного результативного подхода к работе. И моментами даже нравилось, особенно когда попадался по-настоящему интересный проект, в котором работодатели давали волю для самовыражения и творческого подхода.
Но контекст статьи не в том, что нравится, а что нет. Тут поднимался вопрос перспектив "А что будет дальше в мире DevOps?". Если я для себя чётко могу ответить на этот вопрос в контексте Си, то по теме DevOps у меня логического ответа вообще нет, одни негативные эмоции.
Я ведь не зря указал свой возраст. Когда мне было 20 — было интересно буквально всё! А теперь ценности сильно изменились и прошлые интересы оцениваются в первую очередь критически, и только потом с любых других ракурсов. Сейчас я смотрю на технологию только с точки зрения личного интереса: сколько я могу на этом заработать денег? Могу ли я расти как специалист, углубляясь в технологию? Пригодятся ли мои знания другим работодателям? В Си можно расти и развиваться всю жизнь, язык сильно переплетён с аппаратной составляющей, мир которой преображается не за годы, но за минуты. Взять тот же ИИ, в бэкграунде которого важна предельная производительность и экономия ресурсов.А тем кому нравится тоже уходить да )?
Решение принимать только Вам. Лично я давно перестал видеть перспективы в DevOps. Там просто некуда расти. Если под "расти" не подразумевать добычу опыта в борьбе с глюками очередной технологии от Amazon. Разобраться в каком-нибудь AWS Glue? И зачем всё это лично мне? Чтобы через год появилось очередное индусское говноподелие типа AWS Athena или AWS Glue DataBrew и по прихоти очередного умника ("Только это спасёт наш бизнес") перейти уже к борьбе с их багами? Так себе "интересная работа"...
Поэтому я параллельно учил программирование и пока ту самую упомянутую интересность вижу только в этом направлении.
AlexeySetevoi
30.04.2024 10:38+9Вы просто устали от одной сферы работы и хотите пойти в другую сферу.
Статья - это эмоциональное обоснование выбора, но с набросом, чтобы немножко пожечь напоследок.
Потом можно будет написать еще одну, когда выяснится, что мир чистого C существует только издалека, а реальность несколько более блекла.
И что перфекционизм не всегда нужен и не всегда оплачивается в обоих помянутых сферах. Но очень сильно вытягивает силы.Нет и не будет, полагаю, проблемы быть консервативным инженером, работающим по методологии Devops, которая внезапно, не только и вообще не про тысячи новых технологий и переизобретений.
У нас стек технологий на уровне теории не менялся с конца 70х, если внимательно посмотреть.
И верхнеуровневые паттерны тоже.Были неймспейсы в позднем юникс 80х, а сейчас это одна из технологий под капотом контейнеризации.
Виртуализацию теоретически изобрели/обосновали тоже где-то в 60х, но кому-то она перевернула мир сильно позже.
И так далее. А новое под этим солнцем случается, но не столь уж часто. Проекты для резюме случаются гораздо чаще и нужно просто отличать первое от второго.
Ну и отсылки, что ECS стало вдруг не модно - его заменил EKS, как пример - прекрасны. Если что, между их релизами толи 6, толи 8 лет. И ECS до сих пор живой, и не помню, чтобы задепрекейченный. Нет необходимости бежать с горящими пятками, если вас устраивает ECS. И так почти во всем.
В приведенном примере про более быстрый в 10 раз Кубер - ну вообще не очень. Кому он нужен, в 10 раз более быстрый? Это оркестратор. 99% времени кластеру он не нужен, после запуска и вообще не участвует, пока все хорошо. Поэтому его x10 никому не нужно, кроме чистой теории. Если речь про контейнеризацию под капотом - она как бе опирается на ядро линукса. И на его механизмы. Быстрее в целом некуда и не за чем(потому что накладные расходы в рантайме на контейнеризацию исчезающе малы). Еще раз - там под капотом технологии, запиленные в начале 90х-00х в ядро линукса. В основе. И до сих пор работает, незаметно модернизируясь и сохраняя совместимость.Нормальная инженерия, она про то, что вам надо минимальными ресурсами/технологиями закрыть требования, чтобы работало. Переписывание всего на последную супер-технологию, выпущенную Васей(да простят меня все Васи) - вчера - это какая-то не инженерия. Там про требования ничего нет.
Caefah Автор
30.04.2024 10:38+2Статья - это эмоциональное обоснование выбора
Я искренне жалею о том десятилетии, которое я слил на DevOps. Поэтому статья — скорее предостережение другим. Чтобы помимо восхваления этого пути в других публикациях (особенно от крупных компаний, заинтересованным в специалистах) у интересующихся был выбор мнений.
feelamee
30.04.2024 10:38меня так забавляет, когда люди обесценивают опыт другого человека словами "вы просто....".
А может это вы просто не поняли автора на самом деле? будь то по вашей или его вине.Не стоит так делать. Лучше говорить "Я не согласен. Мой опыт сильно отличается от вашего.". Так вы выскажете ту же точку зрения, но не покажете будто ваша более "правильная/правдивая", чем автора.
У нас стек технологий на уровне теории не менялся с конца 70х
теория это далеко не все
Да, вам будет легче учить новые технологии, так как база одна с 70х годов. Но это никак не исключает факта, что в каждом из этих велосипедов есть нюансы/bad practice/best practice, которые нужно знать.
Нет необходимости бежать с горящими пятками, если вас устраивает ECS
Вы приходите в компанию и она уже не использует X, а использует Y.
Ваши действия
убедить всех, что нужно X, а не Y; потратить много много часов на то, чтобы сделать X.
научиться работать с Y
Для меня тут очевиден факт того, что второй пункт наименее трудозатратен
Dimly
30.04.2024 10:38Я только клаырять начал докуры-херокеры, но в голове та же мысль -и нафига так сложно?
Не, ну понятно - изоляция... Развертывание... Но проще можно было.
А то что в каждом втором резюме аисты пишут что они девопс, а сами тянут образ альфрески и ВЕСЬ контент файловый оставляют в контейнере, как и бд. Я же правильно понимаю что так нельзя?
opusmode
30.04.2024 10:38+8Не понимаю, а что сложного в докере?
Вы берёте консоль, берёте код, выполняете команды, получаете нечто.
В докере вы делаете тоже самое - берёте файлик и описываете теже команды, манипулирующие кодом, но в него.
Далее вам больше не нужно ставить на сервер ничего, кроме докера, так как у вас приложение взяло, оба-оба, сбилждалось на раннере и вы получили готовый контейнер. В автоматическом режиме. И это будет каждый раз, раз за разом.
Прикиньте, не надо настраивать окружение, не надо билдить на сервере. Просто получаем готовое приложение, которое уже сбилдилось.
Ну, да, наверное можно было проще. Только мы сэкономили на спичках, чтобы заплатить за это стоймостью крыла самолёта.
И да, вы правильно понимаете, что так нельзя. Ну, много чего нельзя и много кто чего пишет. Главное, кто и чем является. И хреновые специалисты это не проблема методологии, это проблема того, что у нас готовят хреновых специалистов, которые делают тяп-ляп
scarab
30.04.2024 10:38+2Только всё то же самое было изобретено десятилетия назад в виде пакетов. deb, rpm, pkg и так далее.
Беда докера не в нём самом, а в том, что контейнерная виртуализация - это мощная, но всё ещё сырая технология, идущая путём проб и ошибок. Те, кто начинал работать с докером давно, помнят его нестабильность на первых порах, помнят глюки unionfs и aufs. Ну ладно, за 10 лет стабилизировали в виде overlayfs. Потом выяснили, что собирать в докере небезопасно и придумали отдельно buildah и buildkit, заодно придумали podman и runc и задумались - а зачем тогда, собственно, докер?..
Я уж про оркестрацию не говорю. Docker compose, docker swarm, rancher, nomad, кубер-мать-его-нетес и openshift. Ну куда столько, а главное - зачем? И всё это отомрёт ещё лет через 5, а придёт что-то новое.
Я согласен с автором в том плане, что возраст даёт представление о ретроспективе. Между 20 и 25 - пропасть, между 40 и 45 - не так уж и много. Банально эти все технологии воспринимаются как бабочки-однодневки, когда ты в профессии 30 лет.
Frankenstine
30.04.2024 10:38+2И всё это отомрёт ещё лет через 5, а придёт что-то новое.
А вы думаете, почему оно отомрёт? Да потому, что выживает более удобный и лучше работающий инструмент. Однако, как он становится лучшим? А в конкуренции с другими... Это всё естественные процессы, как эволюция обезьяны. Без криворуких обезьян как промежуточных предков, человека не возникло бы. Жаловаться, что приходится эволюционировать - примерно как жаловаться, что дождь идёт.
Caefah Автор
30.04.2024 10:38+2Теория Дарвина не всегда работает в IT. Иногда появляются такие уродливые монстры, которые, казалось бы, не имеют права на существование. Но за неимением альтернатив они не только живут и умудряются развиваться, но на их базе строят других монстров. Пример — Java, которая написана на Си, и Scala, которая написана на Java... Почему просто не писать на Си? ;)
P.S. Чувствую, за джаву мне сразу снесут карму, несмотря на смайлики. Надо было привести другой пример... Может котика приаттачить? :-D Не не поможет?
Frankenstine
30.04.2024 10:38+2Почему просто не писать на Си?
Потому что это более трудоёмко. То, что уже написано на Яве (ненавижу), ещё никем не написано на сях. Вот когда напишут - тогда и отомрёт старое. Эволюция, однако.
ALexhha
30.04.2024 10:38+3А тем кому нравится тоже уходить да )?
Вспомнилось
Хаус: Форман увольняется
Вилсон: Почему ? Что случилось ?!
Хаус: Сказал не хочет закончить как я
Хаус: Я остроумно возразил, только не помню как
Вилсон: Что сам не хочешь закончить как ты
Хаус: Именно! Мне тоже уволиться ?
opusmode
30.04.2024 10:38+24Статья какой-то сумбурный высер. Я уже разбирал с пяток подобных и извините, но сегодня у меня выходной, мне лень.
Скажу ровно 2 вещи:
Становится DevOps-инженером действительно не надо. DevOps это методология. DevOps-инженер звучит так же нелепо, как Kanban-менеджер. Нужно становится просто инженером по инфраструктуре.
-
Чел, извини, но тебе 47. Я всегда говорю, что сейчас у ИТ есть 2 проблемы - динозавры 40+, которым всё сложно и которые цепляются за то, к чему привыкли, отрицая что-то сложнее деплоя по ftp и малолетние смузихлёбы, которым всё сложно и они ненавидят всё старое, при этом готовы внедрять любую вышедшую неделю назад 0.0.1 pre-aalpha в проект, просто потому, что вышла статья на хабре на 10 плюсов.
В итоге у первых есть фундамент, но нет развитие, у вторых нет фундамента, есть просто тяга к блестяшкам.
Хотите стать инженером? Становитесь. Хотите заниматься инфраструктурой - окей, круто, давайте к практикующим специалистам, объясним концепции, научим думать, считать и реализовывать. Расскажем, что, как, почему и в каком случае делается, какие есть критерии, зачем нужны все эти абстракции и "усложнения" и к чему вы придёте, поленившись или "упростив" на ранних этапах (спойлер - к пересборке самолёта в процессе полёта и просиранию кучи денег и времени).
И это не реклама курсов, мне ваши деньги нафиг не упали. Это приглашение в сферу от практикующего специалиста, который в своём деле немного так понимает. Не бойтесь, заходите. На своём пути вы встретите много слабых специалистов, но встретите и много хороших и годных
Caefah Автор
30.04.2024 10:38+6Статья какой-то сумбурный высер
Зачем же так грубо? Статья — частное мнение, не претендующее на объективность, но оппозитное тем восхищённым хомячкам, которые в основном пишут тут на хабре про технологии не успевшие им набить оскомину.
Чел, извини, но тебе 47
Ну что-же, буду рад услышать обновлённое мнение уже к Вашим 47 :-) Тем более, будет время проверить озвученные тут утверждения.
Dimly
30.04.2024 10:38+10Зумеры такие умные пошли... Все что у вас есть - сделано динозаврами.
Tony-Sol
30.04.2024 10:38Все что у вас есть - сделано динозаврами.
Получается, тот же kubernetes тоже сделан «динозаврами»? А как тогда назвать «динозавров» считающих «он нам и на…й не нужон, кукаретис ваш!»?
scarab
30.04.2024 10:38+1Одно другому не противоречит. Кубернетес штука хорошая, но применять его нужно там, где в нём действительно есть потребность. Если у вас кровавый энтерпрайз типа одноклассников или вконтактика и целая команда сеньор-девопсов по сопровождению этого добра - да, применение кубера оправданно. Но его ж пихают куда только можно, я встречал проекты на десяток контейнеров на одной ноде - и для оркестрации подняли k8s, потому что "это модно" и "все так делают".
Tony-Sol
30.04.2024 10:38+3Иронично, ведь я работал во вконтактике как раз в devops команде сопровождения кубера) Да, это было оправдано, но и на проектах кратно меньше, тоже предпочел бы кубер альтернативам типа swarm
scarab
30.04.2024 10:38Вопрос в стоимости сопровождения. Кубер требует достаточной квалификации и хотя бы одного выделенного девопса. А это сразу +400-500к к ФОТ. Тогда как compose или swarm вполне может освоить приличный разраб.
Вообще, вот Ваше мнение опытного человека - начиная с какого масштаба инсталляции Вы считаете оправданным применение k8s?
Tony-Sol
30.04.2024 10:38+2ИМХО, если разраб сумел освоить compose и/или swarm, то сможет и k8s на уровне, достаточно для локальной разработки/базового понимания как работает его приложение.
Кубер требует достаточной квалификации и хотя бы одного выделенного девопса
Это довольно спорно и сильно зависит от процессов.
начиная с какого масштаба инсталляции Вы считаете оправданным применение k8s
Тоже очень скользкая тема и все зависит от множества факторов - есть ли экспертиза, какая стратегия развития, какой план роста, какой продукт и тд и тп.
Далее, сугубо мое ИМХО и только в рамках web разработки: Так, например, считаю что k8s оправдан практически всегда, когда речь идет о развертывании собственного продукта. От ботика в телеграмме, до соцсети. ("Сайтик на тильде" в моем представлении продуктом не является, продукт там это сама тильда и я почти уверен, что под капотом там тоже кубер).
Ведь за абстрактным k8s может быть много реализаций - это может быть single node инсталяция (вон k3s позволяет в пару команд организовать решение), свой полноценный кластер или облачный кубер.
В этом и вся его прелесть, что сегодня, например, mvp вашего сервиса, внутри k3s на одной виртуалке, а завтра в полноценном кластере в облаках. При этом со стороны сборки/развертывания приложения скорее всего практически ничего не меняется - правильно написанный манифест (helm-чарт/helmfile/helmwave.yml/werf.yaml - тысячи их) почти наверняка будет работать.
Kubernetes - просто еще один инструмент, привносящий слой абстракции, а как говорится:
Любую проблему можно решить введением новой абстракции. За исключением проблемы чрезмерного количества абстракций.
Для кого-то - серебряная пуля (9000 stateless микросервисов с rest api по 3.5 эндпоинта), для кого-то - сущий кошмар (базы данных в кубах это ОЧЕНЬ больно)
ALexhha
30.04.2024 10:38+2Кубернетес штука хорошая, но применять его нужно там, где в нём действительно есть потребность.
не поверите, но это относится к любой технологии/языку ;)
vp7
30.04.2024 10:38Ирония а другом - вы вместо адекватного и простого init везде суëте монстроидальный systemd, но оправдываете это тем, что "это не я, это разработчик ОС принял такое решение, а я лишь жертва обстоятельств" (не виноватая я, он сам пришёл).
Но при этом отказываете другим развернуть куб (который концептуально не особо сложнее systemd) там, где они хотят.
Куб может быть оправдан в виде minikube на raspberry Pi (если на то есть причины, возможно даже просто "мне по фану"), а может быть совершенно лишним в кластере на сотню серверов. У каждого инструмента есть свои задачи и области применения.
ALexhha
30.04.2024 10:38+1Но при этом отказываете другим развернуть куб (который концептуально не особо сложнее systemd) там, где они хотят.
ну да ну да
Xeldos
30.04.2024 10:38+6динозавры 40+, которым всё сложно и которые цепляются за то, к чему привыкли, отрицая что-то сложнее деплоя по ftp
Динозавр-программист 45лвл итт. На последней работе сознательно внедрил докер, и слал в пешее эротическое сисадмина-смузихлёба, который ныл "зачем так сложно". Просто потому что я ЗАДОЛБАЛСЯ "деплоить по ftp". Я задолбался от монотонной ручной работы. Я задолбался от бесконечных ошибок, когда правую панель перепутали с левой, когда сделали git reset --hard не в той репе, когда всё правильно перенесли, но забыли что надо снести одну старую системную библиотеку и добавить две новых. И я даже до docker swarm дошёл, ради бесшовного обновления. До кубера не дошёл, там сразу скачок кривой сложности, и ничего близко похожего на кластер у нас не было, и ресурсов не вагоны, вся инфраструктура хорошо если десятилетней давности, то есть десятилетней на момент моего прихода.
Да, и к картинке ниже - я мечтал об ансибле или чём-то похожем, чтобы управлять хранением настроек инфраструктуры и автоматизированно её разворачивать. Но наш админ на мои намёки ныл "зачем так сложно".
Всё это, блин, нужно, как только начинаешь заниматься реальными задачами, а не форумами на phpbb, которые упадут - туда им и дорога. Когда у тебя в казалось бы не очень большом проекте две сотни открытых тикетов не предел, и три одновременно решаемых задачи у разработчика - не предел, начинаешь задумываться об управлении этим всем. Автоматизированном управлении. Когда ты понимаешь, что абстракции даны тебе в ощущениях, они есть в бизнес-процессе, который ты автоматизируешь, ты начинаешь скулить "а вот были бы в моём языке хотя бы интерфейсы, и чтобы типизация была построже и чуточку более явной".
rusik2293
30.04.2024 10:38+2Так и не понял как вам докер помог с git reset не в той репе и ручной работой.
Anarchist
30.04.2024 10:38+4Динозавр 50. По мне так проблема в обилии молодых "специалистов", пришедших в профессию за легкими деньгами. Вот они и начинают ныть в стиле автора исходной статьи.
vp7
30.04.2024 10:38+2А динозаврами становятся вот прям ровно в 40? ;))
Мне 43 и я себя как-то не считаю динозавром. Да, есть некоторое занудство - к примеру, если по правилам компании запрещено деплоить в прод в пятницу вечером и вообще есть процесс деплоя (включая согласования руководства), то бью по рукам коллегам, которые хотят выкатить что-то в прод забив на процедуры по принципу "да ладно, я так 100 раз делал, ничего не падало". Но процедуры на то и процедуры - либо иди и согласовывай их изменение внутри компании, либо выполняй.
В остальном вроде всё норм, отлично разбираюсь с новыми технологиями и новыми направлениями, а имеющийся за плечами опыт позволяет сразу же смотреть на потенциально проблемные места.
HellKaim
30.04.2024 10:38+10Присоединюсь к комментаторам выше.
Я с вами согласен, что в DevOps не нужно идти, если ты не любишь копаться в дерьме. И знаете почему?
Да по тому, что DevOps и есть та половая тряпка, которая подтирает за всеми, у кого пролилось. А проливается - у всех.
Я начинал как Sparc инженер, сертифицирован по Solaris9 и на Sun железе. Но тогда был другой мир. Приложения были локальными, сервисы - монолитными. Был жёсткий вендор-лок и шаг влево, шаг в право был подобен смерти: нет поддержки (она, конечно, не покрывает убытки, но даёт иллюзию что твою, даже самую-самую зубодробильную, проблему решат), нет резервирования, ты должен был всю команду держать у себя, вместе со всем железом, кабельными журналами и этим вот всем.
Порог входа был огромен, smb отличался от enterprise как рисунок 3хлетки от Ван Гога.
И вы знаете что? Всем надоело. Надоело держать команды, платить вендорам, строить свои ЦОД и содержать кабельные журналы в более-менее актуальном состоянии. А это магическое слово Veritas и Oracle RAC...
То, что сегодня есть 100500 мультонов решений, которые вообще как-то друг с другом интегрируются и на них можно запускать почти любые поделки любой макаки - удивительно уже само по себе. Я не жалею что все это появилось.
Докер был ошибкой с самого начала, но небыло и нет ничего, что бы его заменило. Не в плане техническом, а в плане использования, ценности, которую он "создаёт". А далее эффект снежка - чем больше индустрия адаптировала, тем больше на это завязывались.
Дошло до страшного - найти людей, которые бы могли "руками" держать сервисы через докер и гит - почти невозможно. Всем подавай Амазон, Кубернетис и это вот все.
Когда я показываю решение, которое работает почти на баш портянках, на меня смотрят как на инопланетянина. Но, я так же понимаю, что это все на "моих масштабах". Если бы мне нужно было это все масштабировать - я бы ушел в тот же Амазон. Потому, что AWS создаёт ценность только на масштабе. Если у вас его нет, не нужно туда соваться.
Мы все - жертвы маркетинга и DevOps их самое кровавое воплощение. Пока мальчики в кедах и худи слушают сказки про космические корабли, девопсятина, как Титаны - держат это все от неминуемого коллапса.
Нет, современное ИТ это не про инженеров, это про макак. Я не утверждаю, что разработчики или те же DevOps не могут быть супер профессионалами, но тренд - на прикладывание красного кубика к синему тетраидеру. Профессионализм в том, знает ли данный индивид каким клеем это склонять и при каких условиях оно будет держаться.
Мы больше не можем позволить себе роскошь затачивать катану, нас нужно быстро бежать.
AI, в конечном итоге, слизнет эту всю пену и снова будет время крутых спецов, которые могут решать сложные задачи зная узкий стек. Это не так далеко как кажется. Мы, конечно, ещё посопротивляемся, но DevOps будут вторыми или третьем, кого слижет. Так что да - не стоит туда идти.
Если меня бы спросили дети "Папа, мы хотим в ИТ, чё делать?", я бы порекомендовал им идти в разработку аппаратного обеспечения, в "железячники". Если конечно, они не могут на, условный, мехмат. Тогда не вопрос - будут заниматься AI, или ещё какой-то корневой технологией, на которой все крутится в их "будущем" мире.
А системный администратор как был дерьмовой работой, так и остаётся дерьмовым DevOps
rjeka
30.04.2024 10:38+4Дошло до страшного - найти людей, которые бы могли "руками" держать сервисы через докер и гит - почти невозможно. Всем подавай Амазон, Кубернетис и это вот все.
По моему опыты на такие проекты не найти людей, потому что никто не хочет идти , а не потому что нет тех кто разбирается в докере, гите и башеписании. Просто мало желающих идти в проект с костылями и велосипедами на баше. Так как чаще всего автор этих костылей и велосипедов уже отсутствует в проекте , как и какая либо документация с мониторингом. Но деплой то нужен сегодня, и все это превращается в операцию с даунтаймом, страшным сном суппорта, и требующую решительности, отваги и поиска кого нибудь кто хоть примерно представляет как это работает. А бизнес считает, что мы нашли аж целого DevOps инженера (модное слово же) и сейчас он нам все сделает как в той книжке которую гугл в свободный доступ выложил.
HellKaim
30.04.2024 10:38+1Ой, смотрите, как мы в два присеста докатились до понимания, что всякие HAproxy "в чистом виде" это проблема!
Оказывается, обёртка нужна для того, чтоб экономить ресурсы по средством стандартизации реализации и разделении труда. Разработчики ELB за нас уже написали все башпортянки, задокументировали это все и куча народу уже это поковыряла, заполнив Stack overflow своими знаниями.
Я даже больше скажу - попробуйте попросить архитектора "брат, а давай твои орлы сами напишут объектное хранилище, ну че там, пару картинок сохранить!".
Caefah Автор
30.04.2024 10:38+1Вам удалось гораздо лучше и без эмоций выразить все те мысли, которые я хотел донести. Благодарю.
Kotmanul
30.04.2024 10:38+3Вот за обзывание работы системного администратора было обидно.
Caefah Автор
30.04.2024 10:38+1Позвольте предположить из контекста, что в оригинале фраза должна была иметь несколько иной смысл: "Работа системного администратора как была невероятно сложной, скучной и недооценённой, так и остаётся таковой, но уже в ключе DevOps и облачных инфраструктур". Всё точно @HellKaim? ;-)
HellKaim
30.04.2024 10:38Ну почти.
Я никогда не понимал чистый случай сисадминства.
Вот у вас в системечто? Она самоценна? Стоит шкаф, на нем система, в ней... Что, постоянно происходит тюнинг каких-то параметров? Подкручиваем susctl и vm.options?
Во времена системных инженеров, это было управление оборудованием, параметрами драйверов и сетевого стека. Где это нужно - баллансировщики, системы сетевой фильтрации, сервера БД, редко - сторадж серверы.
Все остальное это мышкование с софтом или настройка Group policy. А если это мышкование с софтом, то это уже не системное администрирование, а деплой или саппорт конкретного софта
Но, и я писал об этом, у нас теперь не страшный вендормонолит или WebSohere - у нас теперь чудо дивное вон тех ребят из соседнего опенспейса. Они и сами не очень знают что они делали в прошлую пятницу, так как уже новый спринт, Продакт зубами скрипит и саппорт подпирает свежими тасками.
Это - не системное администрирование уже ни разу. И, как выясняется, если нужен на фултайм человек, который будет "чисто системами заниматься" - юзаерей заводить, или бдшки разворачивать, он сам себе башпортянки напишет. А если их несколько и один - со знанием С, он ещё и свою собственную систему мониторинга запилит (я не шучу, а рассказываю о 2000х годах и тяжёлых юникс сетапах).
А потом что-то пошло не так, эти самопальный баш/С поделки всех достали и им на смену пришли Телеграфы, Кубернетись, Ансамбли и Докер.
А потом и это всех достало и пришли облака, в виде Амазона и присне.
И наш сисадмин, который и так-то копался ток с виндой, так как только там и был нужен, по сути, совсем погрустнел. Системные инженеры вымерли как класс и на их место пришли люди-оркесиры, которые умеют это все вместе собирать. Правда, вместо своей башпортянки они мучаются с десятком-другим чужих.
Amadey17
30.04.2024 10:38+2Сколько я уже встречал разрабов, которые без DevOps сами не могут развернуть докер или подобное. Я уж молчу про k8s. DevOps нужны, и необходимы. Но это не должна быть затычка в каждую дырку. Всё должно быть по делу.
HellKaim
30.04.2024 10:38Это-то и пугает.
Разработчик, который не щупал среду в которой его софт будет крутиться... Да что я вам рассказываю.
Именно по этому я и писал - DevOps за всеми подтирает.
Есть ли места где все ок - безусловно! Много ли их - достаточно. Но, в среднем по больнице - мрак и ужОс.
Amadey17
30.04.2024 10:38+1Ну я больше к тому, что каждый должен выполнять свою задачу. А щупать должны уже QA. Представим что разраб будет выполнять весь стек и обязанности DevOps. Можно будет забыть что какой-нибудь софт когда-нибудь выйдет.
cyberbolt
30.04.2024 10:38То есть, компилируется - можно дальше тестировщику перекинуть, пусть сам разбирается как это запустить?
Tony-Sol
30.04.2024 10:38+1Докер был ошибкой с самого начала
Искренне не понимаю почему, но буду рад понять
но небыло и нет ничего, что бы его заменило
Был LXC (или вы про другое), сейчас есть CRI и его реализации
HellKaim
30.04.2024 10:38Искренне не понимаю почему, но буду рад понять
Потому, что реализация кривая. В данном случае я про сетевой стек. Настроить фильтрацию трафика для конкретного контейнера ещё те костыли. И там ещё можно накопать при желании, которого нет. Мы все знаем что это достаточно стремянок поделье, но таков путь. Докер появился как срочный ответ на назревший вопрос. И кривость этого ответа была меньше чем запрос.
Был LXC (или вы про другое)
Я про то, что когда вы идете в любой проект, там в условном README написано docker compose up, а не lxc launch.
Почему так получилось, вопрос к историкам индустрии. Сегодня есть flatpack, appimage и даже snap, которые лучше со всех точек зрения, но мы продолжаем плодить докеры, так как они прощают нам гораздо больше, чем описанные выше вещи. Они почти такие же добрые как и виртуалки.
Tony-Sol
30.04.2024 10:38Сегодня есть flatpack, appimage и даже snap, которые лучше со всех точек зрения
Но ведь это же вообще другое - это альтернатива распространению пакетов, apt/dpkg/pacman/итд, с докером никак не связанная
HellKaim
30.04.2024 10:38А докер, простите, тогда что?
Tony-Sol
30.04.2024 10:38+1Средство виртуализации. И нужен он в первую очередь для изоляции окружения, а не распространения пакетов. Внутри контейнера вы можете использовать flatpack/appimage для создания окружения, а наоборот - сомнительно. (UPD - да, есть whalebrew например, но это скорее исключение)
HellKaim
30.04.2024 10:38+1Все верно, средство изоляции, точно так же как и апаимадж.
И сегодня докер - среда распространения приложения в изолированной среде.
Вы один раз собрали апаимкдж и распространяете его на свои кластеры.
Не, не подумайте, прелесть докера это его обвязка и эти докфайоы, которые инструктируют докер и его окружение как-то верно себя вести. Именно они делают самый фарш в докере, а не его изоляция.
У аппимаджей и флатпаклв этого всего нет, есть только изоляция.
Если интересно, как это "могло бы быть" - смотрите Lutris.
Tony-Sol
30.04.2024 10:38У аппимаджей и флатпаклв этого всего нет, есть только изоляция
Только для случая, например "пакет A использует openssl@1, а пакет B - openssl@3".
Изоляцию уровня "веб-серверу A я доверяю 0.5 cpu и запрещаю ходить в файловую систему хоста, а веб-серверу B я разрешаю ходить за данными на диск, но только сюда и только для чтения" средствами appimage/flatpack/итд не обеспечить - потому что это разные абстракции и разные изоляции.
Изоляция, про которую docker, можно сделать и нативными средствами linux (на хабре есть хороший цикл статей про это https://habr.com/ru/articles/458462/)
ALexhha
30.04.2024 10:38С каких пор докер стал виртуализацией ?
Tony-Sol
30.04.2024 10:38Контейнерной виртуализацией. Контейнеризация это тоже виртуализация, просто на другом уровне абстракции - не вне ОС, а внутри нее.
budnikovsergey
30.04.2024 10:38linux cgroups вместе со связанными механизмами это вообще не виртуализация. И Любой контейнер технологически ничем не отличается от system-unit, почему собственно при запуске контейнеров нет никакой привязки к собственно продуктам docker, podman и подобным. Более того, большинство фич, приписываемых контейнерам докер полностью доступны для настройки для любого systemd-unit. Накладных расходов от виртуализации у контейнеров нет, у них производительность нативного приложения со всеми плюсами "всё своё ношу с собой", когда нет разницы чем и какими версиями наполнена выполняющая контейнер система.
uhf
30.04.2024 10:38+3Просто вы не любите абстракции ради абстракций, без обоснования их необходимости. У меня такое есть. Возможно, особенность мышления.
С ООП тоже знакомо - после Си поначалу буквально не лезло в мозг, поскольку не понимал, зачем оно. Но приходилось через нехочу. И в какой-то момент понял, что дальше жить без него не смогу.
Сейчас, когда я в коде создаю очередную абстракцию, я точно знаю, зачем она, и когда может мне понадобиться. При этом все так же считаю, что в чужом коде абстракциями часто злоупотребляют.
Си хороший язык, но с очень узкой сферой применения, в нынешних реалиях. И у него низкая производительность разработчика.Caefah Автор
30.04.2024 10:38Соглашусь буквально со всем. Помню мнение одного Erlang разработчика. Он сказал: "Я лет пять писал в функциональной парадигме, и только потом начал понимать её изящность". Наверно да, особенность моего личного мышления, потому что близки принципы Оккама и KISS. Упрощать где это можно и не плодить сущностей где без этого можно обойтись. И с другой стороны — отвергать всё, что противоречит концепции.
uhf
30.04.2024 10:38+2Я полностью разделяю эти принципы, и могу написать подобную статью, почему не нужно становиться Software developer ) В основном, потому что это далеко не всегда созидательный труд, а гораздо чаще, изматывающее ковыряние в legacy, чужом непонятном коде. И тебе редко когда позволят это исправить, потому что нужно выкатывать новые фичи, а за рефакторинг бизнес не хочет платить.
Говнокод побеждает, потому что он выгоднее в ближней перспективе, а в дальней никто не считает. Я одно время интересовался DevOps. Вот, Докер - вау, все просто. Вот Кубернетис - чего-то уже наворотили, но вроде понятно. Настроил CI/CD в гитлабе - красота! Но это все на личном проектике, где ты сам себе хозяин. А когда увидел портянку helm от реального enterprise проекта, успевшего за десяток лет обрасти костылями - желание продолжать как-то пропало =)
AlexXYZ
30.04.2024 10:38+1И что же оказалось в этой пресловутой парадигме не так? А то, что она просто НЕ НУЖНА!!! И это открытие меня поразило до глубины души.
Тоже считаю «почти также». Но только не эта парадигма не нужна, а она нужна, но в другом виде. Лично мне претит ООП с одним уровнем вложенности членов класса. Хочешь два/три уровня как в JSON - добавляй структуру или класс. Вот зачем? Неужели одного класса мало? Не, пусть будет возможность разложения разных уровней абстракции на классы, но пусть бы была возможность многоуровневой абстракции тоже.
kmeaw
30.04.2024 10:38+1Но ведь почти везде есть вложенные анонимные структуры/классы, разве нет?
AlexXYZ
30.04.2024 10:38+1Честно говоря просто для внутренней структуризации данных городить такой огород из всяких анонимных конструкторов и структур очень напрягает. Сравните, когда этого делать не хочется, то скрепя внутренней гордостью очередной раз чертыхаешься про себя и вводишь какой-то суффикс или префикс. И то и то выглядит криво. Вот пусть бы компилятор сам делал эти «анонимные» классы и структуры. Это ему надо, не мне. (Простите, это вопрос скорее риторический, я не в упрёк вам это говорю)
kmeaw
30.04.2024 10:38Может быть я не понимаю проблему, поэтому уточню. Что не так с этим кодом на Go? На C и C++ можно очень похожие вещи делать.
type Game struct { Video struct { framedata []byte colormap []byte canvas *window.Window } Random struct { prndindex byte rndindex byte } StatusBar struct { InventoryActive bool ArtifactFlash byte } } func (g *Game) Reset() error { g.Random.rndindex = 0 g.Random.prndindex = 0 g.Video.canvas.Reset() }
Tony-Sol
30.04.2024 10:38ООП с одним уровнем вложенности членов класса
Или я не понял, что Вы имеете ввиду или предлагаете "нафиг этот ваш закон Деметры"?
Batalmv
30.04.2024 10:38+4Правду я осознал значительно позже, но сначала не мог понять, почему ООП вызывает такое внутренне отторжение. Ведь и глубокое понимание, и использование ООП в коде требовалось буквально от каждого работодателя!
Просто задачи изменелись. В мире двух-уровневых архитектур это смотрелось избыточно, так как логику можно было сделать хранимками в базе, а морду наклепать - да неважно на чем. Либо "консольное" приложение - тоже ничего такого. Вход/выход == stdin/stdout/stderr, логику пишешь как есть. Хотя лично я начал писать еще на третьем курсе на С++, так как было прикольно. Хотя по работе писал на чистом С и было норм. Но да, наверное для моих задач (а писали в основном под *nix можно было и просто на С.
Но это было давно, а сейчас такие задачи довольно таки нишевые. Но я допускаю, что тогда это было важно в тех местах, куда вы совались
Первая причина — усложнения. Усложнения всего того, что могло бы быть простым. Усложнения усложнений! Надо больше абстракций! Просто так надо! Просто это модно! Просто так делают все! Потому что вот так! Потому что Кубернетис…
Ну, такое. Я в до контейнерную (для меня) эпоху я вот отлично помню опыт автодеплоя на IBM WebSphere. Фееричное упражение. Не, гибкая архитектура, масштабируемая. Скрипті пишутся на чем-то жутко пропиетарном. Одна отрада. Слеав что-то в консоли, можно посмотреть, а чего ж там произошло и скопировав команду можно попробовать засунуть приложение в кластер и сделать этот скрипт частью CD. Но простой там и не палхо. А уж пререносимостью
Хотите просто. Та не вопрос. Есть чудесная утилита make. Пишите Makefile и все будет по старому, как вы любите. Давно писали файл на большой проект с кучей либ и прочего? Так чтобы сам файлик на несколько сот строк и еще с кучей дочерних
Как все это ставить на реальную среду - bash в помощь. Я кстати отлично и сейчас его знаю, может на прям супер-супер, но ... решите современную задачу на связке bash + make, а я посмотрю. Или вспомните как это делали Х лет назад.
И эти чудные IF... THEN ... ELSE где только можно, чтобы обеспечить кросс-платформенность. Кстати, вот где отлично залетал С-ный препроцессор :) Прям аж ностальгия пробила.
Вторая причина. Нужно понимать 300500 технологий, иметь в них опыт и всё равно при смене работодателя на техническом собеседовании осознать, что из всего опросного листа можешь уверенно ответить только на половину
Ну это смотря что спрашивают. Как по мне, смысла спрашивать "а как там выглядит третья слева галочка в пятом ряду" не очень имеет смысл. Человек должна знать базовые сервисы и базу для них. Остальное можно быстро прочитать и осознать за полчаса. Тут скорее вирус "индуса" прилетел и заразил всех в конкретного работодателя
Третья причина. Перспективы углубления знаний в том самом пресловутом количестве технологий. В жизни DevOps инженера мало знать 300 технологий. Через год такой инженер должен будет знать ещё 300, потому что за год выйдет именно столько изменений и старые технологии уйдут на второй план.
Как архитектор могу сказать еще более ужасную вещь. Надо еще изучать концепции, новинки. Также въезжать в бизнес домен, так чтобы через три месяца уверенно обсуждать с заказчиком нюансы его процессов. Как иногда хочется быть простым DevOps и просто стучать по клаве, когда тебя никто не трогает
--------------
Про С ... не знаю. В мире корпоративных решений ему нет места, как по мне. Ни на веб-морде, ни на беке по хорошему. А значит большая часть заказчиков машет ручкой и никогда к вам не придет. Но если вы счастливы там где вы есть - рад за вас.
Возможно ближе к пенсии я тоже захочу все послать подальше и спокойно кодить на чем-то просто и понятном
Geckelberryfinn
30.04.2024 10:38Пока читал, тоже вспоминал Вебсферу, опередили. Тот ещё монстр был. Как вспомню, аж мурашки
Cheater
30.04.2024 10:38+5Даже самый топорный современный компилятор сразу предупредит о проблеме в строке if (variable = NULL)
Эх, хорошо жить в детерминированном мире, наверное.
Вот вам русская рулетка в виде абсолютно безопасного (с точки зрения как минимум PVS-Studio) кода:
#include <stdio.h> #include <stdlib.h> #include <time.h> int *generate() { static int generate1 = 42; static int generate2 = 43; srand(time(NULL)); // Simulate a typo: "&generate" instead of &generate1. return (rand() % 6 == 1) ? &generate : &generate2; } int main () { int *pi = generate(); (*pi)++; return(0); }Нет и не может быть безопасности в языке с сырыми указателями и никакие санитайзеры тут не помогут.
JustMarfix
30.04.2024 10:38+1За полвека для Си разработаны тысячи удобных инструментов, от IDE, до отладчиков, статических анализаторов и компиляторов на любой вкус и аппаратную платформу. Ориентируясь в Си даже на начальном уровне освоения уже невозможно просто так взять и выстрелить себе в ногу. Даже самый топорный современный компилятор сразу предупредит о проблеме в строке if (variable = NULL), а такие инструменты как sanitize или valgrind подскажут где проблема с контролем памяти, если это случайно упустит программист. Си универсален. Си 100% переносим и платформо-независим на уровне исходного кода. Он уже просуществовал полвека и будет существовать в своём мало-трансформирующемся виде ещё очень, очень долго!
Кто-то слишком много слушал Торвальдса :)
Caefah Автор
30.04.2024 10:38Не угадали. Все эти айтишники — жуткие зазнайки, хорошо разбирающиеся только в одном. Им как синоптикам — верить нельзя ни одному, Торвальдсу тем более. Надо делать свои ошибки и на них учиться. Потом делать самостоятельные выводы и описывать эти выводы в статьях, чтобы в результате тебе никто не верил — ведь ты же айтишник :-)
dvglab
30.04.2024 10:38+2Слили карму, не могу голосовать, во многом соглашусь, из сисадминов ушел в девопс и голова разрывается от количества технологий и количества абстракций. И вроде как понимаешь что каждая отдельная технология решает отдельную проблему, и каждая отдельная абстракция тоже нужна и вроде на своем месте, но вместе с тем держать в голове всё многообразие технологий так или иначе имеющих отношение к девопсу и все нюансы довольно тяжело мягко говоря и чуть не каждый месяц появляется новый продукт который вроде как решает какую-то проблему и всё это нужно изучать чтрбы не слишком сильно отставать в девопс технологиях. Бежим чтобы стоять на месте (с)..
ky0
30.04.2024 10:38+2Можно быть хорошим админом без какого-либо девопса, можно остаться фиговым админом в компании, где сплошной девопс. Можно прирасти корнями к определённым технологиям и не желать слышать ни о чём новом. Что не осилил автор статьи, понятно - надеюсь лет через десять не обнаружить себя на его месте.
dvglab
30.04.2024 10:38+1Здесь наверно даже вопрос не в неосилении отдельных технологий. Один пример, вы привыкли использовать ansible, а приходите в компанию где все на puppet и хочешь не хочешь, придется себя ломать и писать на puppet. И так во многом. Переходя на новое место работы ты обязательно сталкиваешься с тем что какой-то инструмент ты не знаешь или не достаточно хорошо знаешь в девопс стеке технологий. А Си он и в Африке Си.. в этом проще с одной стороны. Ну или любой другой язык программирования в целом.
ky0
30.04.2024 10:38+1Если знание определённой технологии критично - обычно вы просто технические собеседования не пройдёте без неё. Если же технология - не громадный пласт (а в эксплуатации в основном такие), обычно влиться реально за вменяемые сроки (если ещё не наступили возрастные когнитивные изменения, хе-хе).
З.Ы. конкретно относительно Паппета - я бы на вашем месте не стал "себя ломать" и трижды подумал, надо ли оно мне, когда есть масса мест, где используют прекрасный Ансибл :)
TldrWiki
30.04.2024 10:38+1А вы точно не используете в Си инкапсуляцию (сокрытие) и наследование (переиспользование)?
vaniacer
30.04.2024 10:38Тоже думал про C недавно, совпадение?) Советы для начинающих? Что почитать? Куда посмотреть? Что использовать? И вот это вот все.
TommyG
30.04.2024 10:38+3Сегодня это очень нишевый язык с тенденцией к уменьшению доли. Надо реально понимать зачем это тебе надо или беззаветно его любить. Для кругозора можно потыкать палочкой, но перспективы сильно так себе.
Согласен с автором про девопс и администрирование в целом. Надо иметь особый склад ума и психику, чтобы эти авгиевы конюшни разгребать. Но в С с мотивацией что ООП не осилил, это тоже "феномен".
outlingo
30.04.2024 10:38+3Насчет линуксового ядра, которое "написано в императивной парадигме" вы очень сильно ошибаетесь.
Возьмите например struct file и struct file_operations. Это как раз классический пример ООП, когда собственно struct file это объект, file.file_operations - VMT (virtual methods table), а file->file_operations->write(file, ... ) это по сути развернутый вариант file->write( ... )
Поэтому, ядро линукса это как раз хороший пример ООП, без излишних абстракций.
Caefah Автор
30.04.2024 10:38Использование структур для определения классов и их атрибутов достаточно распространённый приём в Сишке. И я согласен что очень удобный. Кроме ядра Linux такое используются в том числе для построения GUI (где-то было упоминание тут в комментариях).
Разница в уровне сложности между нативным OOP в том же C++ и трюками в Сишке. Чтобы не многословить просто укажу ссылку на одну из статей: "Десять вещей, которые я терпеть не могу в ООП" И одной такой заметкой список не ограничивается. Есть много хейта вокруг конкретно C++ и Java именно в ключе их усложнённости ради усложнения, когда программисты с 20 летним опытом просто не могут понять чужой код.
HellKaim
30.04.2024 10:38+1Ах дач про С, про С я забыл.
С сегодня действительно, очень... ОЧЕНЬ нишевый. И он не чистый там.
Так как вокруг С существует дивный мир, ищут не просто С, а С+х, и засада в этом самом Х.
Он может быть всяким, внезапным и вообще ни разу не широко доступным. И да, придется менять локацию, так как позиций прям скажем, мизер.
Что действительно раздражает в этом всем новомодном, это обилие слабо совместимых, подчас фигово документированных yaml-xml соплей.
Основная проблема не в "технологии", а в реализации. Есть огромный пласт софта, который внезапно ломает совместимость или просто документирован по принципу "мы следуем тут RFC1234". Ты не читал - лох!
Вот это да, это поджигает почище много чего.
Но, индустрия ест, за это платят деньги - значит это нужно. Если бы это было так ужасно, что было бы что-то дешевле (читай быстрее, меньше цена специалистов, меньше требования к оборудованию, среде) - индустрия бы пошла туда. Я же и писал это выше - ушли мы от спарков не потому, что x86 был хорош, а потому, что на цену 1 спарка можно было купить 20-50 x86. И внезапно, горизонтально масштабировать стало выгоднее... Докер, да
Caefah Автор
30.04.2024 10:38придется менять локацию
Вынужден согласиться. Не раз пытался в прошлых локациях перейти в разработку, но повезло только сейчас и только тут. Раньше просто не мог найти работодателей, даже в удалёнке. Сейчас удалось зайти в интересный High Load проект. В нём такие ресурсы задействованы, что ничего кроме ассемблера и сишки не справится. Так же есть спрос на разработчиков модулей ядра операционок типа AIX, Linux, FreeBSD, разработчиков в сфере безопасности SELINUX/BPF, и, конечно, Embedded — это вообще большинство вакансий.
индустрия ест, за это платят деньги - значит это нужно
К сожалению у индустрии всегда есть своё мнение, и оно часто бывает деструктивным по отношению к людям ею нанятым. То швеи спиваются, то девопсы выгорают...
nugut
30.04.2024 10:38+5Я пришёл в DevOps после многих лет работы разработчиком и сисадмином. И лично для меня постоянная изменяемость и новизна технологий - это плюс, потому что не надоедает. Работать разработчиком мне надоедает, админом - тоже. А DevOps - нет. Здесь и админство (инфраструктура в железе и облаках), и есть место автоматизации (пайплайны, всякие инфраструктурные скрипты), и даже суппорт в виде живого общения с людьми, т.к. нужно организовывать конвеер.
Платят тоже, кстати, неплохо.
KuramoriReika
30.04.2024 10:38+2Я ещё несколько лет назад понял, насколько профессия DevOps способствует выгоранию. Поэтому никогда даже не думал становится им.
Плюс у меня был опыт поднятия и надстройки всех этих серверов и выбора технологий, когда приходиться читать тонны документации, чтобы просто начать писать код. Так как тот, кто этим должен был заниматься, игнорировал свою работу.
Так же сам оказывался в ситуации, когда начальник отдела внезапно ушёл, не оставив ни паролей, ни доступов, ни даже списка проектов и клиентов, которыми он занимался. Несколько месяцев убил, чтобы просто собрать информацию чем он занимался, получить доступы и разгрести проблемы с клиентами.
Поэтому когда уже я в середине апреля подал заявление на увольнение, я решил все задачи по проектам, прочитал лекцию тому, кто остаётся после меня, подготовил пачку документации и напихал комменты в код. А так же составил список из 25 проектов, которыми в последнее время занимался, сбросив все доступы и оставив описание проблемных мест и о чём вообще эти проекты.
Ну и напоследок раздал сетевые ресурсы, которые принадлежали компании вроде ботов, чатов, каналов, контактов и всё такое главам различных отделов.
Пару дней назад ушёл, зная, что выполнил свой долг как разработчика.
Zeqular
30.04.2024 10:38+4Привет от человека, который ушел из программирования "потому что скучно" в девопс. Прошло 5 лет, до сих пор тащусь от того, чем занимаюсь
Caefah Автор
30.04.2024 10:38Не забудьте, пожалуйста, ещё через пять лет поделиться впечатлениями. А я со своей стороны обещаю поделиться впечатлениями о 5 годах в разработке :-)
ALexhha
30.04.2024 10:38+3Мало развернуть приложение на EC2-инстансе и обновлять его по ssh. НЕТ
еще скажи делать git pull на сервере )))
Как насчёт старых добрых опенсорсных HAproxy плюс BGP на Quagga? Нет, не слышали! Да и зачем такое знать клиентам, если на on premise нельзя их поиметь на деньги?!
так настраивай что хочешь, тебя заставляют использовать elb ? Аргументируй клиенту что haproxy/bgp будет дешевле/надежнее/эффективнее. Не можешь ? Так зачем разводить полемику
Как оно в жизни: приходишь в компанию в помощь крутому 20 летнему девопсу, который там уже лет 100 работает и всё-всё знает. В результате оказывается, что от того девопса давно хотели избавиться и он через неделю уходит в закат на вторую работу о которой никто не подозревал, не оставив после себя ни паролей, ни ключей доступа к облаку.
и при чем тут devops ?
Опус больше похож на кризис среднего возраста у ТС )))
Caefah Автор
30.04.2024 10:38и при чем тут devops?
Суть цитируемого раздела заключается в том, чтобы передать мысль: DevOps — это одноразовый инструмент. Им пользуются и выбрасывают сразу же, как только запахло жареным. DevOps — это недешёвый ресурс, и от таких специалистов избавляются в первую очередь, особенно когда инфраструктура уже налажена, проект достиг пиковой стадии и дальнейшего развития не предвидится. Проект функционирует самостоятельно, принося прибыль, и для его поддержки требуется минимум усилий. Или, наоборот, если владелец бизнеса не увидел ожидаемой отдачи от своих инвестиций и начинает сокращать штат, то DevOps-инженеры улетают одними из первых, сразу после дизайнеров. Если в вашей компании начали сокращать дизайнеров — это уже первый звоночек, и пора обновить резюме. :-D Текст написан с долей юмора, но, как известно, в каждой шутке…
nugut
30.04.2024 10:38Никакой проблемы для DevOps'а в этом нет, т.к. как правило из-за специфики работы DevOps'ы вполне восприимчивы к перемене организаций, технологий и редко сидят на одном месте больше нескольких лет. Думаете всё настроили и девопс не нужен? Ок, найду другую работу а вашу организацию буду поддерживать в качестве подработки (или не буду). Поддержка неразвивающейся инфраструктуры - это уже не совсем DevOps, поэтому скорее всего он сам уйдёт раньше чем его попросят.
ALexhha
30.04.2024 10:38DevOps — это одноразовый инструмент. Им пользуются и выбрасывают сразу
же, как только запахло жареным. DevOps — это недешёвый ресурс, и от
таких специалистов избавляются в первую очередьа причем тут описанный организационный бардак, когда ни паролей ничего нет, к теме devops ? У программистов такого не бывает априори и такие случае специфичны только для devops ?
особенно когда инфраструктура уже налажена, проект достиг пиковой стадии и дальнейшего развития не предвидится
слабо себе такое представляю, разве что какие то рога и копыта
а больше похоже на классику
kirillbelash93
30.04.2024 10:38Вот кстати автор прав, ТОЛЬКО В ИТ технология которая еще актуальна сегодня может быть уже заброшена завтра, потому что вышла очередная модная параша, которую сразу лепят в вакансии и опыт с ней от 5 лет нужно. Ненавижу бл*№ь за это ИТ люто, но ничего не поделаешь.
Caefah Автор
30.04.2024 10:38Вот и я к пришёл к тому же через такие же негативные эмоции и выгорание. Но при этом мне нравится сфера IT и поэтому хочу в ней оставаться дальше. Тем более платят ощутимо лучше, чем за всё остальное! ;-) Долго думал чем бы заниматься таким, что уже завтра не уйдёт в забвение и в результате нашёл для себя выход в Си.
brownbrown
30.04.2024 10:38Сегодня нужен только EKS! Он глючный и плохо интегрирован в остальной зоопарк AWS? Ну и что!?
Хотелось бы увидеть примеры/пруфы/первоисточники...
Caefah Автор
30.04.2024 10:38Пруфы того, что всем нужен EKS? Легко:
https://www.linkedin.com/jobs/search/?keywords=devops eks&origin=JOBS_HOME_SEARCH_BUTTON&refresh=true
Или пруфы что он плохо интегрирован с остальными элементами AWS по сравнению с ECS и гораздо более глючный? Проще простого:
https://stackoverflow.com/questions/tagged/amazon-eks?tab=UnansweredALexhha
30.04.2024 10:38Или пруфы что он плохо интегрирован с остальными элементами AWS по сравнению с ECS и гораздо более глючный? Проще простого:
https://stackoverflow.com/questions/tagged/amazon-eks?tab=Unansweredи это доказательство ? показать сколько вопросов по с/с++/python ?
Ssandarss
30.04.2024 10:38можно совет тогда с высоты вашего опыта. Вот я админ 5 лет с саппорта в тех поде провайдера, до админства офиса в 600 человек в одного, сеть-серваки-виртуализация-секурити немного. думаю в девопс перейти, бо зп выше при тех же объемах работы (ну я так думаю) но вот чего дальше делать непонятно, в девопс хочу, но сейчас всем надо опыт работы в этой сфере, а опыта то нет. да я могу дженкинс поднять и с интегрировать, в ансибле плейбуки написать, но всем надо фиг пойми чего. кодить? но кодить мне не очень нравится, да и не занимался этим никогда. и в итоге непонятно чего дальше делать
Caefah Автор
30.04.2024 10:38Как вариант попробуйте найти такого нового работодателя, у которого есть две инфраструктуры: on-premise и в облаке. Или у него есть планы построить Disaster Recovery в облаке, продублировав инфраструктуру или её основные элементы. Там точно будет много практики и нового опыта с облаками. А чтобы расширить выбор работодателей улучшайте английский хотя бы до уровня Upper Intermediate. С таким английским вариантов выбора работодателей для работы в удалённом режиме возрастает на два порядка. В любом случае откажитесь от обслуживания конечных пользователей. Они сжирают всё время и не дают расти. Попросите у руководства для обслуживания пользователей отдельного эникейщика, который будет им помогать, чтобы Вы могли сосредоточиться на саморазвитии и поддержке серверных решений. В конце-концов предложите развернуть Disaster Recovery текущему работодателю. Хотя бы бэкапы хранить в облаке.
Ssandarss
30.04.2024 10:38ну вот ищу уже пару месяцев и нифига, на линкидине голяк: на удаленку сбегается толпа чуваков и всегда находится другой что милее работодателю. А англ b2 с залетом в с1 ток немного практики
Caefah Автор
30.04.2024 10:38Если Вы ищете удалённую работу в Google из Тагила, то по очевидным причинам Ваше оформленное не по стандартам принимающей стороны резюме даже не будет рассмотрено. Тогда остаётся вариант предложить изменить локацию. Там автоматически изменится уровень доверия, схемы налогообложения и прочие мелочи жизни, которые работодателю могут быть принципиально важны. А так же откроется возможность рассмотреть варианты hybrid и on-site.
С Вашим английским можно претендовать на очень крутые компании в случае переезда в зону их интересов. А ещё есть масса нюансов типа ATS и правил оформления резюме под конкретного работодателя или правил, относящихся к конкретной стране. Они есть и иногда очень жёсткие, и даже регулируются законом. Поищите комьюнити в социалках, задавайте вопросы именно по той локации, на которую рассчитываете и Вам подскажут как избежать ошибок при подаче резюме и прохождении интервью.
В моей локации у компаний богатый выбор аутсорсеров, но они предпочитают местных только потому, что их можно будет взять за жабры и трепать до конца жизни как того Буратину, в случае если сотрудник превращается в источник проблем.
Ещё вариант присоединиться к международным галерам, специализирующимся на аутсорсе. Но там, как правило, маленькие проекты с коротким сроком жизни... ну хоть руку набить и строчку в резюме добавить и то уже неплохо! Однако... как повезёт... У меня есть друг, который в галерах не первый год и на одном и том же проекте. При этом галеры помогли ему вместе с семьёй и тремя детьми релоцироваться в страну его мечты и он работает по 4 часа в день. При этом все довольны.
RedFirefly
30.04.2024 10:38На 600 человек надо 6 человек минимум. Как ты это вывозишь один непонятно. Может быть, конечно, ты не саппортишь самих юзеров.
budnikovsergey
30.04.2024 10:38+1Всем надо автоматизировать инфраструктуру. Автоматически создать виртуалку терраформом, настроить её ansible и подключить в инфраструктуру с автодобавлением в мониторинг. В инфраструктуре нужен оркестратор kubernetes, чтобы сервисам абстрагироваться от железа, операционных систем и понимания в онпреме оно или в облаке у провайдера. В кубер всё нужно деплоить автоматически: инфраструктурное через GitOps-подход Application-of-Applications от ArgoCD, и прикладное через CI/CD на Gitlab. Всё в кубере надо уметь сделать прозрачным: поднять мониторинг на Promeheus и сбор логов на Loki + promtail. Этой базы достаточно для замены любой перечисленной составляющей на кучу аналогичных: принципы одни и те же, однако сразу надо учиться на хорошем.
Самому надо освоить кубер (для экономии времени и денег лучше по этому курсу за 10$ https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/ с выполнением всех лаб), helm, CI/CD на базе Gitlab и основы мониторинга на связке Grafana+Prometheus. Этого достаточно для уверенной работы джуном в компании из нескольких девопсов, от которых уже нахватаешься более широкого спектра систем.
Крайне рекомендую использовать канал Артура Крюкова https://www.youtube.com/channel/UCU55LZT7oRxhX4GTvb5H4HA на котором он честно делится всеми основами и всем кодом.
aikss
30.04.2024 10:38Статья прекрасна, как минимум, как альтернатива. Надоело читать сопли по то, как все прекрасно в девопс. Хотя, как мне кажется, автор не остановится на С, и через N лет будет заниматься чем-то другим =)
Caefah Автор
30.04.2024 10:38Абсолютно верное предположение! ;)
Конечно есть идеи что делать дальше и очень скоро я их озвучу, потому что они могут быть интересны не только мне, но и другим программистам.
NelEvg
30.04.2024 10:38+2Я бы отделил мух от котлет. ООП и контейнеризация (как пример) реально "помогают", они частично автоматизируют процессы. Это котлеты. А мухи в том, что не всегда это реально оправдано для внедрения)
astafevataisiya
30.04.2024 10:38Полностью согласна. Иногда кажется, что компании тратят слишком много времени и ресурсов на мелкие изменения, вместо того чтобы фокусироваться на разработке новых идей и технологий. Вместо перестановки иконок и изменения интерфейсов, лучше бы вложить усилия в развитие новых продуктов или улучшение существующих.
feelamee
30.04.2024 10:38+1Плюсую за хороший выбор. Си дает очень хорошую и стабильную основу.
Но я бы выбрал немного иной путь - изучить computer science. И уже как необходимость для практики - изучения языка. Не суть важно какого, но си вполне достойный вариант.
Caefah Автор
30.04.2024 10:38На самом деле изучение computer science подозревается по-умолчанию. Если ставится цель профессионально работать программистом, то без знания алгоритмов, работы памяти, параллелизма и других аспектов делать нечего не только в Сишке, но и в любом другом языке программирования. Однако computer science это такой пласт знаний, в который можно углубляться бесконечно не для практических задач, но ради академических знаний.
budnikovsergey
30.04.2024 10:38+1Я с точно таким же бэкграундом: возраст, жизнь в ИТ, широкий набор навыков, сейчас зарабатываю как DevOps-инженер. Я тоже из поколения, чей карьерный путь начался в буме внедрения массового ИТ в России и с которым по мере взросления в обществе сдвигается приемлемый возраст для ИТ-инженера. Более того: я отлично вижу фундаментальные вещи, на основе которых строятся каркасы современных инфраструктур и могу переточить решения своими навыками между онпремом, Yandex Cloud, AWS и GCP. Мне без разницы на чём строить CI/CD: Gitlab, Jenkins, Bamboo: я смогу сделать CI/CD даже на shell :) Я регулярно хихикаю, когда вижу как очередной стек инфра-технологий замечательно автоматизируется через старый добрый shell scripting несмотря на все верхнеуровневые кнопки "сделать всё зашибись". Я умею в python/golang/c/cpp, но как инфраструктурщику мне обычно хватает unix way с его гениальным shell scripting, отточенным нуждой в переносимости и требованиями приемлемой производителности, когда окружение даёт кучу специализированных инструментов, которые ты как кубики Лего склеиваешь между собой. Опыт позволяет мне успешно строить прозрачность и наблюдаемость решений. Опыт позволяет мне успешно заниматься выявлением и устранением узких мест в производительности инфраструктуры и я успешно помогая командам притащить эти инструменты в продукты и облегчить им процесс поддержки стабильности в продуктиве. Более того, накопленный опыт позволяет мне строить процессы и я знаю как построить команду и процессы в ней, чтобы бизнес имел на руках максимально адекватный импульс от инфраструктуры для его продуктов, работающих и развивающихся в режиме 24/7. Опять же, доступен левелап: процессами и уровнем обслуживания можно успешно заниматься сколько угодно времени, платя за это существенной частью жизни на совещаниях.
И я не жалею о выборе карьерного пути.
Мне не очень понятен выбор C вместо Golang: гошечка даёт продуктовые вакансии, где инженеры это часть контура зарабатывания денег и поэтому обласканы множеством компаний. И у go есть всё, чтобы массово и успешно писать востребованный быстрые высоконагруженные сервисы: её делали те самые дядьки, которые делали C и они применили весь свой опыт, отточенный многими десятилетиями mainstream IT: gperf, прозрачность, каналы, мощная простота и нативная жизнь в сети. Тогда как по ощущению C это практически только железо или древнючее легаси, что в российских условиях жизни электроники только в Китае смутно ощущается как тотальное кроилово на людях внутри чего-то, похожего на советские НИИ с их специфичной атмосферой.
Caefah Автор
30.04.2024 10:38не очень понятен выбор C вместо Golang
Хотелось бы обосновать свой выбор. Он исключительно субъективный, но у меня есть причины.
Зачем мне Golang если я знаю Си на котором могу написать буквально всё. Те же самые "буквально всё" на Golang, к сожалению, не напишешь. Люблю свободу без ограничений.
Если смотреть с точки зрения асимптотической сложности накладных расходов в больших проектах, то производительность программ на Си почти равна возможностям железа и, например, каждое новое клиентское подключение будет потреблять линейное количество ресурсов O(n) или близкое к тому. Накладные расходы любого другого языка программирования с теми же принципами, которые заложены в Golang (например гарбидж-коллектор) никогда не будет линейной, а с значительным коэффициентом.
Упрощу объяснение на выдуманном примере:
а) Программа на Си для одного клиентского подключения потребляет 1Mb и 1/1024 CPU. Для 1024 клиентов она потребит 1Gb и 1CPU. Это, конечно, очень грубое представление — в реальной жизни может быть как меньше ресурсов, так и больше — тут целое поле для оптимизаций.
b) Программа на Golang для одного клиентского подключения потребит 1Mb и 1/1024 CPU, но для 1024 клиентов она потребит 100Gb и 10CPU. Цифры взяты от потолка, прошу не придираться, цель их присутствия только для того, чтобы передать идею накладных расходов, а не принизить достоинства ЯП.
Kingas
30.04.2024 10:38+2Все эти абстракции это попытка людей нащупать такие, чтобы было проще решать различные проблемы, от понимания чужого кода, до проблем с распределёнными транзакциями. Это долгий путь, он спиральный, и это ещё надолго =)
У Си есть огромное преимущество - его легко встраивать в других языки. А языков наплодили много. С C++, вирт методами и его исключениями возникают сложности.
Если говорить про простоту кросс-платформенности - то это не Си. Начиная от различных выравниваний, разных размеров типов, posix функций которых нет например в win и нужны эти чертовые порты, заканчивая тем что поток не всегда легко выбить из блокирующих функций (а в системах очень много латентных IO операций, туда же относится файловая даже не супер быстром SSD).
Учитывая эффективность самого языка (не библиотек), многопоточности, простоты асинхронности, простоты кросс-платформенной компиляции - я лично за C#. У него как и у каждого языка свои плюсы и минусы. С чистым native бывает не просто с ним. Не надо там на Hello world 10 ГБ оперативы, сейчас конечно сборка уже по-проектная, а в классике было чисто scs, и он умел намного больше, чем обычно использовали через IDE. А вот все IDE жрут много.
Я вот в последнем проекте собираю C++, он во время сборки 10 ГБ за секунды сжирает.
Но это всё это только инструменты. А есть то, зачем этот инструмент, сама задача которую надо решить.
Protosuv
30.04.2024 10:38+2По возрасту почти как автор (скоро 45 лет). Карьерный путь был тернистым и иногда напоминал метания и ощущения что нахожусь не на своём месте. И весьма забавно, что именно сегодня, когда я вечером размышлял о своих 22+ годах карьеры, мне попалась эта статья. Волею судеб все мои попытки уйти в разработку давали мне понимание, что не совсем это моё. Да близкое и интересное, но не моё. Пока что в роли Devops я ощущаю себя на своём месте, но как знать, что я буду говорить в 47)) Я вот даже не знаю, динозавр я уже или ещё нет. Стремительно пробежали последние лет 15. А всё почему, а потому как когда появляются дети, время летит быстрее. Технологии летят также стремительно, но с возрастом приходит какое-то спокойствие в оценках нового и попытки обосновать технологию для самого себя приводят в целом к верным выводам. Так в спокойном темпе, подключая старые знания, изучаю что-то новое.
zencd
30.04.2024 10:38Восхвалять именно Си сейчас - это смешно. В первую очередь это язык ответственный за большую часть уязвимостей. Во вторую, там нет даже автоматической очистки только что выделенной руками памяти. Нечего там защищать: господь, жги... А мысль первой половины текста, про превращение мира девопса в мир джава скрипта по части гонки технологий - она понятна; я не девопс, но наблюдал немного со стороны что-то похожее, и вероятно автор тут прав.
Caefah Автор
30.04.2024 10:38автоматической очистки только что выделенной руками памяти
Вот даже страшно было это читать, куда уж себе такое представить...
Ладно, добавлю смайлик. Дружелюбный. :o)
etaradayko
30.04.2024 10:38+1Я прямо увидел своё отражение. Мой путь в IT был 1 к 1 с твоим особенно в начале и ближе к концу )
И я испытывал похожие сложности с пониманием ООП. Я перечитывал OOP С++ по 10+ раз пока не понимал и двигался дальше. Но не смотря на то, что я разобрался и проникся в итоге красотой ООП я пошел по пути админства и девопства. Сейчас пока наслаждаюсь терраформом с ансибл и иногда пишу питон скрипты с классами для разных нужд )
Иногда скучаю по чистому программированию ... возможно это наш путь вернуться к истокам )
ChePeter
Проблемы не в Devops или ООП, это инструменты всего лишь.
Проблемы в том, что как не умели так и не умеют толково и дельно превращать реальность в байты и обратно.