Вкатится в devops

devops это те кто хотел быть админом но не осилил. А потом они своим неосиляторством стали гордиться.

Вайбкодил

Осуждаю.

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

Осуждаю.

devops это слишком обширное понятие, кто то вкладывает в этом понятие написание плайбуков для ансибеле, кто то жонлигрование контенейрами в кибере, кто то системы непрерывного деплоя, аля Женкинс …

Но в любом случае я никогда не понимал заббикс (я прекрасно знаю это тормозное поделие), почему то его любят вчерашнии пользователи виндовс.

я прекрасно знаю это тормозное поделие

Не, не знаешь. По умолчанию он работает с БД через жопу. Нужно настроить партиционирование, и тормозить не будет

инфобеза(скрины экранов пользователей с передачей на сервак, проверка заблокирован экран или нет, открытое текущее окно и кейлогер и т.п.)

Это называется не инфобез

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

Проблема в том, что джунов - мульёны.

Я, помимо основных задач, участвую в найме для конторы, через меня проходят сотни резюмешек.

Ситуация примерно следующая: на волне бума IT 21-23 годов, в IT за «длинным рублём» ломанулись примерно все. Все эти юристы-экономисты-аграрии и прочие-прочие-прочие. В основном, в тестировщики, но и в сисадмины, и в разрабы, кое-кто и сразу в девопсы. Резюмешки у всех, как под копирку: предыдущий опыт стёрт, ВУЗ закончил когда-то давно, а первое место работы - условный девопс в условном Сбере в середине 22-го.

За пару-тройку лет сей добрый молодец научился разве что нажимать кнопочку «собрать» в дженкинсе. И, вполне справледливо, был пинком под зад выкинут не просто из Сбера, а вообще из всей Сберовской инфраструктуры (там много контор, но никому такое счастье не упёрлось). Читаешь резюме такого героя - диву даёшься! Истинный гений, куда мне до него! Всё знает, всё умеет! Разве что в космос не летал и не схватил ачивку «пилот межконтинентального бомбардировщика».

Зовёшь такого на технический собес - не знает ничего. Вот ащще. На элементарнейшие вопросы ответить не может. Ни по линуксу, ни по докеру, ни по куберу, ни по облакам, да вообще ни о чем. Хотя всё это в ключевых навыках написано! И денег хотят от 300К на руки.

Ну, для примера, на понимание уровня: у человека было написано, что много опыта с AWS. Спрашиваю, чем отличаются инстансы c5, m5, t2/t3. Молчит, как рыба от лёд. Говорю: ну вот же у тебя в резюме написано - AWS, вот ты конторе работал и бородато одминил облако. Как ты виртуалки-то для проектов заказывал, не понимая, чем они друг от друга отличаются?

Но резюмешки у всех - залюбуешься. И эта орава очень хочет кушать. И не только хлеб с водой. Так что пролезут, как тараканы. Стоит ли тебе в этот высококонкурентый рынок нубья влезать - решай сам.

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

Нормальный админ не вайбкодит, а целеноправленно пишет код. Девопсу писать код нужно ещё больше.

То, что ты назвал инфобезом к инфобезу отношения не имеет вообще никакого.

Zabbix'а для мониторинга сейчас недостаточно.

+1 за заббикс.

А вот про написание кода не совсем понятно. Плайбуки, скриптики и к примеру всякие цели в женкинсе я бы не назвал кодом.

Хороший админ/девопс пишет не только плейбуки. Нужно писать утилиты для управления инфрой, экспортеры для того же прометея, плотно взаимодействовать с разработчиками(когда делаешь для них CI/CD; вплоть до ревью кода и внесения правок). Это только вершина айсберга. Работать с кодом нужно очень плотно. Прошли те времена, когда админ сидел и пил кофе, поставив ОС на сервер и забыв об этом.

Экспортеры? Да ладно, мне приходилось писать экспортер на питоне для поднятие собственого экспириенса, а для разрабов а зачем оно для разрабов?

