DevOps *

Исторически сложилось, что автоматизация ТОиР на заводах — это долго и дорого.

В статье разберем, как сократить этот цикл: отказаться от закупки серверов, перенести систему в облако и запустить пилот на реальном участке за считаные недели с первыми результатами уже через несколько месяцев.

CI/CD-пайплайн, который хранит секреты, — это риск. В безопасной модели он получает доступ к чувствительным данным только на время выполнения задачи и строго в рамках своих прав.

Разбираем, почему GitLab CI/CD Variables — это не хранилище секретов, какие подводные камни ждут при самодельной интеграции GitLab CE с HashiCorp Vault и как связка Deckhouse Code и Stronghold закрывает эти проблемы без Bash-портянок в before_script.

Я хотел запускать Claude Code через подписку ChatGPT/Codex. Без OpenAI API key и без потери привычных вещей: инструментов, скриншотов, /compact, длинных сессий и нормальных ошибок.

На бумаге это выглядит как простой локальный прокси. На практике пришлось переводить не только JSON, но и поведение Anthropic API: потоковые события, вызовы инструментов, лимиты контекста, файлы, картинки и типы ошибок.

Так появился мой open source fork Claudex. Репозиторий: github.com/pilc80/claudex. Лицензия — MIT.

Полчаса в день у меня уходило на ручной обход шести нод Proxmox через веб-интерфейс — он показывает по одной ноде за раз. И часть рутины всё равно проскакивала: задание PBS остановилось — никто не заметил, ZFS scrub отключили на maintenance и забыли включить, на ноде накопились pending kernel updates, и о них узнаёшь, когда уже надо ребутить.

На Proxmox-кластере, который я администрирую, после миграции с проприетарного гипервизора этот операционный долг копился особенно быстро: отключённые таймеры scrub, остановленные после рестарта PBS задания резервного копирования, дрейф конфигурации между нодами после мажорного апгрейда.

Стандартный путь — полноценный observability-стэк: Zabbix или Prometheus + Alertmanager + Grafana. Это правильный путь, но он плохо подходит к задаче «быстро получить единый экран по Proxmox-кластеру». В этой статье — про другой вариант: лёгкий read-only слой над Proxmox/PBS, который разворачивается за несколько часов и закрывает первый уровень видимости. Инструмент называется Pulse — где он работает, где нет, и что выяснилось в первый месяц эксплуатации.

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

В первой части мы разобрались с постановкой задачи и ТЗ, затем выбрали себе фаворита из локальных LLM, теперь же займемся скучным занятием- проектированием. В этой статье рассмотрим составление HLD и почему это должен делать человек, а что уже можно отдать нейросети в помощь.

В процессе написания материал разросся до неимоверных размеров, поэтому пришлось поделить его аж на четыре части. Впереди осталась самая интересная заключительная часть с тем, что получилось на выходе. Ее планирую подготовить за 2-3 недели, т.к. это просто хобби.

Часть 1: Вводная и формирование ТЗ
Часть 2: Выбор локальной LLM
Часть 3: Формирование HLD и немного LLD -> вы здесь
Часть 4: Что из этого вышло

Привет, Хабр! Меня зовут Юрий Соловьёв, я ведущий инженер в команде экосистемы Tarantool. С опытом я пришел к тому, что конфигурация должна иметь строгую спецификацию, так же как и HTTP API. В этой статье я предлагаю альтернативный подход на базе protobuf и постараюсь показать, что это не избыточная сложность, а необходимый уровень инженерной гигиены — особенно для систем, рассчитанных на долгую и стабильную жизнь. Это в какой-то мере технорассказ, которым я хочу поделиться — и именно в такой форме.

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

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

Современные инструменты мониторинга (Prometheus, Grafana, профилировщики) обеспечивают хорошую видимость состояния приложения, но имеют ограничения при анализе низкоуровневых проблем. Технология eBPF (Extended Berkeley Packet Filter) позволяет преодолеть этот барьер, предоставляя безопасный доступ к событиям ядра Linux. 

