Не хочу быть DevOps-инженером.
Хочу быть MLOps-инженером.
А.С. Пушкин (из неизданного)
На hh сейчас 200+ вакансий MLOps. Год назад их было от силы 40.
Причина простая: колорит нашего рынка сейчас такой, что всем крупным компаниям сверху поставили КПЭ на внедрение ИИ. Бизнес судорожно накупил дорогих GPU, а как превратить это в работающий сервис почти никто не понимает. Компании ищут тех, кто умеет в инфраструктуру, а не просто "рисует графики в ноутбуках". То есть нас.
Я решил не читать лонгриды, а просто пощупать это руками. Задался целью собрать MLOps-платформу на своей инфре и посмотреть, насколько это вообще "другая планета" для DevOps-инженера.
Первый вывод: 70% базы –внезапно это тот же Kubernetes, CI/CD и Terraform. А вот остальные 30% реально взрывают мозг. Модель может отвечать за 2мс, Prometheus будет гореть зелёным, а бизнес терять деньги, потому что модель несёт чушь просто потому, что данные в мире изменились. Без единого коммита в код.
В следующих 4 постах разложу по фактам: что конкретно поднял, где привычный DevOps спас, а где пришлось учиться заново, чтобы железо не работало вхолостую.
Если уже работаете с ML-инфрой – расскажите в комментариях, что больше всего удивило при переходе. Интересно сверить заметки.
#карьера #devops #mlops
Хочу быть MLOps-инженером.
А.С. Пушкин (из неизданного)
На hh сейчас 200+ вакансий MLOps. Год назад их было от силы 40.
Причина простая: колорит нашего рынка сейчас такой, что всем крупным компаниям сверху поставили КПЭ на внедрение ИИ. Бизнес судорожно накупил дорогих GPU, а как превратить это в работающий сервис почти никто не понимает. Компании ищут тех, кто умеет в инфраструктуру, а не просто "рисует графики в ноутбуках". То есть нас.
Я решил не читать лонгриды, а просто пощупать это руками. Задался целью собрать MLOps-платформу на своей инфре и посмотреть, насколько это вообще "другая планета" для DevOps-инженера.
Первый вывод: 70% базы –
В следующих 4 постах разложу по фактам: что конкретно поднял, где привычный DevOps спас, а где пришлось учиться заново, чтобы железо не работало вхолостую.
Если уже работаете с ML-инфрой – расскажите в комментариях, что больше всего удивило при переходе. Интересно сверить заметки.
#карьера #devops #mlops
❤4🔥4
⚡️ DevOps Digest #11 | 19.04.2026
🔥 Главное за неделю:
1. Ядро Linux 7.0 – Rust стал штатным – включён режим PREEMPT_LAZY по умолчанию, новая ФС Nullfs, поддержка пост-квантовой криптографии ML-DSA и WiFi 8. NFS 4.1 теперь по умолчанию – проверьте монтирование перед обновлением.
https://www.opennet.ru/opennews/art.shtml?num=65194
2. nginx 1.30.0 + OpenSSL 4.0.0 – связка, которая определит следующие два года. nginx получил Encrypted ClientHello, HTTP/2 к бэкендам и sticky sessions. OpenSSL удалил SSLv3 и engine API, добавил постквантовую криптографию. Если у вас HSM через engine (а не provider) – сломается. OpenSSL 3.5 LTS живёт до 2030, не торопитесь.
https://github.com/nginx/nginx/releases/tag/release-1.30.0 | https://github.com/openssl/openssl/releases/tag/openssl-4.0.0
3. RustFS – объектное хранилище, в 2.3 раза быстрее MinIO – S3-совместимое, миграция с MinIO и Ceph из коробки. 1300+ звёзд за неделю. Если выбираете on-premise хранилище – поставьте рядом с MinIO и замерьте на своём профиле.
https://github.com/rustfs/rustfs
4. Критическая уязвимость в Python (CVE-2026-6100, 9.1/10) – use-after-free в модулях lzma, bz2 и gzip. Затронуты все сервисы, распаковывающие сжатые файлы. Обновляйте CPython.
https://www.opennet.ru/opennews/art.shtml?num=65202
5. Бэкдоры в 30 WordPress-плагинах через покупку – злоумышленник скупил 30 плагинов и внедрил вредоносный код во все. Ни код-ревью, ни сканеры не спасают, когда плагин просто меняет владельца. Классика supply chain.
https://anchor.host/someone-bought-30-wordpress-plugins-and-planted-a-backdoor-in-all-of-them/
6. nxs-universal-chart 3.0 – модульный Helm-чарт от Nixys: sub-chart-ы через OCI-реестр, из коробки Istio, KServe, Vault Secret Operator. Открытый проект, Apache 2.0.
https://github.com/nixys/nxs-universal-chart
7. GitHub Stacked PRs – официальный инструмент для цепочек зависимых PR с автоматическим ребейзом. Давняя боль: разбить большое изменение на серию связанных PR.
https://github.github.com/gh-stack/
🔍 Неделя Rust и больших версий
Linux 7.0 перевёл Rust из эксперимента в штатный инструмент ядра. RustFS показывает 2.3x над MinIO. Rust 1.95 стабилизировал if/let guards. Тренд очевиден: критическая инфраструктура переезжает на Rust. Параллельно nginx 1.30 и OpenSSL 4.0 синхронно внедрили ECH – приватность TLS-хендшейка вышла из лаборатории в продакшн. Если обновляете OpenSSL – проверьте, что HSM-интеграции используют provider API, а не устаревший engine.
🛠 Команда дня:
Список образов по размеру – быстрый способ найти раздутые и кандидатов на многоэтапную сборку.
#дайджест #rust #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Ядро Linux 7.0 – Rust стал штатным – включён режим PREEMPT_LAZY по умолчанию, новая ФС Nullfs, поддержка пост-квантовой криптографии ML-DSA и WiFi 8. NFS 4.1 теперь по умолчанию – проверьте монтирование перед обновлением.
https://www.opennet.ru/opennews/art.shtml?num=65194
2. nginx 1.30.0 + OpenSSL 4.0.0 – связка, которая определит следующие два года. nginx получил Encrypted ClientHello, HTTP/2 к бэкендам и sticky sessions. OpenSSL удалил SSLv3 и engine API, добавил постквантовую криптографию. Если у вас HSM через engine (а не provider) – сломается. OpenSSL 3.5 LTS живёт до 2030, не торопитесь.
https://github.com/nginx/nginx/releases/tag/release-1.30.0 | https://github.com/openssl/openssl/releases/tag/openssl-4.0.0
3. RustFS – объектное хранилище, в 2.3 раза быстрее MinIO – S3-совместимое, миграция с MinIO и Ceph из коробки. 1300+ звёзд за неделю. Если выбираете on-premise хранилище – поставьте рядом с MinIO и замерьте на своём профиле.
https://github.com/rustfs/rustfs
4. Критическая уязвимость в Python (CVE-2026-6100, 9.1/10) – use-after-free в модулях lzma, bz2 и gzip. Затронуты все сервисы, распаковывающие сжатые файлы. Обновляйте CPython.
https://www.opennet.ru/opennews/art.shtml?num=65202
5. Бэкдоры в 30 WordPress-плагинах через покупку – злоумышленник скупил 30 плагинов и внедрил вредоносный код во все. Ни код-ревью, ни сканеры не спасают, когда плагин просто меняет владельца. Классика supply chain.
https://anchor.host/someone-bought-30-wordpress-plugins-and-planted-a-backdoor-in-all-of-them/
6. nxs-universal-chart 3.0 – модульный Helm-чарт от Nixys: sub-chart-ы через OCI-реестр, из коробки Istio, KServe, Vault Secret Operator. Открытый проект, Apache 2.0.
https://github.com/nixys/nxs-universal-chart
7. GitHub Stacked PRs – официальный инструмент для цепочек зависимых PR с автоматическим ребейзом. Давняя боль: разбить большое изменение на серию связанных PR.
https://github.github.com/gh-stack/
🔍 Неделя Rust и больших версий
Linux 7.0 перевёл Rust из эксперимента в штатный инструмент ядра. RustFS показывает 2.3x над MinIO. Rust 1.95 стабилизировал if/let guards. Тренд очевиден: критическая инфраструктура переезжает на Rust. Параллельно nginx 1.30 и OpenSSL 4.0 синхронно внедрили ECH – приватность TLS-хендшейка вышла из лаборатории в продакшн. Если обновляете OpenSSL – проверьте, что HSM-интеграции используют provider API, а не устаревший engine.
🛠 Команда дня:
docker image ls --format '{{.Repository}}:{{.Tag}} {{.Size}}' | sort -k2 -hСписок образов по размеру – быстрый способ найти раздутые и кандидатов на многоэтапную сборку.
#дайджест #rust #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
GitHub
Release release-1.30.0 · nginx/nginx
nginx-1.30.0 stable version has been released, incorporating new features and bug fixes from the 1.29.x mainline branch — including Early Hints, HTTP/2 to backend and Encrypted ClientHello, sticky...
🔥6❤1
Пост 2/5: Что конкретно поднял и где DevOps спас
Прежде чем что-то ставить, надо понять, что конкретно ставить. Ваш КО. 😜
Скормил парсеру hh.ru – 272 вакансии "MLOps". Догнал выгрузкой с getmatch – еще 588 за год. Итого: MLflow – 38%, Airflow – 32%, Kubeflow – 16%, DVC – 11%. Требований по SaaS ноль – похоже, рынок облачных ML-платформ в РФ сейчас скорее мертв, чем жив, напишите в комментариях, если что-то не так. Стек выглядит компактным, поэтому точкой входа выбрал MLflow.
Мой подход стандартный: собрать руками и посмотреть, что сломается. Описывал его в DevOps Roadmap.
На сервере уже жили Docker, PostgreSQL и S3. Доставил к ним MLflow – он уютно сел на ту же базу и то же хранилище.
А вот сам MLflow оказался тем, чего мне не хватало, а я и не знал. Это фактически GitLab для экспериментов: запустил обучение – записал параметры, метрики, модель. В UI – табличка, сортировка по точности. Model Registry: теги, алиас production, откат. Запустил
Неа. Пришлось поковыряться с Python-клиентом. Если он обновился, а сервер остался на старой версии, клиент дергает endpoint, которого сервер еще не знает. И делает это молча. Час ковыряния на ровном месте просто потому, что "доверился версии" и иишке.
С артефактами тоже весело. Артефакт модели тут у нас это не один файл, а пачка: сам дамп плюс conda.yaml и requirements.txt. Без них через месяц какой-нибудь scikit-learn обновится, и модель не загрузится. Это как Docker-образ без Dockerfile: запустить сейчас можно, воспроизвести потом уже нет.
И вишенка. Классический реактивный мониторинг тут бесполезен. Сервис жив, latency в норме, всё зеленое, а в ответах мусор. Данные в мире изменились, а модель осталась в прошлом. Ни коммита, ни деплоя, просто мир "поехал" дальше. Для борьбы с этим раскопал Evidently – это такой diff для статистики. Позволяет увидеть дрейф данных до того, как его заметит тот же заказчик.
Итого: MLflow, S3, PostgreSQL, Serving и Evidently. Пять контейнеров, и у тебя полный цикл на одном сервере.
Забавно, как новые знания меняют угол зрения. Оказалось, что у меня в Code Roast та же история: провайдер обновил веса модели и мои оценки кода поплыли. Ни одного коммита с моей стороны, а результат другой. Эталона нет, детекции сдвига нет. Познакомился с дрейфом в ML сразу узнал его паттерны у себя в проде.
В следующем посте – залезем во внутренности MLflow и разберем эксперимент, который показал, что я не логирую и половину того, что стоило бы.
#кейс #ai #mlops
Прежде чем что-то ставить, надо понять, что конкретно ставить. Ваш КО. 😜
Скормил парсеру hh.ru – 272 вакансии "MLOps". Догнал выгрузкой с getmatch – еще 588 за год. Итого: MLflow – 38%, Airflow – 32%, Kubeflow – 16%, DVC – 11%. Требований по SaaS ноль – похоже, рынок облачных ML-платформ в РФ сейчас скорее мертв, чем жив, напишите в комментариях, если что-то не так. Стек выглядит компактным, поэтому точкой входа выбрал MLflow.
Мой подход стандартный: собрать руками и посмотреть, что сломается. Описывал его в DevOps Roadmap.
На сервере уже жили Docker, PostgreSQL и S3. Доставил к ним MLflow – он уютно сел на ту же базу и то же хранилище.
docker compose up, ss -tlnp – порты торчат, логи идут. Пока скучно.А вот сам MLflow оказался тем, чего мне не хватало, а я и не знал. Это фактически GitLab для экспериментов: запустил обучение – записал параметры, метрики, модель. В UI – табличка, сортировка по точности. Model Registry: теги, алиас production, откат. Запустил
mlflow models serve – и у тебя REST endpoint. Curl отправил JSON – получил предсказание. Всё?Неа. Пришлось поковыряться с Python-клиентом. Если он обновился, а сервер остался на старой версии, клиент дергает endpoint, которого сервер еще не знает. И делает это молча. Час ковыряния на ровном месте просто потому, что "доверился версии" и иишке.
С артефактами тоже весело. Артефакт модели тут у нас это не один файл, а пачка: сам дамп плюс conda.yaml и requirements.txt. Без них через месяц какой-нибудь scikit-learn обновится, и модель не загрузится. Это как Docker-образ без Dockerfile: запустить сейчас можно, воспроизвести потом уже нет.
И вишенка. Классический реактивный мониторинг тут бесполезен. Сервис жив, latency в норме, всё зеленое, а в ответах мусор. Данные в мире изменились, а модель осталась в прошлом. Ни коммита, ни деплоя, просто мир "поехал" дальше. Для борьбы с этим раскопал Evidently – это такой diff для статистики. Позволяет увидеть дрейф данных до того, как его заметит тот же заказчик.
Итого: MLflow, S3, PostgreSQL, Serving и Evidently. Пять контейнеров, и у тебя полный цикл на одном сервере.
Забавно, как новые знания меняют угол зрения. Оказалось, что у меня в Code Roast та же история: провайдер обновил веса модели и мои оценки кода поплыли. Ни одного коммита с моей стороны, а результат другой. Эталона нет, детекции сдвига нет. Познакомился с дрейфом в ML сразу узнал его паттерны у себя в проде.
В следующем посте – залезем во внутренности MLflow и разберем эксперимент, который показал, что я не логирую и половину того, что стоило бы.
#кейс #ai #mlops
🔥5❤1
Пост 3/5: Что я нашёл внутри MLflow и чего не нашёл у себя
На прошлой неделе я поднял MLflow и обучил первые модели. Всё выглядело знакомо: параметры, метрики, артефакты. А потом меня осенило, что половину своей работы я вообще не версионирую. Вот что я увидел.
Взял 22 прожарки из своего Code Roast – реальные репо с реальными оценками. У каждой прожарки есть набор метрик: сколько файлов в репо, сколько строк кода, сколько проблем нашли линтеры – trivy, semgrep, bandit. И есть итоговый score по десятибалльной шкале. Задача простая: научить модель предсказывать этот score по метрикам линтеров, без участия человека.
Обучил 8 разных моделей на этих данных. MLflow записал каждый запуск: какие параметры у модели, какую точность показала, сколько весит артефакт. Всё это ложится в таблицу, где можно сортировать и сравнивать. Выглядит как
Результаты, мягко говоря, пока так себе – да и выборка маленькая. Одна из моделей выдала ошибку 18 баллов при шкале-то от 0 до 10. Как обычно: "Петька, приборы?!" — "200!" — "Что 200?" — "А что приборы?". Двенадцать параметров на 22 строки данных – модель заучила шум вместо закономерности.
Лучшая модель (RandomForest) весит 94 КБ. Самая лёгкая (Lasso) – 615 байт. В 155 раз тяжелее, а точнее всего на полбалла. Без таблички бок о бок я бы взял "лес" – звучит-то посолиднее. Но MLflow показал: брать не за что, обе не работают.
Мои Pusk и NORA в Code Roast получили по 8 из 10. Но модель обоим ставит пятёрки. Почему? Модель смотрит на находки линтеров – сколько багов нашёл trivy, сколько подозрительных паттернов поймал semgrep. У чистого кода находок мало. У пустого репо тоже мало. Для модели они выглядят одинаково. А разница между ними – в архитектуре, в тестах, в том, как код организован. Это то, что видит человек при ревью, но ни один линтер не измерит.
Окей, а у самого что там? В Code Roast у меня ровно та же схема: промпты, которые я пишу для анализа кода, набор линтеров, которые запускаю, модель, которая генерирует отчёт. Это полноценный эксперимент – с параметрами, метриками и артефактом на выходе. А я ничего из этого не логирую. Поменял промпт – не записал, как изменился результат. Переключил линтер – не зафиксировал, стало лучше или хуже. Через месяц уже не скажу, какая конфигурация давала лучший результат, потому что сравнивать не с чем. Без конкретных цифр – та же астрология получается.
Привычка "всё в Git и в реджистри" само собой база и спасала не раз, но её мало. Между строчкой кода и результатом в проде есть прослойка из данных и настроек, которую я, получается, бросаю на самотёк. Git версионирует код. Docker Registry версионирует образы. А кто версионирует эксперименты?
Потыкайте: mlflow.devopsway.ru – три эксперимента, реальные данные из Code Roast, 8 моделей.
В следующем посте, что мониторить, когда Prometheus уже зелёный.
#кейс #ai #mlops
На прошлой неделе я поднял MLflow и обучил первые модели. Всё выглядело знакомо: параметры, метрики, артефакты. А потом меня осенило, что половину своей работы я вообще не версионирую. Вот что я увидел.
Взял 22 прожарки из своего Code Roast – реальные репо с реальными оценками. У каждой прожарки есть набор метрик: сколько файлов в репо, сколько строк кода, сколько проблем нашли линтеры – trivy, semgrep, bandit. И есть итоговый score по десятибалльной шкале. Задача простая: научить модель предсказывать этот score по метрикам линтеров, без участия человека.
Обучил 8 разных моделей на этих данных. MLflow записал каждый запуск: какие параметры у модели, какую точность показала, сколько весит артефакт. Всё это ложится в таблицу, где можно сортировать и сравнивать. Выглядит как
git log --oneline, только не для коммитов, а для экспериментов.Результаты, мягко говоря, пока так себе – да и выборка маленькая. Одна из моделей выдала ошибку 18 баллов при шкале-то от 0 до 10. Как обычно: "Петька, приборы?!" — "200!" — "Что 200?" — "А что приборы?". Двенадцать параметров на 22 строки данных – модель заучила шум вместо закономерности.
Лучшая модель (RandomForest) весит 94 КБ. Самая лёгкая (Lasso) – 615 байт. В 155 раз тяжелее, а точнее всего на полбалла. Без таблички бок о бок я бы взял "лес" – звучит-то посолиднее. Но MLflow показал: брать не за что, обе не работают.
Мои Pusk и NORA в Code Roast получили по 8 из 10. Но модель обоим ставит пятёрки. Почему? Модель смотрит на находки линтеров – сколько багов нашёл trivy, сколько подозрительных паттернов поймал semgrep. У чистого кода находок мало. У пустого репо тоже мало. Для модели они выглядят одинаково. А разница между ними – в архитектуре, в тестах, в том, как код организован. Это то, что видит человек при ревью, но ни один линтер не измерит.
Окей, а у самого что там? В Code Roast у меня ровно та же схема: промпты, которые я пишу для анализа кода, набор линтеров, которые запускаю, модель, которая генерирует отчёт. Это полноценный эксперимент – с параметрами, метриками и артефактом на выходе. А я ничего из этого не логирую. Поменял промпт – не записал, как изменился результат. Переключил линтер – не зафиксировал, стало лучше или хуже. Через месяц уже не скажу, какая конфигурация давала лучший результат, потому что сравнивать не с чем. Без конкретных цифр – та же астрология получается.
Привычка "всё в Git и в реджистри" само собой база и спасала не раз, но её мало. Между строчкой кода и результатом в проде есть прослойка из данных и настроек, которую я, получается, бросаю на самотёк. Git версионирует код. Docker Registry версионирует образы. А кто версионирует эксперименты?
Потыкайте: mlflow.devopsway.ru – три эксперимента, реальные данные из Code Roast, 8 моделей.
В следующем посте, что мониторить, когда Prometheus уже зелёный.
#кейс #ai #mlops
❤3🔥3
Пост 4/5: Три модели, ноль мониторинга
В Code Roast работают три LLM-модели. Они анализируют код, перепроверяют друг друга и выставляют оценку. По сути это ML-сервис – только я об этом не думал, пока всё не поехало.
В DevOps мониторинг построен вокруг инфраструктуры: упало, кончилось, тормозит – или вот-вот кончится. Даже проактивные алерты смотрят на те же метрики, просто заглядывают вперёд. Prometheus из коробки этого не увидит. А у меня в какой-то момент провайдер молча обновил модель – и оценки поплыли. Сервис жив, алертов нет, а результат другой. Я это заметил случайно.
На стенде с MLflow я уже видел как работает Evidently – скормил ей два среза данных, она показала что сдвинулось. Но Evidently заточена под классический пайплайн машинного обучения: признаки, предсказания, эталонные ответы. А у меня оценки ревью, находки линтеров, размеры файлов. Другие данные, но вопрос тот же: "что-то поплыло?". Взял саму идею и написал экспортер под свою структуру.
Экспортер лезет в базу, делит ревью пополам по времени и считает статистическую значимость сдвига – та же логика, что у Evidently под капотом, но без тяжёлого обвеса.
Теперь на дашборде рядом с latency и error_rate висят панели дрейфа. Какие метрики поплыли, насколько сильно, что это значит – всё с подсказками прямо на графиках. Ко мне стали нести более тяжёлые проекты, файлы крупнее, находок больше. Экспортер это видит.
Видит, но пока не реагирует. Дашборд показывает дрейф – а дальше что? Нужен эталонный набор репозиториев, который прогоняется после каждого обновления модели. Если оценка эталона уехала – значит модель сменилась и надо разбираться. Нужно версионировать промпты и конфигурации линтеров, чтобы можно было откатиться. Нужен алерт, а не просто график. По сути – тот же CI/CD, только триггер не коммит, а статистика.
Дашборд живой, заходите смотреть, как дрейфуют мои метрики: grafana.devopsway.ru
В следующем посте – чем всё закончилось и что из этого можно повторить за выходные.
#кейс #ai #mlops
В Code Roast работают три LLM-модели. Они анализируют код, перепроверяют друг друга и выставляют оценку. По сути это ML-сервис – только я об этом не думал, пока всё не поехало.
В DevOps мониторинг построен вокруг инфраструктуры: упало, кончилось, тормозит – или вот-вот кончится. Даже проактивные алерты смотрят на те же метрики, просто заглядывают вперёд. Prometheus из коробки этого не увидит. А у меня в какой-то момент провайдер молча обновил модель – и оценки поплыли. Сервис жив, алертов нет, а результат другой. Я это заметил случайно.
На стенде с MLflow я уже видел как работает Evidently – скормил ей два среза данных, она показала что сдвинулось. Но Evidently заточена под классический пайплайн машинного обучения: признаки, предсказания, эталонные ответы. А у меня оценки ревью, находки линтеров, размеры файлов. Другие данные, но вопрос тот же: "что-то поплыло?". Взял саму идею и написал экспортер под свою структуру.
Экспортер лезет в базу, делит ревью пополам по времени и считает статистическую значимость сдвига – та же логика, что у Evidently под капотом, но без тяжёлого обвеса.
Теперь на дашборде рядом с latency и error_rate висят панели дрейфа. Какие метрики поплыли, насколько сильно, что это значит – всё с подсказками прямо на графиках. Ко мне стали нести более тяжёлые проекты, файлы крупнее, находок больше. Экспортер это видит.
Видит, но пока не реагирует. Дашборд показывает дрейф – а дальше что? Нужен эталонный набор репозиториев, который прогоняется после каждого обновления модели. Если оценка эталона уехала – значит модель сменилась и надо разбираться. Нужно версионировать промпты и конфигурации линтеров, чтобы можно было откатиться. Нужен алерт, а не просто график. По сути – тот же CI/CD, только триггер не коммит, а статистика.
Дашборд живой, заходите смотреть, как дрейфуют мои метрики: grafana.devopsway.ru
В следующем посте – чем всё закончилось и что из этого можно повторить за выходные.
#кейс #ai #mlops
🔥3❤1
⚡️ DevOps Digest #12 | 26.04.2026
🔥 Главное за неделю:
1. Kubernetes 1.36 – десять новых alpha-фич. Пять из них связаны с DRA (Dynamic Resource Allocation) для ИИ-нагрузок на GPU, появился планировщик с учётом топологии и рабочих групп, серверный шардинг watch-потоков и отслеживание последнего использования PVC – удобно для чистки забытых томов. Если работаете с GPU в кластерах – пора смотреть.
🔗 https://platformengineering.org/blog/alpha-features-in-kubernetes-1-36
2. В Rust Coreutils нашли 113 уязвимостей – Canonical ограничила внедрение в Ubuntu 26.04. Независимый аудит Zellic выявил 7 критических и 11 серьёзных проблем: повышение привилегий, TOCTOU-гонки, обходы защиты каталогов. В LTS-релиз попадут только cp, mv и rm на Rust, остальные утилиты остаются на GNU. Помните uutils 0.8 из дайджеста #10? Вот продолжение истории: переписать на Rust ≠ сделать безопаснее.
🔗 https://www.opennet.ru/opennews/art.shtml?num=65278
3. RTK – прокси на Rust, сжимающий вывод CLI перед отправкой в LLM на 60–90%. Один бинарник, ноль зависимостей. Переписывает команды (git, cargo, npm, Docker) в фильтрованные эквиваленты. В тестах на 30-минутной сессии с Claude Code сократил 118 тыс. токенов до 24 тыс. (–80%). Поддерживает 12 ИИ-ассистентов. 35 800 звёзд.
🔗 https://github.com/rtk-ai/rtk
4. OpenSRE – открытый фреймворк для ИИ-агентов инцидент-менеджмента. При срабатывании алерта агент собирает контекст (логи, метрики, трейсы), анализирует корневую причину, генерирует отчёт и предлагает исправления. Интеграции с 60+ инструментами (Grafana, Datadog, Kubernetes). Поддерживает Anthropic, OpenAI, Ollama – можно запускать полностью локально. 3 200 звёзд.
🔗 https://github.com/Tracer-Cloud/opensre
5. Валидация K8s-манифестов в CI: kubeconform + Kyverno. Практический разбор: kubeconform ловит структурные ошибки (неверные apiVersion, битые поля) на этапе пулл-реквеста, Kyverno обеспечивает политики на уровне кластера с точечными исключениями через лейблы. Сдвиг проверки влево – ошибки не доезжают до ArgoCD.
🔗 https://dev.to/futhgar/stop-merging-broken-yaml-kubernetes-manifest-validation-in-ci-52g9
🔍 ИИ в инфраструктуре и разработке: от K8s до инцидент-менеджмента
В Kubernetes 1.36 завезли пять улучшений в рамках DRA (Dynamic Resource Allocation). Теперь планировщик лучше понимает специфику ИИ-нагрузок, оптимизируя выделение ресурсов. Параллельно развиваются агентские инструменты: OpenSRE берёт на себя первичный анализ инцидентов, а RTK решает проблему "раздутого" контекста для LLM-ассистентов.
На фоне этого – важный кейс Rust Coreutils. Проект, который часто позиционируют как безопасную замену GNU, собрал 113 уязвимостей. Это ещё раз подтверждает: переход на Rust не гарантирует отсутствие багов в логике, а глубокий аудит остается обязательным процессом вне зависимости от выбранного стека.
🛠 Команда дня:
Последние 20 предупреждений кластера – стартовая точка для любого SRE-расследования. Если у вас нет этого алиаса – самое время добавить.
#дайджест #kubernetes #rust #ai
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Kubernetes 1.36 – десять новых alpha-фич. Пять из них связаны с DRA (Dynamic Resource Allocation) для ИИ-нагрузок на GPU, появился планировщик с учётом топологии и рабочих групп, серверный шардинг watch-потоков и отслеживание последнего использования PVC – удобно для чистки забытых томов. Если работаете с GPU в кластерах – пора смотреть.
🔗 https://platformengineering.org/blog/alpha-features-in-kubernetes-1-36
2. В Rust Coreutils нашли 113 уязвимостей – Canonical ограничила внедрение в Ubuntu 26.04. Независимый аудит Zellic выявил 7 критических и 11 серьёзных проблем: повышение привилегий, TOCTOU-гонки, обходы защиты каталогов. В LTS-релиз попадут только cp, mv и rm на Rust, остальные утилиты остаются на GNU. Помните uutils 0.8 из дайджеста #10? Вот продолжение истории: переписать на Rust ≠ сделать безопаснее.
🔗 https://www.opennet.ru/opennews/art.shtml?num=65278
3. RTK – прокси на Rust, сжимающий вывод CLI перед отправкой в LLM на 60–90%. Один бинарник, ноль зависимостей. Переписывает команды (git, cargo, npm, Docker) в фильтрованные эквиваленты. В тестах на 30-минутной сессии с Claude Code сократил 118 тыс. токенов до 24 тыс. (–80%). Поддерживает 12 ИИ-ассистентов. 35 800 звёзд.
🔗 https://github.com/rtk-ai/rtk
4. OpenSRE – открытый фреймворк для ИИ-агентов инцидент-менеджмента. При срабатывании алерта агент собирает контекст (логи, метрики, трейсы), анализирует корневую причину, генерирует отчёт и предлагает исправления. Интеграции с 60+ инструментами (Grafana, Datadog, Kubernetes). Поддерживает Anthropic, OpenAI, Ollama – можно запускать полностью локально. 3 200 звёзд.
🔗 https://github.com/Tracer-Cloud/opensre
5. Валидация K8s-манифестов в CI: kubeconform + Kyverno. Практический разбор: kubeconform ловит структурные ошибки (неверные apiVersion, битые поля) на этапе пулл-реквеста, Kyverno обеспечивает политики на уровне кластера с точечными исключениями через лейблы. Сдвиг проверки влево – ошибки не доезжают до ArgoCD.
🔗 https://dev.to/futhgar/stop-merging-broken-yaml-kubernetes-manifest-validation-in-ci-52g9
🔍 ИИ в инфраструктуре и разработке: от K8s до инцидент-менеджмента
В Kubernetes 1.36 завезли пять улучшений в рамках DRA (Dynamic Resource Allocation). Теперь планировщик лучше понимает специфику ИИ-нагрузок, оптимизируя выделение ресурсов. Параллельно развиваются агентские инструменты: OpenSRE берёт на себя первичный анализ инцидентов, а RTK решает проблему "раздутого" контекста для LLM-ассистентов.
На фоне этого – важный кейс Rust Coreutils. Проект, который часто позиционируют как безопасную замену GNU, собрал 113 уязвимостей. Это ещё раз подтверждает: переход на Rust не гарантирует отсутствие багов в логике, а глубокий аудит остается обязательным процессом вне зависимости от выбранного стека.
🛠 Команда дня:
kubectl get events -A --field-selector type=Warning --sort-by='.lastTimestamp' | tail -20
Последние 20 предупреждений кластера – стартовая точка для любого SRE-расследования. Если у вас нет этого алиаса – самое время добавить.
#дайджест #kubernetes #rust #ai
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
platformengineering.org
Alpha features in Kubernetes 1.36
Explore the top 10 new Alpha features in Kubernetes 1.36. Learn about 5 DRA advancements for AI/ML workloads, workload-aware scheduling, new security policies, and major scalability gains
👍4❤1
Пост 5/5: Что оказалось за дверью
"Ничто не вечно под луной" Н.М. Карамзин
DevOps родился, когда код писали люди. На прошлой неделе Пичаи на Google Cloud Next выдал: 75% нового кода в Google пишет ИИ. Полтора года назад было 25%. Реальность, под которую мы строили свои пайплайны, тихо уехала – как те самые данные из четвёртого поста.
В первом посте я прикинул: 70% MLOps – это знакомый DevOps, 30% – что-то новое. Четыре поста спустя я могу точно сказать, что это за 30%.
1. Код – это верхушка айсберга. Ещё в 2015-м ребята из Google написали статью "Hidden Technical Debt in ML Systems". Смысл простой: сам ML-код – это крошечный квадрат в центре. Всё остальное – инфраструктура: сбор данных, валидация, обслуживание запросов, мониторинг. Её на порядок больше, чем самого кода модели. Мы подняли 5 контейнеров и увидели только фасад. За той же дверью – хранилища признаков (feature stores), валидация схем данных и ещё много всего, до чего мы даже не дошли.
2. Данные рулят кодом, а не наоборот. В DevOps код управляет системой. В ML данные управляют кодом. Модель – это производная от данных. Google ввёл термин CT (Continuous Training) не ради красоты. Это реальность: данные сдвинулись – модель пересобирается сама. Код при этом никто не трогал. DevOps-пайплайн – это конвейер от коммита до прода. ML-пайплайн – это кольцо: данные → модель → прод → новые данные → переобучение.
3. Код перестал быть предсказуемым. Пока я ковырялся в MLflow, выяснилось кое-что ещё. Когда Copilot пишет за тебя половину функций, промпт становится гиперпараметром, а обновление модели у провайдера – дрейфом. По статистике CodeRabbit (470 реальных пулл-реквестов), ИИ-код даёт в 1.7 раза больше дефектов. Это не "плохо", это значит, что код стал стохастическим. А такие системы требуют не просто линтеров, а статистической валидации. То есть – MLOps.
Я увидел это на своём Code Roast раньше, чем прочитал в статьях: провайдер обновил модель – оценки поплыли – ни одного моего коммита. Дашборд это показал, но обратная связь ещё не замкнута. Это то, что Microsoft называет первым уровнем: "DevOps есть, MLOps ещё нет". Стартовая точка, не финиш.
Что можно сделать за выходные, чтобы не остаться в прошлом:
1.
2. Обучить модель на своих данных – хоть на времени сборки пайплайнов, хоть на метриках алертов.
3.
4. Разделить данные пополам по времени и посчитать сдвиг (дрейф).
Первые три шага – чистый DevOps. Четвёртый – тот самый новый слой, который меняет угол зрения.
DevOps строили для мира, где код пишут люди. Этот мир меняется. MLOps – это не параллельная вселенная, а следующий уровень того же стека. А за ним уже маячит AIOps, но это уже совсем другая дверь.
Стенды всё ещё живые, заходите, буду развивать их:
mlflow.devopsway.ru
grafana.devopsway.ru
#мышление #ai #mlops
"Ничто не вечно под луной" Н.М. Карамзин
DevOps родился, когда код писали люди. На прошлой неделе Пичаи на Google Cloud Next выдал: 75% нового кода в Google пишет ИИ. Полтора года назад было 25%. Реальность, под которую мы строили свои пайплайны, тихо уехала – как те самые данные из четвёртого поста.
В первом посте я прикинул: 70% MLOps – это знакомый DevOps, 30% – что-то новое. Четыре поста спустя я могу точно сказать, что это за 30%.
1. Код – это верхушка айсберга. Ещё в 2015-м ребята из Google написали статью "Hidden Technical Debt in ML Systems". Смысл простой: сам ML-код – это крошечный квадрат в центре. Всё остальное – инфраструктура: сбор данных, валидация, обслуживание запросов, мониторинг. Её на порядок больше, чем самого кода модели. Мы подняли 5 контейнеров и увидели только фасад. За той же дверью – хранилища признаков (feature stores), валидация схем данных и ещё много всего, до чего мы даже не дошли.
2. Данные рулят кодом, а не наоборот. В DevOps код управляет системой. В ML данные управляют кодом. Модель – это производная от данных. Google ввёл термин CT (Continuous Training) не ради красоты. Это реальность: данные сдвинулись – модель пересобирается сама. Код при этом никто не трогал. DevOps-пайплайн – это конвейер от коммита до прода. ML-пайплайн – это кольцо: данные → модель → прод → новые данные → переобучение.
3. Код перестал быть предсказуемым. Пока я ковырялся в MLflow, выяснилось кое-что ещё. Когда Copilot пишет за тебя половину функций, промпт становится гиперпараметром, а обновление модели у провайдера – дрейфом. По статистике CodeRabbit (470 реальных пулл-реквестов), ИИ-код даёт в 1.7 раза больше дефектов. Это не "плохо", это значит, что код стал стохастическим. А такие системы требуют не просто линтеров, а статистической валидации. То есть – MLOps.
Я увидел это на своём Code Roast раньше, чем прочитал в статьях: провайдер обновил модель – оценки поплыли – ни одного моего коммита. Дашборд это показал, но обратная связь ещё не замкнута. Это то, что Microsoft называет первым уровнем: "DevOps есть, MLOps ещё нет". Стартовая точка, не финиш.
Что можно сделать за выходные, чтобы не остаться в прошлом:
1.
docker compose up – MLflow, PostgreSQL, S3. Наша база.2. Обучить модель на своих данных – хоть на времени сборки пайплайнов, хоть на метриках алертов.
3.
mlflow models serve – превратить модель в API.4. Разделить данные пополам по времени и посчитать сдвиг (дрейф).
Первые три шага – чистый DevOps. Четвёртый – тот самый новый слой, который меняет угол зрения.
DevOps строили для мира, где код пишут люди. Этот мир меняется. MLOps – это не параллельная вселенная, а следующий уровень того же стека. А за ним уже маячит AIOps, но это уже совсем другая дверь.
Стенды всё ещё живые, заходите, буду развивать их:
mlflow.devopsway.ru
grafana.devopsway.ru
#мышление #ai #mlops
🔥4❤1
MLOps: 70% DevOps, 30% магии или просто другой Airflow?
Открываешь roadmap.sh/mlops – и хочется закрыть. Там 90+ тем, от Feature Stores до Data Labeling, которые выглядят как план захвата Луны. Но рынок диктует другие правила. Я взял 838 реальных вакансий (getmatch + hh.ru) и "прожарил" их данными, чтобы понять, за что на самом деле платят деньги.
Спойлер:roadmap.sh вам врет.
Главное из разбора:
1. 10 из 12 ключевых навыков – это чистый DevOps. Python (85%), K8s (80%), Docker и CI/CD – база, которая закрывает 80% требований.
2. Специфика начинается с 11-го места. Весь ваш "входной билет" в MLOps – это джентльменский набор из Airflow и MLflow. Каждый встречается в 50% вакансий на роль MLOps.
3. Кладбище хайпа. Инструменты вроде W&B, Neptune или Feast имеют 0 (ноль) упоминаний в 566 вакансиях getmatch. Учить их сейчас – как учить суахили для поездки в Тулу.
4. Деньги на столе. Медиана рынка – 325К на руки. Хотите 400К+? Придется копать в сторону GPU-специфики: CUDA, Triton и деплой LLM.
Полный разбор: зарплатная пирамида, почему AWS не нужен в РФ и план перехода из DevOps за 5 шагов – уже в статье.
🔗 devopsway.ru/posts/mlops-roadmap/
#mlops #devops #карьера #datadriven
Открываешь roadmap.sh/mlops – и хочется закрыть. Там 90+ тем, от Feature Stores до Data Labeling, которые выглядят как план захвата Луны. Но рынок диктует другие правила. Я взял 838 реальных вакансий (getmatch + hh.ru) и "прожарил" их данными, чтобы понять, за что на самом деле платят деньги.
Спойлер:
Главное из разбора:
1. 10 из 12 ключевых навыков – это чистый DevOps. Python (85%), K8s (80%), Docker и CI/CD – база, которая закрывает 80% требований.
2. Специфика начинается с 11-го места. Весь ваш "входной билет" в MLOps – это джентльменский набор из Airflow и MLflow. Каждый встречается в 50% вакансий на роль MLOps.
3. Кладбище хайпа. Инструменты вроде W&B, Neptune или Feast имеют 0 (ноль) упоминаний в 566 вакансиях getmatch. Учить их сейчас – как учить суахили для поездки в Тулу.
4. Деньги на столе. Медиана рынка – 325К на руки. Хотите 400К+? Придется копать в сторону GPU-специфики: CUDA, Triton и деплой LLM.
Полный разбор: зарплатная пирамида, почему AWS не нужен в РФ и план перехода из DevOps за 5 шагов – уже в статье.
🔗 devopsway.ru/posts/mlops-roadmap/
#mlops #devops #карьера #datadriven
🔥5❤2
⚡️ DevOps Digest #13 | 03.05.2026
🔥 Главное:
1. Copy Fail (CVE-2026-31431) – эскалация до root в ядре Linux. Уязвимость в подсистеме AF_ALG затрагивает все дистрибутивы с ядром начиная с 4.14. Эксплоит публичный – патчите немедленно.
🔗 https://www.opennet.ru/opennews/art.shtml?num=65325
2. Proxmox Backup Server 4.2 – обновление self-hosted системы резервного копирования. Бесплатные репозитории обновлений, поддержка бэкапов виртуальных машин и контейнеров. Хорошая альтернатива коммерческим решениям для тех, кто строит инфраструктуру на Proxmox.
🔗 https://www.opennet.ru/opennews/art.shtml?num=65338
3. DevSecOps на практике: как встроить SAST в CI/CD для кода, написанного с помощью LLM. Автор подключил SonarCloud и Semgrep к пайплайну, настроил Quality Gate как блокировщик деплоя и показал реальные цифры – 234 проблемы в проекте, сгенерированном нейросетью.
🔗 https://habr.com/ru/companies/ruvds/articles/1017858/
4. Cilium и eBPF – новая парадигма сетевого стека в Kubernetes. Разбор того, как eBPF-программы заменяют kube-proxy и iptables, объединяя сетевые политики, безопасность и наблюдаемость (Hubble) прямо в ядре Linux.
🔗 https://dev.to/fundacjadobrepanstwo/cilium-and-ebpf-the-new-networking-paradigm-in-kubernetes-3oeb
5. SeaweedFS набирает популярность – 311 звёзд за неделю. Распределённое хранилище с поддержкой S3 API, файловых систем и таблиц Iceberg. Горизонтальное масштабирование и O(1) доступ к диску – серьёзная self-hosted альтернатива облачным объектным хранилищам.
🔗 https://github.com/seaweedfs/seaweedfs
🔍 eBPF вытесняет iptables из Kubernetes
Замена kube-proxy на Cilium – уже не эксперимент, а осознанный выбор для кластеров от 50 узлов. Ключевое преимущество – не скорость (хотя она тоже есть), а единая точка наблюдения: сетевые политики, шифрование между подами и метрики трафика живут в одном месте вместо разрозненных инструментов. Если планируете переход – начните с Cilium в режиме совместимости с kube-proxy, чтобы откатиться без простоя.
🛠 Команда дня:
Проверяет, активен ли модуль algif_aead — именно он содержит уязвимость Copy Fail (CVE-2026-31431). Модуль предоставляет доступ к AEAD-шифрованию ядра через сокеты, реально нужен только на embedded/IoT-устройствах. На серверах и десктопах не используется — TLS, LUKS и VPN работают через userspace-библиотеки или другие модули ядра. Даже если модуль не загружен сейчас, локальный пользователь может триггернуть его автозагрузку.
Заблокируйте:
#дайджест #security #kubernetes
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное:
1. Copy Fail (CVE-2026-31431) – эскалация до root в ядре Linux. Уязвимость в подсистеме AF_ALG затрагивает все дистрибутивы с ядром начиная с 4.14. Эксплоит публичный – патчите немедленно.
🔗 https://www.opennet.ru/opennews/art.shtml?num=65325
2. Proxmox Backup Server 4.2 – обновление self-hosted системы резервного копирования. Бесплатные репозитории обновлений, поддержка бэкапов виртуальных машин и контейнеров. Хорошая альтернатива коммерческим решениям для тех, кто строит инфраструктуру на Proxmox.
🔗 https://www.opennet.ru/opennews/art.shtml?num=65338
3. DevSecOps на практике: как встроить SAST в CI/CD для кода, написанного с помощью LLM. Автор подключил SonarCloud и Semgrep к пайплайну, настроил Quality Gate как блокировщик деплоя и показал реальные цифры – 234 проблемы в проекте, сгенерированном нейросетью.
🔗 https://habr.com/ru/companies/ruvds/articles/1017858/
4. Cilium и eBPF – новая парадигма сетевого стека в Kubernetes. Разбор того, как eBPF-программы заменяют kube-proxy и iptables, объединяя сетевые политики, безопасность и наблюдаемость (Hubble) прямо в ядре Linux.
🔗 https://dev.to/fundacjadobrepanstwo/cilium-and-ebpf-the-new-networking-paradigm-in-kubernetes-3oeb
5. SeaweedFS набирает популярность – 311 звёзд за неделю. Распределённое хранилище с поддержкой S3 API, файловых систем и таблиц Iceberg. Горизонтальное масштабирование и O(1) доступ к диску – серьёзная self-hosted альтернатива облачным объектным хранилищам.
🔗 https://github.com/seaweedfs/seaweedfs
🔍 eBPF вытесняет iptables из Kubernetes
Замена kube-proxy на Cilium – уже не эксперимент, а осознанный выбор для кластеров от 50 узлов. Ключевое преимущество – не скорость (хотя она тоже есть), а единая точка наблюдения: сетевые политики, шифрование между подами и метрики трафика живут в одном месте вместо разрозненных инструментов. Если планируете переход – начните с Cilium в режиме совместимости с kube-proxy, чтобы откатиться без простоя.
🛠 Команда дня:
lsmod | grep -q algif_aead && echo "⚠️ algif_aead ЗАГРУЖЕН — вы уязвимы" || echo "✅ algif_aead не загружен"
Проверяет, активен ли модуль algif_aead — именно он содержит уязвимость Copy Fail (CVE-2026-31431). Модуль предоставляет доступ к AEAD-шифрованию ядра через сокеты, реально нужен только на embedded/IoT-устройствах. На серверах и десктопах не используется — TLS, LUKS и VPN работают через userspace-библиотеки или другие модули ядра. Даже если модуль не загружен сейчас, локальный пользователь может триггернуть его автозагрузку.
Заблокируйте:
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/cve-2026-31431.conf
#дайджест #security #kubernetes
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥6
Общая память: почему .md – это не RAG
В серии про "Барьер" я топил за то, что нельзя становиться био-адаптером для нейронки. Нужно выходить на уровень архитектора.
Знаете момент в "Матрице", когда Нео открывает глаза и говорит "I know kung fu"? Ему загрузили программу напрямую в мозг.
Теперь представьте Нео, у которого загрузка слетает каждые два часа. Он снова не знает кунг-фу. Каждый спарринг начинается с "а что такое удар?".
Вот так работает AI-ассистент без памяти. Каждая сессия – чистый лист. Ты заново объясняешь структуру проекта, свои конвенции, свои баги. Цифровая деменция.
Главный вопрос после тех постов: как сделать так, чтобы AI не "забывал" контекст через два часа?
Обычно предлагают два пути:
1. Закинуть всё в CLAUDE.md или скармливать Obsidian-плагинам.
2. Поднимать RAG.
Первый вариант работает до определённого масштаба. Пока у тебя 50 заметок и один проект, .md хватает. Но у этого подхода есть "стеклянный потолок". Например, Claude Code принудительно обрезает CLAUDE.md после ~200 строк. Даже если скормить модели огромный файл целиком, вступает в силу эффект Lost in the Middle: модели хуже извлекают данные из середины длинного контекста (это подтверждено тестами ребят из Stanford и Anthropic). Кроме того, это статика: спрашиваешь про Rust, а модель "переваривает" и твои заметки по Python, просто потому что они лежат в том же файле.
RAG (Retrieval-Augmented Generation) – это уже не просто "положи файл". Здесь речь про динамику и фильтрацию.
Например, у меня сейчас:
180+ файлов памяти (заметки, логи, база знаний).
11 000+ только профильных DevOps-фрагментов (всего в базе под 300к векторов).
Векторный стор (Qdrant) + семантический поиск.
Это и есть "человек в цепочке". Я сам решаю, что пойдет в индекс и как оно режется на чанки. RAG не пихает в модель всё подряд – он делает семантический поиск и отдает только те куски, которые релевантны текущему вопросу. В итоге ассистент не просто "умный", он контекстный. Он знает специфику именно моего кода и старые баги моих проектов.
Многие боятся лезть в RAG, думая, что нужны серверные стойки.
Спойлер: GPU не нужен .
Для персональной базы знаний в пару тысяч фрагментов Qdrant занимает ~100 МБ оперативки – это действительно уровень одной вкладки Chrome. У меня на 300к векторов база потребляет 4.7 ГБ RAM, работая на обычном CPU. Поиск по смыслу при этом происходит мгновенно.
В следующих постах и заметках в блоге попробуем собрать пайплайн с нуля.
Скоро про Qdrant. Минимум теории, только конфиги и запуск.
#миникурс #мышление
В серии про "Барьер" я топил за то, что нельзя становиться био-адаптером для нейронки. Нужно выходить на уровень архитектора.
Знаете момент в "Матрице", когда Нео открывает глаза и говорит "I know kung fu"? Ему загрузили программу напрямую в мозг.
Теперь представьте Нео, у которого загрузка слетает каждые два часа. Он снова не знает кунг-фу. Каждый спарринг начинается с "а что такое удар?".
Вот так работает AI-ассистент без памяти. Каждая сессия – чистый лист. Ты заново объясняешь структуру проекта, свои конвенции, свои баги. Цифровая деменция.
Главный вопрос после тех постов: как сделать так, чтобы AI не "забывал" контекст через два часа?
Обычно предлагают два пути:
1. Закинуть всё в CLAUDE.md или скармливать Obsidian-плагинам.
2. Поднимать RAG.
Первый вариант работает до определённого масштаба. Пока у тебя 50 заметок и один проект, .md хватает. Но у этого подхода есть "стеклянный потолок". Например, Claude Code принудительно обрезает CLAUDE.md после ~200 строк. Даже если скормить модели огромный файл целиком, вступает в силу эффект Lost in the Middle: модели хуже извлекают данные из середины длинного контекста (это подтверждено тестами ребят из Stanford и Anthropic). Кроме того, это статика: спрашиваешь про Rust, а модель "переваривает" и твои заметки по Python, просто потому что они лежат в том же файле.
RAG (Retrieval-Augmented Generation) – это уже не просто "положи файл". Здесь речь про динамику и фильтрацию.
Например, у меня сейчас:
180+ файлов памяти (заметки, логи, база знаний).
11 000+ только профильных DevOps-фрагментов (всего в базе под 300к векторов).
Векторный стор (Qdrant) + семантический поиск.
Это и есть "человек в цепочке". Я сам решаю, что пойдет в индекс и как оно режется на чанки. RAG не пихает в модель всё подряд – он делает семантический поиск и отдает только те куски, которые релевантны текущему вопросу. В итоге ассистент не просто "умный", он контекстный. Он знает специфику именно моего кода и старые баги моих проектов.
Многие боятся лезть в RAG, думая, что нужны серверные стойки.
Спойлер:
Для персональной базы знаний в пару тысяч фрагментов Qdrant занимает ~100 МБ оперативки – это действительно уровень одной вкладки Chrome. У меня на 300к векторов база потребляет 4.7 ГБ RAM, работая на обычном CPU. Поиск по смыслу при этом происходит мгновенно.
В следующих постах и заметках в блоге попробуем собрать пайплайн с нуля.
Скоро про Qdrant. Минимум теории, только конфиги и запуск.
#миникурс #мышление
🔥8❤1
Как понять, что ты стал чужим KPI, а не кандидатом
"Ходит дурачок по лесу,
ищет дурачок глупее себя"
– Егор Летов
Недавно со мной общался AI-бот от крупной компании. Четыре раунда глубоких вопросов: архитектура моей платформы, стек, метрики, бюджеты. По сути бесплатный консалтинг на полчаса.
В ответ на мои вопросы о зарплате, стеке и локации бот выдавал "нет информации". Через три недели шаблонный отказ без фидбека (сами нашли, сами написали, сами отказали, молодцы). Система не оценивала мою экспертизу, она её тупо собирала. Это не скрининг, а экстракция данных какая-то под видом интервью.
Красные флаги, что вы строчка в отчёте:
– Односторонний обмен. Бот вытягивает детали архитектуры, но не дает конкретики по вакансии.
– Барьер из чат-ботов. Вас не пускают к живому человеку, так как бот собирает данные дешевле и быстрее.
– Зарплата на первой минуте. Сбор рыночных вилок без контекста задач и стека.
– Рекрутер "на подмене". Человек в чате не знает деталей позиции и работает просто как оператор эксельки.
– Документы до этапов. Просьба прислать трудовую "для белого списка" еще до технического интервью.
– Фантомные вакансии. В 2026 году до 40% вакансий просто фейки для создания видимости рынка или сбора аналитики.
Что с этим делать:
– Выходите на нанимающих напрямую. LinkedIn, митапы или рефералы позволяют обойти "сборочный цех" ботов.
– Соблюдайте пропорциональность. Глубина вашего ответа должна соответствовать прозрачности вакансии. Не назвали стек – не расписывайте архитектуру.
– Тестируйте инверсией. Спросите бота или рекрутера: "Какую техническую боль команда решала в прошлом квартале?". Шаблонный ответ – признак мертвой вакансии.
– Никаких документов до оффера. Паспорт и трудовая передаются только при оформлении.
– Если чувствуете, что вас гоняют по кругу – вы не в найме, а в чужой отчетности.
Если хочешь разобрать свою стратегию поиска и перестать быть чужим KPI – записывайся на разбор:
calendly.com/devitway/meet-with-me
#devops #карьера
"Ходит дурачок по лесу,
ищет дурачок глупее себя"
– Егор Летов
Недавно со мной общался AI-бот от крупной компании. Четыре раунда глубоких вопросов: архитектура моей платформы, стек, метрики, бюджеты. По сути бесплатный консалтинг на полчаса.
В ответ на мои вопросы о зарплате, стеке и локации бот выдавал "нет информации". Через три недели шаблонный отказ без фидбека (сами нашли, сами написали, сами отказали, молодцы). Система не оценивала мою экспертизу, она её тупо собирала. Это не скрининг, а экстракция данных какая-то под видом интервью.
Красные флаги, что вы строчка в отчёте:
– Односторонний обмен. Бот вытягивает детали архитектуры, но не дает конкретики по вакансии.
– Барьер из чат-ботов. Вас не пускают к живому человеку, так как бот собирает данные дешевле и быстрее.
– Зарплата на первой минуте. Сбор рыночных вилок без контекста задач и стека.
– Рекрутер "на подмене". Человек в чате не знает деталей позиции и работает просто как оператор эксельки.
– Документы до этапов. Просьба прислать трудовую "для белого списка" еще до технического интервью.
– Фантомные вакансии. В 2026 году до 40% вакансий просто фейки для создания видимости рынка или сбора аналитики.
Что с этим делать:
– Выходите на нанимающих напрямую. LinkedIn, митапы или рефералы позволяют обойти "сборочный цех" ботов.
– Соблюдайте пропорциональность. Глубина вашего ответа должна соответствовать прозрачности вакансии. Не назвали стек – не расписывайте архитектуру.
– Тестируйте инверсией. Спросите бота или рекрутера: "Какую техническую боль команда решала в прошлом квартале?". Шаблонный ответ – признак мертвой вакансии.
– Никаких документов до оффера. Паспорт и трудовая передаются только при оформлении.
– Если чувствуете, что вас гоняют по кругу – вы не в найме, а в чужой отчетности.
Если хочешь разобрать свою стратегию поиска и перестать быть чужим KPI – записывайся на разбор:
calendly.com/devitway/meet-with-me
#devops #карьера
🔥4👍2❤1
⚡️ DevOps Digest #14 | 10.05.2026
🔥 Главное за неделю:
1. Cilium: практики защиты CI/CD в open-source проекте. Команда Cilium опубликовала разбор того, как они защищают свой конвейер сборки – актуально для любого, кто поддерживает CI/CD с публичными контрибьюторами и supply-chain рисками.
🔗 https://cilium.io/blog/2026/05/06/securing-cicd-open-source-lessons-from-cilium
2. Kubescape набирает обороты – open-source платформа безопасности Kubernetes для IDE, CI/CD и кластеров. Сканирование на соответствие стандартам, поиск мисконфигураций, анализ рисков. Работает локально, без привязки к облачным вендорам.
🔗 https://github.com/kubescape/kubescape
3. Gitleaks – поиск секретов в репозиториях продолжает расти (230 звёзд за неделю). Инструмент для интеграции в CI/CD: сканирует коммиты, pre-commit хуки, целые репозитории на предмет утечек ключей, токенов и паролей.
🔗 https://github.com/gitleaks/gitleaks
4. Импортозамещение: централизованная аутентификация в Linux. Практический опыт интегратора по настройке аутентификации в закрытом контуре – FreeIPA, SSSD, работа с отечественными дистрибутивами. Полезно тем, кто мигрирует с Active Directory.
🔗 https://habr.com/ru/companies/astralinux/articles/1023816/
🔍 Безопасность CI/CD – не только про код
Cilium показал, что защита пайплайна – это не только сканирование образов. Это подписание артефактов, ограничение прав GitHub Actions runners, изоляция секретов между окружениями и аудит доступа контрибьюторов. Если у вас в CI есть хотя бы один step с доступом к продовым секретам – стоит пройтись по их чеклисту.
🛠 Команда дня:
Сканирует кластер Kubernetes на мисконфигурации и соответствие стандартам безопасности (NSA, MITRE). Работает без облачного аккаунта
#дайджест #security #cicd
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Cilium: практики защиты CI/CD в open-source проекте. Команда Cilium опубликовала разбор того, как они защищают свой конвейер сборки – актуально для любого, кто поддерживает CI/CD с публичными контрибьюторами и supply-chain рисками.
🔗 https://cilium.io/blog/2026/05/06/securing-cicd-open-source-lessons-from-cilium
2. Kubescape набирает обороты – open-source платформа безопасности Kubernetes для IDE, CI/CD и кластеров. Сканирование на соответствие стандартам, поиск мисконфигураций, анализ рисков. Работает локально, без привязки к облачным вендорам.
🔗 https://github.com/kubescape/kubescape
3. Gitleaks – поиск секретов в репозиториях продолжает расти (230 звёзд за неделю). Инструмент для интеграции в CI/CD: сканирует коммиты, pre-commit хуки, целые репозитории на предмет утечек ключей, токенов и паролей.
🔗 https://github.com/gitleaks/gitleaks
4. Импортозамещение: централизованная аутентификация в Linux. Практический опыт интегратора по настройке аутентификации в закрытом контуре – FreeIPA, SSSD, работа с отечественными дистрибутивами. Полезно тем, кто мигрирует с Active Directory.
🔗 https://habr.com/ru/companies/astralinux/articles/1023816/
🔍 Безопасность CI/CD – не только про код
Cilium показал, что защита пайплайна – это не только сканирование образов. Это подписание артефактов, ограничение прав GitHub Actions runners, изоляция секретов между окружениями и аудит доступа контрибьюторов. Если у вас в CI есть хотя бы один step с доступом к продовым секретам – стоит пройтись по их чеклисту.
🛠 Команда дня:
kubescape scan --enable-host-scan --format pretty-printer
Сканирует кластер Kubernetes на мисконфигурации и соответствие стандартам безопасности (NSA, MITRE). Работает без облачного аккаунта
#дайджест #security #cicd
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
cilium.io
Securing CI/CD for an open source project: lessons from Cilium
A case study of how Cilium secures its CI/CD pipeline end to end: SHA-pinned actions, two-phase checkouts for pull_request_target, Re...
🔥4
RAG Pipeline 1/N: Qdrant
Qdrant – векторная БД. Текст превращается в массив из 384 чисел. Два похожих текста дают похожие массивы. Косинусная близость (Cosine similarity) между "reverse proxy" и "проксирование запросов" – 0.94. Между "reverse proxy" и "рецепт борща" – 0.12. PostgreSQL с LIKE так не умеет.
В посте практика от docker run до семантического поиска на Python. Без теории ради теории: запустил, создал коллекцию, загрузил данные, нашёл по смыслу. Плюс продакшен-параметры из моего рабочего pipeline: 16 446 чанков, 384 измерения, systemd timer на синхронизацию.
Это первый пост серии RAG Pipeline.
Следующий – про embeddings: Ollama vs API, подводные камни с русским текстом.
👉 devopsway.ru/posts/rag-01-qdrant-vectors/
#кейс #ai
Qdrant – векторная БД. Текст превращается в массив из 384 чисел. Два похожих текста дают похожие массивы. Косинусная близость (Cosine similarity) между "reverse proxy" и "проксирование запросов" – 0.94. Между "reverse proxy" и "рецепт борща" – 0.12. PostgreSQL с LIKE так не умеет.
В посте практика от docker run до семантического поиска на Python. Без теории ради теории: запустил, создал коллекцию, загрузил данные, нашёл по смыслу. Плюс продакшен-параметры из моего рабочего pipeline: 16 446 чанков, 384 измерения, systemd timer на синхронизацию.
Это первый пост серии RAG Pipeline.
Следующий – про embeddings: Ollama vs API, подводные камни с русским текстом.
👉 devopsway.ru/posts/rag-01-qdrant-vectors/
#кейс #ai
🔥6❤1
RAG Pipeline 2/N: Embeddings
Embedding-модель превращает текст в массив чисел. От выбора модели зависит, найдёт ваш RAG правильный фрагмент или вернёт мусор.
Взял три модели из Ollama и скормил им пару фраз на русском: "настройка reverse proxy" и "проксирование запросов через nginx". Смысл одинаковый, слова разные. Для контроля добавил "рецепт борща" – модель должна понять, что это не про nginx.
Результат:
– all-MiniLM (23 MB): score 0.24.
Провал. RAG ничего не найдёт.
– nomic-embed-text (274 MB): score 0.45.
Но "рецепт борща" тоже 0.46. Модель не отличает nginx от кулинарии.
– mxbai-embed-large (670 MB): score 0.72.
Работает, но борщ всё ещё 0.50 – порог нужно настраивать аккуратно.
Почему так плохо? Русское слово "контейнер" для этих моделей – девять токенов: "к", "о", "н", "т", "е", "и", "н", "е", "р". Побуквенно. Русского текста в обучающих данных было мало, и модели его просто плохо понимают.
Ещё в посте: почему batch ломается на длинном русском тексте, зачем чистить текст перед embedding, и реальные параметры pipeline для 206,000+ векторов.
Полная версия с кодом и benchmark-скриптом
👉 devopsway.ru/posts/rag-02-embeddings/
#кейс #ai
Embedding-модель превращает текст в массив чисел. От выбора модели зависит, найдёт ваш RAG правильный фрагмент или вернёт мусор.
Взял три модели из Ollama и скормил им пару фраз на русском: "настройка reverse proxy" и "проксирование запросов через nginx". Смысл одинаковый, слова разные. Для контроля добавил "рецепт борща" – модель должна понять, что это не про nginx.
Результат:
– all-MiniLM (23 MB): score 0.24.
Провал. RAG ничего не найдёт.
– nomic-embed-text (274 MB): score 0.45.
Но "рецепт борща" тоже 0.46. Модель не отличает nginx от кулинарии.
– mxbai-embed-large (670 MB): score 0.72.
Работает, но борщ всё ещё 0.50 – порог нужно настраивать аккуратно.
Почему так плохо? Русское слово "контейнер" для этих моделей – девять токенов: "к", "о", "н", "т", "е", "и", "н", "е", "р". Побуквенно. Русского текста в обучающих данных было мало, и модели его просто плохо понимают.
Ещё в посте: почему batch ломается на длинном русском тексте, зачем чистить текст перед embedding, и реальные параметры pipeline для 206,000+ векторов.
Полная версия с кодом и benchmark-скриптом
👉 devopsway.ru/posts/rag-02-embeddings/
#кейс #ai
🔥3👍2
⚡️ DevOps Digest #15 | 18.05.2026
🔥 Главное за неделю:
1. Kubernetes v1.36: ExternalIPs в Service объявлен deprecated – Поле .spec.externalIPs признано небезопасным (CVE-2020-8554) и объявлено устаревшим. Если используете его в on-premise кластере вместо облачного балансировщика – пора переходить на MetalLB или kube-vip. В будущих версиях kube-proxy перестанет поддерживать ExternalIPs.
🔗 https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/
2. Terraform 1.15: переменные в source модулей и deprecation переменных – Теперь можно использовать переменные прямо в source и version модулей (через новый атрибут const = true). Плюс появился механизм пометки переменных как deprecated с кастомным сообщением – удобно при рефакторинге больших конфигураций.
🔗 https://www.hashicorp.com/blog/new-in-terraform-115-dynamic-sources-variable-deprecation-and-more
3. node-ipc снова скомпрометирован – но не через код, а через домен за $9 – Атакующие перехватили просроченный домен мейнтейнера, сбросили пароль npm-аккаунта и опубликовали вредоносные версии пакета. Payload крал AWS-ключи, SSH и .env, а эксфильтрация шла через DNS TXT-записи – SIEM такое почти не видит. Если у вас есть npm-зависимости в CI/CD – стоит прочитать.
🔗 https://habr.com/ru/articles/1035902/
4. Стоимость уборки за AI-кодом – то, о чём молчит нарратив про скорость – GitHub прогнозирует 14 млрд коммитов в 2026 году. Но AI генерирует код быстрее, чем команды успевают его ревьюить и поддерживать. Статья разбирает скрытые расходы: технический долг, раздувание кодовой базы, проблемы с безопасностью сгенерированного кода. Полезный взгляд для тех, кто внедряет AI-инструменты в пайплайн.
🔗 https://thenewstack.io/cleanup-cost-ai-code/
5. Как программа попадает в память: от execve до main – Пошаговый разбор того, что происходит в Linux после ./myprogram: как ядро находит файл, загружает ELF в память, вызывает динамический линковщик и доходит до main(). Всё с примерами через strace. Отличный материал для понимания того, что происходит под капотом.
🔗 https://habr.com/ru/articles/1036444/
6. Cloudflare: как оптимизация TCP в ядре Linux сломала QUIC – Инженеры обнаружили, что окно перегрузки CUBIC залипает на минимуме и не восстанавливается. Причина – Linux-ядро обнуляет таймер cwnd_epoch при переходе в idle, но QUIC-реализация quiche использует CUBIC иначе, чем TCP-стек ядра. Починили одной строкой. Поучительный разбор про то, как допущения одной подсистемы ломают другую.
🔗 https://blog.cloudflare.com/quic-death-spiral-fix/
🛠 Команда недели:
Найти все Service с externalIPs в кластере – после deprecation в K8s 1.36 стоит знать, где они у вас.
#дайджест #kubernetes #devops
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Kubernetes v1.36: ExternalIPs в Service объявлен deprecated – Поле .spec.externalIPs признано небезопасным (CVE-2020-8554) и объявлено устаревшим. Если используете его в on-premise кластере вместо облачного балансировщика – пора переходить на MetalLB или kube-vip. В будущих версиях kube-proxy перестанет поддерживать ExternalIPs.
🔗 https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/
2. Terraform 1.15: переменные в source модулей и deprecation переменных – Теперь можно использовать переменные прямо в source и version модулей (через новый атрибут const = true). Плюс появился механизм пометки переменных как deprecated с кастомным сообщением – удобно при рефакторинге больших конфигураций.
🔗 https://www.hashicorp.com/blog/new-in-terraform-115-dynamic-sources-variable-deprecation-and-more
3. node-ipc снова скомпрометирован – но не через код, а через домен за $9 – Атакующие перехватили просроченный домен мейнтейнера, сбросили пароль npm-аккаунта и опубликовали вредоносные версии пакета. Payload крал AWS-ключи, SSH и .env, а эксфильтрация шла через DNS TXT-записи – SIEM такое почти не видит. Если у вас есть npm-зависимости в CI/CD – стоит прочитать.
🔗 https://habr.com/ru/articles/1035902/
4. Стоимость уборки за AI-кодом – то, о чём молчит нарратив про скорость – GitHub прогнозирует 14 млрд коммитов в 2026 году. Но AI генерирует код быстрее, чем команды успевают его ревьюить и поддерживать. Статья разбирает скрытые расходы: технический долг, раздувание кодовой базы, проблемы с безопасностью сгенерированного кода. Полезный взгляд для тех, кто внедряет AI-инструменты в пайплайн.
🔗 https://thenewstack.io/cleanup-cost-ai-code/
5. Как программа попадает в память: от execve до main – Пошаговый разбор того, что происходит в Linux после ./myprogram: как ядро находит файл, загружает ELF в память, вызывает динамический линковщик и доходит до main(). Всё с примерами через strace. Отличный материал для понимания того, что происходит под капотом.
🔗 https://habr.com/ru/articles/1036444/
6. Cloudflare: как оптимизация TCP в ядре Linux сломала QUIC – Инженеры обнаружили, что окно перегрузки CUBIC залипает на минимуме и не восстанавливается. Причина – Linux-ядро обнуляет таймер cwnd_epoch при переходе в idle, но QUIC-реализация quiche использует CUBIC иначе, чем TCP-стек ядра. Починили одной строкой. Поучительный разбор про то, как допущения одной подсистемы ломают другую.
🔗 https://blog.cloudflare.com/quic-death-spiral-fix/
🛠 Команда недели:
kubectl get svc -A -o json | jq -r '.items[] | select(.spec.externalIPs != null) | "\(.metadata.namespace)/\(.metadata.name): \(.spec.externalIPs)"'
Найти все Service с externalIPs в кластере – после deprecation в K8s 1.36 стоит знать, где они у вас.
#дайджест #kubernetes #devops
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
Kubernetes
Kubernetes v1.36: Deprecation and removal of Service ExternalIPs
The .spec.externalIPs field for Service was an early attempt to provide cloud-load-balancer-like functionality for non-cloud clusters. Unfortunately, the API assumes that every user in the cluster is fully trusted, and in any situation where that is not the…
🔥5❤1
RAG Pipeline 3/N: Чанки
RAG-pipeline не скармливает файл модели целиком. Он отдаёт фрагменты – чанки по 800 символов. Если граница реза прошла посередине мысли, модель получит огрызок и ответит мусором.
Первая версия моего pipeline резала по 1500 символов. Ollama падала с HTTP 500 – binary search показал: worst-case русский markdown укладывает 512 токенов в 912 символов. 1500 – это ~840 токенов, на 60% больше лимита. Уменьшил до 800 – ошибки ушли.
Но размер – полдела. Фрагмент "…настройка Cad" без продолжения "dy reverse proxy" бесполезен.
У меня два уровня нарезки:
– Сначала по заголовкам H2/H3 в markdown. Каждая секция – логически завершённая мысль.
– Если секция больше 800 символов – дорезка с перекрытием (overlap) 150 символов. Контекст на стыке не теряется. 800/150 – соотношение, к которому пришёл после трёх итераций.
Ещё санитизация: Unicode-мусор, управляющие символы, строки длиннее 200 знаков без пробелов (base64, хеши) – всё это шумные векторы.
Фрагменты короче 20 символов отбрасываются.
Результат: 180+ файлов памяти → 3 010 фрагментов в Qdrant. Каждый фрагмент несёт метаданные: файл, секция, зона (hot/warm/cold), проект. Это потом позволяет фильтровать поиск, а не надеяться только на косинусную близость.
Полная версия с кодом и скриптом нарезки
👉 devopsway.ru/posts/rag-03-chunking/
Следующий – про поиск: почему одних векторов мало и зачем гибридный поиск (BM25 + dense).
#кейс #ai
RAG-pipeline не скармливает файл модели целиком. Он отдаёт фрагменты – чанки по 800 символов. Если граница реза прошла посередине мысли, модель получит огрызок и ответит мусором.
Первая версия моего pipeline резала по 1500 символов. Ollama падала с HTTP 500 – binary search показал: worst-case русский markdown укладывает 512 токенов в 912 символов. 1500 – это ~840 токенов, на 60% больше лимита. Уменьшил до 800 – ошибки ушли.
Но размер – полдела. Фрагмент "…настройка Cad" без продолжения "dy reverse proxy" бесполезен.
У меня два уровня нарезки:
– Сначала по заголовкам H2/H3 в markdown. Каждая секция – логически завершённая мысль.
– Если секция больше 800 символов – дорезка с перекрытием (overlap) 150 символов. Контекст на стыке не теряется. 800/150 – соотношение, к которому пришёл после трёх итераций.
Ещё санитизация: Unicode-мусор, управляющие символы, строки длиннее 200 знаков без пробелов (base64, хеши) – всё это шумные векторы.
Фрагменты короче 20 символов отбрасываются.
Результат: 180+ файлов памяти → 3 010 фрагментов в Qdrant. Каждый фрагмент несёт метаданные: файл, секция, зона (hot/warm/cold), проект. Это потом позволяет фильтровать поиск, а не надеяться только на косинусную близость.
Полная версия с кодом и скриптом нарезки
👉 devopsway.ru/posts/rag-03-chunking/
Следующий – про поиск: почему одних векторов мало и зачем гибридный поиск (BM25 + dense).
#кейс #ai
🔥4
Локальный AI в терминале: как собрать автономный стек и не зависеть от вендоров
В апреле Alibaba прикрыла бесплатный тир Qwen Code. Инструмент, на который завязали часть пайплайнов, протух за пару месяцев. Вывод банальный: любой внешний вендор – это точка отказа.
Пересобрал стек и статью по принципу полной автономности. CLI отдельно, инференс отдельно. Если завтра закроется очередной API-токен, мы просто меняем одну строку в конфиге.
Что внутри:
– 3 CLI (OpenCode, Aider, Qwen Code) – установлены, настроены, проверены
– MoE-модели: Qwen 3 30B-A3B выдаёт 20 t/s на CPU – быстрее, чем dense 8B
– Тест на DevOps-задачах: Dockerfile, systemd, Terraform, K8s – Gemma 4 26B оказалась лучше Qwen по качеству
– Грабли: /no_think сломан в Ollama 0.24, thinking mode жрёт токены, модели болтают вместо кода
– CPU vs GPU: реальные замеры на RTX 3090 и CPU с ограничением потоков
Полная версия с конфигами, Modelfile и таблицами
👉 devopsway.ru/posts/local-ai-devops-ollama-2026/
#гайд #ai #devops
В апреле Alibaba прикрыла бесплатный тир Qwen Code. Инструмент, на который завязали часть пайплайнов, протух за пару месяцев. Вывод банальный: любой внешний вендор – это точка отказа.
Пересобрал стек и статью по принципу полной автономности. CLI отдельно, инференс отдельно. Если завтра закроется очередной API-токен, мы просто меняем одну строку в конфиге.
Что внутри:
– 3 CLI (OpenCode, Aider, Qwen Code) – установлены, настроены, проверены
– MoE-модели: Qwen 3 30B-A3B выдаёт 20 t/s на CPU – быстрее, чем dense 8B
– Тест на DevOps-задачах: Dockerfile, systemd, Terraform, K8s – Gemma 4 26B оказалась лучше Qwen по качеству
– Грабли: /no_think сломан в Ollama 0.24, thinking mode жрёт токены, модели болтают вместо кода
– CPU vs GPU: реальные замеры на RTX 3090 и CPU с ограничением потоков
Полная версия с конфигами, Modelfile и таблицами
👉 devopsway.ru/posts/local-ai-devops-ollama-2026/
#гайд #ai #devops
🔥5❤2🙏1👻1
⚡️ DevOps Digest #16 | 25.05.2026
🔥 Главное за неделю:
1. Песочница для AI-агентов: почему "просто Docker" не спасает – Пошаговый гайд по изоляции AI-агентов, которые выполняют код: drop root, фильтрация syscalls, сетевые политики, отключение docker.sock. Актуально для всех, кто запускает автоматизацию с доступом к shell.
🔗 https://dev.to/alanwest/how-to-sandbox-ai-coding-agents-without-crippling-them-116c
2. docker-use – переключение между аккаунтами Docker Hub – Простая CLI-утилита: по директории конфигов на каждый аккаунт + shell-функция для переключения через
🔗 https://dev.to/chiragagg5k/managing-multiple-docker-hub-accounts-using-docker-use-b6p
3. Массовые обновления безопасности: nginx, OpenSSH, PostgreSQL, rsync, dnsmasq – На этой неделе вышли патчи для Debian, SUSE, Ubuntu, Fedora, AlmaLinux. Затронуты nginx, openssh, postgresql (14–18), rsync, dnsmasq, bind9, podman, runc. Проверьте свои серверы.
🔗 https://lwn.net/Articles/1073860/
4. Как ломаются сложные системы: 18 уроков для дежурного инженера – Разбор классической работы Ричарда Кука через призму SRE: катастрофа требует стечения нескольких отказов, система уже содержит баги, о которых вы не знаете, и постмортемы – не поиск виноватых, а способ учиться.
🔗 https://how.complexsystems.fail/
5. Кто мониторит AI-агентов в продакшене – CrewAI, AutoGen, LangGraph уже работают в production, но наблюдаемость этих систем хуже, чем у микросервисов 10 лет назад. Статья разбирает, что именно ломается: петли вызовов, рост latency, неконтролируемые расходы.
🔗 https://thenewstack.io/who-monitors-ai-agents/
6. CGE – краулер с визуализацией связей между поддоменами – Open-source инструмент для red team: собирает поддомены из SSL-сертификатов, краулит эндпоинты, парсит JS/HTML/формы, строит граф взаимодействий в реальном времени. Web UI + CLI.
🔗 https://github.com/a11mut3d/CGE
🛠 Команда недели:
Показывает последние 20 событий кластера в хронологическом порядке. Быстрый способ понять, что происходило, когда поды начали падать.
#дайджест #devops #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Песочница для AI-агентов: почему "просто Docker" не спасает – Пошаговый гайд по изоляции AI-агентов, которые выполняют код: drop root, фильтрация syscalls, сетевые политики, отключение docker.sock. Актуально для всех, кто запускает автоматизацию с доступом к shell.
🔗 https://dev.to/alanwest/how-to-sandbox-ai-coding-agents-without-crippling-them-116c
2. docker-use – переключение между аккаунтами Docker Hub – Простая CLI-утилита: по директории конфигов на каждый аккаунт + shell-функция для переключения через
DOCKER_CONFIG. Полезно, если работаете с несколькими реестрами.🔗 https://dev.to/chiragagg5k/managing-multiple-docker-hub-accounts-using-docker-use-b6p
3. Массовые обновления безопасности: nginx, OpenSSH, PostgreSQL, rsync, dnsmasq – На этой неделе вышли патчи для Debian, SUSE, Ubuntu, Fedora, AlmaLinux. Затронуты nginx, openssh, postgresql (14–18), rsync, dnsmasq, bind9, podman, runc. Проверьте свои серверы.
🔗 https://lwn.net/Articles/1073860/
4. Как ломаются сложные системы: 18 уроков для дежурного инженера – Разбор классической работы Ричарда Кука через призму SRE: катастрофа требует стечения нескольких отказов, система уже содержит баги, о которых вы не знаете, и постмортемы – не поиск виноватых, а способ учиться.
🔗 https://how.complexsystems.fail/
5. Кто мониторит AI-агентов в продакшене – CrewAI, AutoGen, LangGraph уже работают в production, но наблюдаемость этих систем хуже, чем у микросервисов 10 лет назад. Статья разбирает, что именно ломается: петли вызовов, рост latency, неконтролируемые расходы.
🔗 https://thenewstack.io/who-monitors-ai-agents/
6. CGE – краулер с визуализацией связей между поддоменами – Open-source инструмент для red team: собирает поддомены из SSL-сертификатов, краулит эндпоинты, парсит JS/HTML/формы, строит граф взаимодействий в реальном времени. Web UI + CLI.
🔗 https://github.com/a11mut3d/CGE
🛠 Команда недели:
kubectl get events --sort-by='.lastTimestamp' -A | tail -20
Показывает последние 20 событий кластера в хронологическом порядке. Быстрый способ понять, что происходило, когда поды начали падать.
#дайджест #devops #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
DEV Community
How to sandbox AI coding agents without crippling them
A practical guide to sandboxing AI agents with layered defenses: containers, seccomp, namespaces, and network controls — without breaking them.
🔥4❤1
RAG Pipeline 4/N: Гибридный поиск
Продолжаем серию про построение конвейера "общей памяти" между сессиями с LLM.
В предыдущих постах разобрали векторный поиск, эмбеддинги и нарезку на чанки. Сегодня – почему одних векторов мало.
Запрос "docker compose настройка". Векторный поиск возвращает чанки про оркестрацию, networking, даже Kubernetes. Семантические соседи. А конкретный
BM25 (поиск по ключевым словам) – обратная история. "docker compose" – вот три чанка, где это упоминается. Но "как поднять сервисы в фоне" он не свяжет с
Запускаю оба параллельно, результаты сливаю по рангам (Reciprocal Rank Fusion). Векторный ~50ms, BM25 ~5ms, слияние ~5ms. Итого ~80ms – копейки на фоне генерации ответа.
Два нюанса, которые стоили часов отладки.
– Первый: русская морфология. "Настройка", "настройки", "настроить" – без pymorphy BM25 на русском теряет треть релевантности.
– Второй: "docker", "kubectl", "git" встречаются в каждом втором чанке. Наивный BM25 посчитает их стоп-словами и выкинет. А для девопса это ключевые термины. Защищаю от фильтрации явным списком из 179 токенов.
Результат: точность top-5 выросла на треть по сравнению с чистым векторным. Особенно на запросах с конкретными командами.
Следующий – про переранжирование: 10 результатов есть, но порядок неправильный.
Полная версия с кодом и сравнением методов
👉 devopsway.ru/posts/rag-04-hybrid-search/
#кейс #ai
Продолжаем серию про построение конвейера "общей памяти" между сессиями с LLM.
В предыдущих постах разобрали векторный поиск, эмбеддинги и нарезку на чанки. Сегодня – почему одних векторов мало.
Запрос "docker compose настройка". Векторный поиск возвращает чанки про оркестрацию, networking, даже Kubernetes. Семантические соседи. А конкретный
docker compose up -d из моего конспекта – на пятой позиции. Для эмбеддинга "настройка" и "конфигурирование" – одно и то же, точное совпадение слова ему безразлично.BM25 (поиск по ключевым словам) – обратная история. "docker compose" – вот три чанка, где это упоминается. Но "как поднять сервисы в фоне" он не свяжет с
docker compose up -d никогда.Запускаю оба параллельно, результаты сливаю по рангам (Reciprocal Rank Fusion). Векторный ~50ms, BM25 ~5ms, слияние ~5ms. Итого ~80ms – копейки на фоне генерации ответа.
Два нюанса, которые стоили часов отладки.
– Первый: русская морфология. "Настройка", "настройки", "настроить" – без pymorphy BM25 на русском теряет треть релевантности.
– Второй: "docker", "kubectl", "git" встречаются в каждом втором чанке. Наивный BM25 посчитает их стоп-словами и выкинет. А для девопса это ключевые термины. Защищаю от фильтрации явным списком из 179 токенов.
Результат: точность top-5 выросла на треть по сравнению с чистым векторным. Особенно на запросах с конкретными командами.
Следующий – про переранжирование: 10 результатов есть, но порядок неправильный.
Полная версия с кодом и сравнением методов
👉 devopsway.ru/posts/rag-04-hybrid-search/
#кейс #ai
🔥3❤1
⚡️ DevOps Digest #17 | 01.06.2026
🔥 Главное за неделю:
1. Kubernetes: исправляют записи о незакрытых CVE — сканеры могут заалертить – 1 июня Kubernetes SRC обновит CVE-записи для трёх старых уязвимостей (CVE-2020-8561, CVE-2020-8562, CVE-2021-25740), которые ранее ошибочно указывали наличие фикса. Эти баги — архитектурные компромиссы, полного исправления нет. После обновления записей сканеры могут начать показывать новые алерты на ваших кластерах — не паникуйте, но проверьте, применимы ли mitigation из описания CVE.
🔗 https://kubernetes.io/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/
2. GitLab 19.0: SBOM-сканирование зависимостей стало GA – Новый анализатор строит полный граф зависимостей (включая транзитивные), сверяет с базой уязвимостей и показывает проблемы прямо в merge request. Если используете GitLab — включите и замените старый Gemnasium-сканер: он видит глубже и находит больше.
🔗 https://about.gitlab.com/blog/sbom-based-dependency-scanning/
3. Чеклист на 54 пункта для деплоя в прод – Инженер из промышленной автоматизации собрал проверки по 4 фазам: pre-deploy, execution, post-deploy, 24h stability. Ничего революционного, но как готовый шаблон для команды без формализованного процесса — отличная отправная точка. Особенно полезно джунам, которые деплоят впервые.
🔗 https://dev.to/fabrciowplima/the-54-point-production-deployment-checklist-that-saves-you-from-3am-rollbacks-22i4
4. Java vs C# в Kubernetes: практический гайд по оптимизации Docker-образов – Подробное сравнение двух стеков в контейнерной среде: размеры образов, время старта, настройка JVM/AOT, GC, лимиты памяти, пробы. Полезно тем, кто контейнеризирует Java/C#-приложения и хочет понять, где теряются ресурсы.
🔗 https://dev.to/syedahmershah/java-vs-c-optimizing-docker-for-kubernetes-1kkc
5. LeafWiki — self-hosted вики в одном Go-бинарнике – SQLite, Markdown-файлы на диске, Ctrl+V для вставки скриншотов, SSO через HTTP-заголовки (Authentik, Authelia), роли. Ноль внешних зависимостей. Если ищете лёгкую вики для внутренней документации в закрытом контуре — стоит попробовать.
🔗 https://github.com/perber/leafwiki
🛠 Команда недели:
Покажет последние 20 событий о failed проверках (liveness/readiness) по всем namespace. Удобно для быстрой диагностики, когда поды рестартятся без видимой причины.
#дайджест #kubernetes #security
🔥 Главное за неделю:
1. Kubernetes: исправляют записи о незакрытых CVE — сканеры могут заалертить – 1 июня Kubernetes SRC обновит CVE-записи для трёх старых уязвимостей (CVE-2020-8561, CVE-2020-8562, CVE-2021-25740), которые ранее ошибочно указывали наличие фикса. Эти баги — архитектурные компромиссы, полного исправления нет. После обновления записей сканеры могут начать показывать новые алерты на ваших кластерах — не паникуйте, но проверьте, применимы ли mitigation из описания CVE.
🔗 https://kubernetes.io/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/
2. GitLab 19.0: SBOM-сканирование зависимостей стало GA – Новый анализатор строит полный граф зависимостей (включая транзитивные), сверяет с базой уязвимостей и показывает проблемы прямо в merge request. Если используете GitLab — включите и замените старый Gemnasium-сканер: он видит глубже и находит больше.
🔗 https://about.gitlab.com/blog/sbom-based-dependency-scanning/
3. Чеклист на 54 пункта для деплоя в прод – Инженер из промышленной автоматизации собрал проверки по 4 фазам: pre-deploy, execution, post-deploy, 24h stability. Ничего революционного, но как готовый шаблон для команды без формализованного процесса — отличная отправная точка. Особенно полезно джунам, которые деплоят впервые.
🔗 https://dev.to/fabrciowplima/the-54-point-production-deployment-checklist-that-saves-you-from-3am-rollbacks-22i4
4. Java vs C# в Kubernetes: практический гайд по оптимизации Docker-образов – Подробное сравнение двух стеков в контейнерной среде: размеры образов, время старта, настройка JVM/AOT, GC, лимиты памяти, пробы. Полезно тем, кто контейнеризирует Java/C#-приложения и хочет понять, где теряются ресурсы.
🔗 https://dev.to/syedahmershah/java-vs-c-optimizing-docker-for-kubernetes-1kkc
5. LeafWiki — self-hosted вики в одном Go-бинарнике – SQLite, Markdown-файлы на диске, Ctrl+V для вставки скриншотов, SSO через HTTP-заголовки (Authentik, Authelia), роли. Ноль внешних зависимостей. Если ищете лёгкую вики для внутренней документации в закрытом контуре — стоит попробовать.
🔗 https://github.com/perber/leafwiki
🛠 Команда недели:
kubectl get events --field-selector reason=Unhealthy --sort-by='.lastTimestamp' -A | tail -20
Покажет последние 20 событий о failed проверках (liveness/readiness) по всем namespace. Удобно для быстрой диагностики, когда поды рестартятся без видимой причины.
#дайджест #kubernetes #security
Kubernetes
Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs
The Kubernetes project relies on transparency to empower cluster administrators and security researchers. One important way we do that is by publishing CVE records into the Common Vulnerabilities and Exposures database. As part of our ongoing effort to mature…
🔥3❤2
RAG Pipeline 5/N: Почему ваш гибридный поиск – это просто первичный отсев, а не точная сортировка
Гибридный поиск (пост 4/N) находит нужный кусок кода или доки в условный top-15, но порядок внутри этого топа напоминает лотерею. Алгоритм RRF пытается скрестить ужа с ежом: "Так, BM25 поставил этот чанк первым, векторный поиск – третьим, складываем обратные ранги".
Проблема в том, что ни один из этих алгоритмов не читал документ вместе с вашим запросом. Они просто сравнивают сухие индексы и вектора. А для LLM критически важен именно top-1. Что туда попало – из того она и соберет ответ. Если на первом месте оказался мусор, замаскированный под релевантный результат, на выходе получите классический garbage in, garbage out. Чтобы решить это, в стек пришлось тащить Cross-encoder.
Как это работает на пальцах
Cross-encoder не занимается сравнением готовых векторов. Он берет запрос, приклеивает к нему текст найденного чанка и читает их вместе, как человек. Модель буквально вчитывается в контекст пары "вопрос-ответ".
Минус очевиден – это дорого по ресурсам. Гонять такую модель по всему корпусу в 360K чанков – безумие. Поэтому мы используем каскадную схему, знакомую любому инженеру по классической архитектуре систем:
– Bi-encoder + BM25 – это наш L1/L2 кэш или Bloom-фильтр перед диском. Его задача – быстро отсечь 99% явного мусора и выплюнуть пачку кандидатов.
– Cross-encoder – это финальный тяжелый запрос к диску. Он ювелирно разбирает оставшийся 1% (наши 15 кандидатов) и расставляет их по реальной релевантности.
Что показали тесты на NORA
Загнал в систему пачку из 30 реальных тестовых запросов по репозиторию. Результат: у двух третей запросов после реранкинга top-1 полностью изменился. Гибридный поиск честно находил нужный кусок, но закапывал его на 5-7 место.
Живой пример:
Запрос: "XSS vulnerability in NORA UI".
– До реранкинга: На первом месте болтался какой-то случайный JSON, который dense search случайно ранжировал выше нужного чанка.
– После реранкинга: Система вытащила конкретный чанк с фиксом пайплайна под issue #521. Rerank score 0.99 – модель уверена.
Цена вопроса и суровая реальность
За точность приходится платить таймингами, и чудес тут нет.
– Время поиска без реранкера: 91ms
– Время поиска с реранкером: 3.3 секунды (на CPU)
Для CLI-утилиты или MCP-тула, который ты запустил в фоне и ждешь развернутый аудит, это приемлемо. Сидишь, пьешь кофе, автоматизация работает. Но если вы попытаетесь прикрутить такую схему на автокомплит в IDE – вы просто убьете UX, разработчики вас проклянут. Для фаст-трека нужен либо мощный GPU-инференс, либо более легкие дистиллированные модели.
В следующем посте разберем классические грабли: почему пайплайн, который выдавал 98% accuracy на моих локальных данных, мгновенно развалился, стоило закинуть в него чужой репозиторий.
Полная версия с кодом интеграции и замерами производительности каскада:
👉devopsway.ru/posts/rag-05-reranking/
#кейс #ai
Гибридный поиск (пост 4/N) находит нужный кусок кода или доки в условный top-15, но порядок внутри этого топа напоминает лотерею. Алгоритм RRF пытается скрестить ужа с ежом: "Так, BM25 поставил этот чанк первым, векторный поиск – третьим, складываем обратные ранги".
Проблема в том, что ни один из этих алгоритмов не читал документ вместе с вашим запросом. Они просто сравнивают сухие индексы и вектора. А для LLM критически важен именно top-1. Что туда попало – из того она и соберет ответ. Если на первом месте оказался мусор, замаскированный под релевантный результат, на выходе получите классический garbage in, garbage out. Чтобы решить это, в стек пришлось тащить Cross-encoder.
Как это работает на пальцах
Cross-encoder не занимается сравнением готовых векторов. Он берет запрос, приклеивает к нему текст найденного чанка и читает их вместе, как человек. Модель буквально вчитывается в контекст пары "вопрос-ответ".
Минус очевиден – это дорого по ресурсам. Гонять такую модель по всему корпусу в 360K чанков – безумие. Поэтому мы используем каскадную схему, знакомую любому инженеру по классической архитектуре систем:
– Bi-encoder + BM25 – это наш L1/L2 кэш или Bloom-фильтр перед диском. Его задача – быстро отсечь 99% явного мусора и выплюнуть пачку кандидатов.
– Cross-encoder – это финальный тяжелый запрос к диску. Он ювелирно разбирает оставшийся 1% (наши 15 кандидатов) и расставляет их по реальной релевантности.
Что показали тесты на NORA
Загнал в систему пачку из 30 реальных тестовых запросов по репозиторию. Результат: у двух третей запросов после реранкинга top-1 полностью изменился. Гибридный поиск честно находил нужный кусок, но закапывал его на 5-7 место.
Живой пример:
Запрос: "XSS vulnerability in NORA UI".
– До реранкинга: На первом месте болтался какой-то случайный JSON, который dense search случайно ранжировал выше нужного чанка.
– После реранкинга: Система вытащила конкретный чанк с фиксом пайплайна под issue #521. Rerank score 0.99 – модель уверена.
Цена вопроса и суровая реальность
За точность приходится платить таймингами, и чудес тут нет.
– Время поиска без реранкера: 91ms
– Время поиска с реранкером: 3.3 секунды (на CPU)
Для CLI-утилиты или MCP-тула, который ты запустил в фоне и ждешь развернутый аудит, это приемлемо. Сидишь, пьешь кофе, автоматизация работает. Но если вы попытаетесь прикрутить такую схему на автокомплит в IDE – вы просто убьете UX, разработчики вас проклянут. Для фаст-трека нужен либо мощный GPU-инференс, либо более легкие дистиллированные модели.
В следующем посте разберем классические грабли: почему пайплайн, который выдавал 98% accuracy на моих локальных данных, мгновенно развалился, стоило закинуть в него чужой репозиторий.
Полная версия с кодом интеграции и замерами производительности каскада:
👉devopsway.ru/posts/rag-05-reranking/
#кейс #ai
🔥3❤2