В любой конторе крупнее васянского ИП есть своя специфика работы и необходимость собирать кастомные метрики, т.е. как минимум либо писать скрипты для node_exporter, либо писать кастомные экспортеры. Есть необходимость анализировать логи.

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

Ну понимать код это нормально. В прошлом тысячитилетее даже на ассемблере писал…

А поводу експортера не согласен. Теже логи фигачишь в локи и если нужно то аллерт на разрабов с доступом к той же графане отфилитрованной по их апп пусть сами в логах квыряються.

пусть сами в логах квыряються.

Прошло это счастливое время. Теперь в логах разбираются девопсы и потом приходят к разрабам.

Спрашиваю, чем отличаются инстансы c5, m5, t2/t3.

Правильный ответ: это чистый маркетинг..

Нормальный админ не вайбкодит, а целеноправленно пишет код. Девопсу писать код нужно ещё больше.

На самом деле, не совсем так. Или совсем не так.

Общемировая тенденция: отдавать CI/CD, написание докерфайлов, куберовских ямликов и, отчасти, ансибловых плейбуков - разработчикам. Размах действий девопсов в этом смысле сильно уменьшается: девопсы становятся экспертами и контролерами над всей разработкой, тестированием и инфраструктурой; ну и в какой-то мере архитекторами инфраструктуры. И поэтому их много не надо. Для понимания: вот я работал девопс лидом в иностранной конторе. Нас было 8 человек, включая PMа. А разработчиков/РМов/тестировщиков - больше 300. А инфраструктура - 170 GCP проектов, в каждом один или несколько куберовских кластеров, в каждом кластере 1 или несколько нодепулов, в каждом нодепуле до 32 нод. Ну и, понятное дело, ноды далекооо не слабенькие. Стоимость инфры можешь прикинуть.

В таком распределении задач есть смысл: только сами разработчики хорошо знают, как у них взаимодействуют сервисы, какой софт (библиотеки, фреймворки и т. п.) используется, какие изменения нужно внести в инфраструктуру при очередном релизе и т. д. То есть, IaC они напишут ПРАВИЛЬНЕЕ, чем девопс. Девопс в этом смысле нужен, чтобы исправить косяки; присмотреть за инфобезом; возможно, что-то оптимизировать; уменьшить косты на инфру.

В целом, в зарубежных компаниях такая тенденция началась ещё в 18-м году (а, возможно и раньше), когда в России девопс направление только хоть как-то развиваться начало. Вот в 25-м эта тенденция докатилась и до России. И прежде всего поэтому джунов девопов начали гнать сцаными тряпками из Сбера, ВТБ, Альфы и прочих всяких. Они просто не нужны стали в таких количествах. Разрабы с их задачами справляются лучше, а пятое колесо в телеге только мешает.

В любой сфере такое. Электрик, электронщик даже зная физику тока не означает, что он автоматически знает пожарную сигнализацию, схему гитарного процессора, свойства аппаратов высоковольных линий. Их растить надо. Я понимаю и в нашу область заходят проходимцы. Опять же что можно узнать за 5 минут общения? Я например слишком много думаю из-за чего могу выглядеть тормознутым и таким же проходимцем, ни раз на меня смотрели с высока, типа что это. В то время я понимаю, что могу уделать инженера в своем направлении как тузик грелку. Одновременно случались и противоположные ситуации, когда в момент собеседования и показа оборудования принесли неисправный блок и зауши хватаются что делать, ну вот говорят можешь посмотреть, опять же напрягся, пока они отвлеклись я спокойно осмотрел и увидел обрыв провода, прикрутил временно, они подошли как раз проверяют, работает. Естественно я для них сразу гением стал, замечу на пустом месте.

Тут вопрос не в «проходимцах» даже.

Вопрос в том, что они нужны были во время IT-бума. Их взяли на работы; они несколько лет сидели; чему-то в рамках прямых обязанностей научились (кнопку «собрать» в женкинсе нажимать), но учиться дальше не стали; делали примерно ничего и получали отличные ништячки в виде зарплат и прочих всяких ДМСок.