Статья — это практическое введение в eBPF: попробуем готовые команды для наблюдаемости, сети и безопасности, разберём, как программа попадает в ядро и взаимодействует с user-space через maps и helpers, почему верификатор отклоняет «опасный» код и чем отличаются BCC, libbpf и bpftrace. В конце — короткий обзор того, как eBPF используют Cilium, Falco и Pixie.

Материал будет полезен программистам, DevOps-инженерам, SRE-специалистам и всем, кто интересуется Linux.

Часть I: Первопричина - атака Mini Shai-Hulud на экосистему TanStack

Цепочка поставок как вектор атаки

11 мая 2026 года, в промежутке с 19:20 до 19:26 UTC, произошло одно из наиболее технически изощрённых событий в истории атак на цепочку поставок npm. Группировка TeamPCP опубликовала 84 вредоносные версии пакетов в рамках 42 пакетов из пространства имён @tanstack/* - и всё это за шесть минут.

Кампания получила название Mini Shai-Hulud - отсылка к гигантским песчаным червям из вселенной «Дюны» Фрэнка Герберта. Это не первая волна активности TeamPCP: до этого они скомпрометировали сканер Trivy от Aqua Security в марте 2026-го и npm-пакет Bitwarden CLI в апреле 2026-го. Каждая следующая волна технически сложнее предыдущей.

Как работала атака: три уязвимости в одной цепочке

Атака объединила три уязвимости, каждая из которых по отдельности была бы недостаточна. Злоумышленник создал форк репозитория TanStack/router, открыл pull request, который запустил workflow с триггером pull_request_target, и отравил кэш GitHub Actions через границу доверия fork↔base. Когда легитимный workflow сработал, отравленный кэш был восстановлен, а вредоносный код извлёк OIDC-токен прямо из памяти процесса runner'а.

Ключевой момент: злоумышленники не крали статические npm-токены. Вместо этого они извлекали runtime OIDC-токены напрямую из памяти процесса runner'а, что позволило им аутентифицироваться легитимным образом через trusted publisher bindings и публиковать скомпрометированные обновления в npm-реестр.

Масштаб заражения

Когда прод падает, первый управленческий рефлекс — найти человека, после которого всё сломалось. Проблема в том, что такой разбор почти ничего не говорит о реальной надёжности системы: инженеры начинают молчать о слабых местах, постмортемы превращаются в формальность, а одни и те же сбои возвращаются под новыми именами.

В статье разбираемся, почему культура поиска виновных делает инфраструктуру хрупче, как работает blameless‑подход, зачем командам error budget и какие управленческие механизмы помогают превращать инциденты в системные улучшения.

25 апреля 2026, пятница вечером. Jer Crane, основатель PocketOS, смотрит, как AI-агент Cursor удаляет его production-базу. Со всеми бэкапами. За 9 секунд.

Потом Jer спрашивает у агента — почему? И получает дословное признание: «I guessed instead of verifying. I violated every principle I was given».

Модель помнит правила. Цитирует их. И всё равно нарушает.

Это разбор трёх таких случаев — и трёх защит, которые я внедрил у себя после.

Локально docker-compose.yml обычно выглядит «рабочим» ровно до момента, пока сервис не уезжает на сервер. Потом внезапно заканчивается память, контейнеры не поднимаются после падения, логи разрастаются на десятки гигабайт, а Docker продолжает считать зависшее приложение живым.

В статье — пять настроек Compose, про которые почти всегда вспоминают уже после первого инцидента в проде: лимиты ресурсов, restart policy, healthcheck, ротация логов и работа с volumes.

В прошлой статье было показано, что обычный MacBook Pro M2 16GB может с оговорками решать инфраструктурные проблемы используя локальную LLM. В этой статье будут показаны результаты решения более сложных инфраструктурных задач на более тяжеловесных моделях.

Мой личный выбор - Qwen3.6-35-A3B для проблем, которые сформулированы общими словами, Gemma4-26B-A4B - для чётко описанных проблем. Далее обо всём этом подробнее.

Настройка CI/CD часто кажется новичкам чем-то сложным и доступным только DevOps-инженерам. На самом деле автоматизировать рутину Python-проекта можно всего за полчаса. В этой статье мы по шагам разберем, как с нуля настроить GitHub Actions для простого FastAPI-приложения: от автоматического запуска тестов и быстрого линтера Ruff до сборки Docker-образа и публикации его в Docker Hub.

GitHub Actions давно стал одной из самых опасных точек в supply chain. Ошибка в workflow может открыть доступ к секретам, токенам и инфраструктуре — именно так развивались атаки на tj-actions, Ultralytics и Trivy.

В статье разберем, как работают уязвимости вокруг pull_request_target, expression injection и сторонних actions, и почему «просто CI» сегодня требует полноценной threat model.

История о том, как сделать видимыми ошибки yt-dlp, которые молча умирали в логах воркера. Bridge на 200 строк, классификатор content vs infra, борьба с alert-fatigue.

Если вы разрабатываете на Битрикс24 и поддерживаете несколько окружений — тест, стейдж, прод — вы знаете эту боль. Настроил воронку, добавил пользовательские поля, написал робота с десятком условий, всё это поправил в карточке, назначил права. А потом нужно повторить то же самое на проде. Руками. Забыв половину.

Конфигурация CRM — это не код. Она живёт в базе данных, не попадает в git, и нет адекватного механизма переноса между окружениями. При этом объём этой конфигурации на реальных проектах значительный: десятки смарт-процессов, сотни пользовательских полей, сложные роботы с условиями, матрицы прав доступа, кастомные виды карточек. Всё это нужно как-то синхронизировать.

В Битрикс24 есть разрозненные инструменты для переноса отдельных частей настроек — штатный экспорт некоторых сущностей через интерфейс, партнёрские модули, закрывающие часть задач. Но каждый работает по-своему, покрывает свой кусок, и ни один не даёт того, что нужно на реальном проекте: полного покрытия CRM-конфигурации в одном инструменте, версионируемого вместе с кодом.

Мы прошли этот путь и в итоге написали набор Version Builder'ов для модуля sprint.migration, покрывающих основные сущности CRM Битрикс24. В этой статье — о самой задаче, подходе и подводных камнях.

Пишите в личку по вопросам.

Где-то с 2021 года программистам обещают, что: ИИ оставит их без работы, 30% мест исчезнут, дипломы обесценятся и вообще все станут бесполезными. В декабре 2025 это уже стало походить на правду, теперь, какой-нибудь Claude, действительно, выдает рыночный результат. А если сравнить стоимость генерации за ноль рублей с любой оплатой труда, то тут победить ИИ - крайне сложно.

Что касается профессий уровня аналитиков, то джуны не нужны, по моим ощущениям, с 2023 года, а на текущий момент вообще аналитики не особо нужны. Тут уже, к сожалению, так как в моей профессии присутствует слово аналитик.

Про замену управленческих кадров и уровня С, пошли прогнозы на конец 2026 года. Это уже касается лично меня и моей текущей работы. Но начиная с того самого 2021 года, я сменил 3 компании, пережил два кризиса в найме и как итог два ребрендинга собственной карьеры.

Сразу спойлер: без работы я не остался, но пришлось перестать "играть в шахматы" и переключиться на режим игры в настольный теннис.
В шахматах побеждает тот, кто видит стратегию на 10 ходов, а в теннисе - у кого лучше реакция и способность адаптироваться под противника.

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

Когда продакшен падает в три часа ночи, строка ERROR Something went wrong не помогает никому. В статье разбираем, почему привычные текстовые логи быстро превращаются в шум при реальной нагрузке, как перейти на structured logging, зачем каждому запросу нужен request_id и как настроить нормальные JSON‑логи в Python и Go без лишней инфраструктуры.

Собрал MCP-сервер для Windows: 42 инструмента в 8 модулях

Тут собраны Services, Event Viewer, Task Scheduler, Processes, Network, Diagnostics, Observability, Safety. Одна команда npx windows-admin-mcp, и Claude Desktop / Cursor / Claude Code получают полный доступ к администрированию Windows. TypeScript, MIT, npm. Внутри: диагностика служб за один вызов, анализ трендов ошибок, отслеживание изменений в системе, защита от случайных bulk-операций.

Пользуюсь сам каждый день. Буду рад фидбеку: что добавить, что лишнее, где можно лучше.