А вот в 25-м году «мавры сделали своё дело, мавры могут удалиться». Вот только куда удалиться? Назад в деревню в пшеничном поле ковыряться? А ведь на жирных временах и ипотеки уже взяты, и уровень жизни вполне на уровне европейского среднего класса, и прочее в том же духе.

Так что нееет. В планах вернуться в жирные времена. А для этого нужно себя показать прям вот суперменом из суперменов. Вот и пишут в резюмешках небылицы. Один джун недавно в резюме написал, что внедрил в Авито ревью изменений в IaC. Джун пришёл туда в 23-м году. Ну то есть, до 23-го года в Авито никакого ревью кода инфраструктуры не было и каждый бородатый одмин безнаказанно творил всё, что хотел. :) Я прям проржался.

Тут ещё и работодатели (точнее, безмозглые HRюши) виноваты. Во-первых, широким применением фильтров и ИИшечек. Во-вторых, неадекватно завышенными требованиями в вакансиях.

Вот все эти ребятушки и пишут в резюмешках все слова, которые когда-либо слышали. Чтобы обойти фильтры и хоть как-то добиться того, что их резюмешки живые люди прочтут.

Вовсе нет. Это экономика. Оптимизация костов на облако.

C - это compute. Больше процессоров, меньше памяти.

M - это memory. Больше памяти, меньше процессоров.

T - это time. Время. Регулярно выделяется бюджет и, в зависимости от нагрузки, расходуется. В остальном оно как compute инстанс.

В отличие от GCP, в котором конфигурацию инстанса можно подправить, в AWS инстансы имеют фиксированные конфигурации.

Соответственно, вот у тебя требование от разрабов: ХХ гигов оперативки. Ты можешь взять С-инстанс с требуемым (или большим) количеством памяти. Но он будет дорогой, потому что будет и много процессоров, которые будут простаивать. Можешь взять М-инстанс под память, так будет дешевле, но там надо смотреть, хватит ли производительности по процессорам.

Ну а если нагрузка только «пиковая» (скажем, несколько часов в сутки), а остальное время нагрузка нулевая - тогда разумно брать Т-инстанс, он получится сильно дешевле.

Прошло это счастливое время. Теперь в логах разбираются девопсы и потом приходят к разрабам.

посмотрите пожалуйста тему с сообщения и до низу: Не работает RDP подключение к компьютеру на Windows 7 (комментарий).

инфобеза(скрины экранов пользователей с передачей на сервак, проверка заблокирован экран или нет, открытое текущее окно и кейлогер

Предлагаю бежать из такой конторы.

куберовских кластеров

Я стараюсь много читать про новые технологии, к примеру не так давно писал про микроВМ кому то здесь, и вот Винда и теперь уже MacOS пишут что сделали запуск контейнеров у себя …

Ну это нормально.

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

Да, ты прав. Но это как раз не отменяет, а наоборот подтверждает то, что нормальный девопс должен хорошо уметь в код. Ему(мне) нужно плотнее взаимодействовать с разрабами, лучше разбираться в том, что они написали и уметь вносить правки сверх мышкотыкательного интерфейса.

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

я это вот к чему: https://mxlinux.blogspot.com/2026/07/bootc.html

А я откуда знаю? Следующая такая бессмысленная и не привязанная к контексту ссылка будет удалена.

Стоп а теперь обьясните в чем выражаеться не привязка к теме?

Если работал программистом и не вывез, но умеешь писать на шелле, достаточно зазубрить систему управления конфигурацией, контейнеры, мониторинг и ci/cd с хостинг-премудростями, чтобы взяли в девопсы?

Тема про DevOps, ссылка к этому отношения не имеет. Очевидно же.

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

Нет.

Нужно уметь проектировать и управлять системой. Зубрёжка тут не поможет.

Значит как теперь это выглядит.

Сидит программер и пишет свою прогу. Причем тестирует ее через контейнер, ну типа жмет одну кнопку жмет. Хотя я когда писал то контейнер работал рядом и если что я менял в каталоге тут же контейнер подхватал и в браузере сразу видно результат.

Как все ему хватает, делает релиз в гит.

Гит через раннер хавает это собирает контейнер и пушит в регистри.

Приложение крутиться, смотрит в регистр, хоп появился изменение в апп.

Скачивает новый слой и перезапусаает контейнер.

Не запустилось, откатываеется само назад с логами …

Ну так примитивно описал, но зато понятно.

Если умно в инете про это умнее написано.

Что касается блога то просто вспомнил про него и решил там написать. Там предыдущая запись от 2013 года …

А потом от таких девляпсов получаются проблемы. Бэкап верифицировать? Зачем. Понять какие маршруты и куда нужно на уровне сети настроить? Это жу пусть админ делает (а то, что девопс должен админскую часть понимать это мы забываем) Разобраться почему Ingress заголовки режет? Так это ж веб-сервер (опять админ). Разрулить зависимости софта? Админ. Система мониторинга? Да зачем ж она нужна? Application Performance Monitoring прикрутить? Так тут нужно и разрабом и админом быть, а мы ни то ни другое не умеем… Поставить и грамотно настроить слой CI, pre-commit hook для запуска линтеров? Так зачем ж мне это надо, пусть разрабы глазками проверяют. Описать инфраструктуру, подготовить пакет документации? Так я и в инфраструктуре не секу, пусть кто-то ещё занимается. Поставить единое хранилище логов и настроить сборку? Так это ELK/Loki надо курить, ептеть. И так далее и так пошло.

Там тоже, знаете ли, не сахар, а девляпсы на нормальную зарплату нахрен никому не упали.

Сидит программер и пишет свою прогу. Причем тестирует ее через контейнер, ну типа жмет одну кнопку жмет. Хотя я когда писал то контейнер работал рядом и если что я менял в каталоге тут же контейнер подхватал и в браузере сразу видно результат.

Это справедливо для хелловорда. И ломается, когда ты пишешь в команде большой продукт, который в своей работе зависит от кучи другого кода и просто не может работать сам по себе.

Остально читать нет смысла.

Видать не убедил. Я это описывал так как сам это все пробовал.

Как это в больших командах вам лучше почитать в инете, но конечный результат деплой контейнера и его сборка через …

Ну и ладно.

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

Как это в больших командах вам лучше почитать в инете

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

Вот за такое меня б уволили прям вот в ту же минуту. :)

1. Правильно построенный GitOps подразумевает workflow: Задача -> бранч -> Pull Request -> аппрув -> мерж куда-нибудь в тест -> тестирование -> аппрув -> мерж в прод -> выкатка. Возможны варианты, но плюс-минус так.

Начать с того, что кто ж тебе в принципе-то дал права хотя бы смотреть в проект (Jira или чего-нибудь аналогичное) разрабов, создавать там задачи и в их репу чего-нибудь пушить? :) А даже если и запушишь, кто ж даст права на мерж? А если и смержишь, тестирование обойдёшь, сразу в прод? :)

Прости, но выглядит полнейшей бредятиной. Тем более, когда команда работает, а ты в душе не знаешь - что, как и зачем они делают. Даже если предположить, что твой emergency patch эту конкретную багу починит - где уверенность, что оно не сломает ещё что-то где-то из остальных восьми десятков микросервисов?

2. В чужом коде разбираться всегда долго и муторно. И не факт, что успешно. Разработчик, написавший код, разберётся в ошибке на порядок быстрее по времени и учтёт всё то, что ты просто не знаешь (поведение сторонных сервисов, например). Не забывай, что прод у тебя лежит в это время.

3. Тем более, ты не знаешь структуру (например) базы данных, если ошибка связана с некорректным запросом к ней. Ну увидишь ты в коде SELECT труляляля - и что дальше-то? Тебе уйма времени потребуется, чтобы в принципе-то понять, можно ли такой запрос к этой БД делать хотя бы теоретически.

4. Ковыряться в логах в плане кода тебе тоже не нужно. Скорее всего, разработчики сами увидят, чего там валится - всё-равно ведь будут смотреть в грейлог или в ELK/EFK.

5. А вот что тебе действительно надо сделать, так это уведомить ответственных (PM, лид проекта, ответственный разраб и т. д.). И дальше смотреть в логи на предмет каких-нибудь Permission Denied. С вероятностью под 90% ошибка связана именно с недостатком прав (чудес не бывает, на тестовой инфре ведь всё работало!) и с чуть меньшей вероятностью - потеря связи, падение каких-нибудь сервисов (например, по ООМ) или падение чего-нибудь платформенного типа виртуальных машин (впрочем, это на мониторинге сразу будет видно).

Я не смог разобрать этот поток сознания.

Жаль. В общем, всё сводится к тому, что не надо тебе править чужой код. Если не хочешь внезапно ощутить себя безработным.

Мой работодатель и начальство моих коллег думают иначе.

Когда я был за реган, хотя и создавал темы против анонимусов, но на самом деле это не совсем так, у меня была цель навести порядок. И я (насколько) помню ни создал ни одной темы где не было бы участие анонимусов так как большая часть грамотных и правильных ответов было именно от них.

Вот вам 2 старые статейки:

https://developers.redhat.com/articles/2024/11/22/creating-cicd-pipelines-image-mode-rhel#

https://www.saisravancherukuri.com/post/bootable-containers-the-next-leap-in-operating-system-delivery

The Future of OS Delivery

Bootable containers blur the line between OS and application delivery, bringing modern DevOps workflows to the operating system. By leveraging the same tools, pipelines, and processes used for containerized apps, organizations can achieve:

    Faster deployments

    Reduced operational complexity

    Improved security posture

    Consistent environments at scale

In short, bootable containers are not just a new deployment method; they’re a fundamental rethink of how we build, deliver, and maintain operating systems in the cloud-native era.

Статьи старые и это уже давно в ходу …

Тогда я тебе искренне сочувствую. :)

Хотел бы я посмотреть, как это у вас происходит. :)

Вот просыпаешься ты в 3 часа ночи от теребоньканья мобилки. Видишь, что лежит какой-то самописный микросервис. И, с томагавком наперевес, лезешь в код этого сервиса (а если он на GOшечке писан? strace - наше всё?) разбираться, чего там не так?

Ни ответственных поднять, ни руководству сообщить? Прям вот сразу - в бой?

Я не знаю, откуда у тебя такие фантазии. У нас такого нет.

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

Первая статья хорошая. Ко второй есть вопросы. В любом случае, спасибо. Это лучше, чем предыдущие ссылки и советы.

Никогда не поздно.

Мне пару раз звонили с работы для моего же блага. Причём я со смены пришёл и естественно дрых без задних ног. С ходу сориентировался и выдал требуемую инфу. И дальше — спать. :⁠-⁠D

...нормальный девопс должен хорошо уметь в код...

И не только.

Дык топикстартер именно это и планирует.

...нужно себя показать прям вот суперменом из суперменов...

Не везде это работает.

бума IT 21-23 годов

19-23 годов, скорее. Если даже не 17-23.

В 19 и 20 году точно не проблема была найти работу в IT, и уже была куча курсов. В 20 году, мне кажется, начался прям пик, брали любого, кто мог показать, с какой стороны надо подходить к клавиатуре.

А так… Всё так.

Я в последний раз собеседовал в 23 году. Прособеседовал несколько десятков, если не сотен человек, и был в полном ужасе. Люди просто зазубривали ответы на самые популярные вопросы, не понимая сути ответа вообще.

Один раз пришёл мальчик, у которого было немного опыта, но который реально шарил, и если не знал ответ на вопрос, мог сам дорассуждать до правильного ответа. Но он запросил… Пабам… Зарплату более полумиллиона! Конечно, его не взяли, у нас никто, включая тимлидов, столько не получает.

Мой работодатель и начальство моих коллег думают иначе.

Ты может и девопс, только на пол-шишечки. Ты разраб, потому что если девопс лезет в код, написанный разрабом - он вылетает с волчьим билетом сразу нахрен потому, что инициативный идиот.