DevOps *

Я начал с requests.get() к Hysteria2 API, а через несколько месяцев получил рабочий VPN-сервис: FastAPI, React, PostgreSQL, JWT, Docker Compose, несколько VPS-нод, сбор трафика и автодеплой. До этого я не работал разработчиком и не понимал половину слов из этого списка. В статье — путь от первых curl-запросов до архитектурных компромиссов в продакшне, а ещё выводы о работе с ИИ: где он ускоряет разработку, где уверенно ошибается и почему без собственного понимания проект быстро превращается в неподконтрольный клубок кода.

Вторник, 14:00. Кластер Kubernetes перестал отвечать, команда в панике, а вам нужно за 15 минут найти первопричину.

В этой статье пройдём диагностику реального отказа вместе с SRE: увидим логи, манифест etcd и ошибки, которые совершают даже опытные инженеры. Попробуйте сначала решить задачу сами, а потом сверьтесь с пошаговым разбором и проверьте, насколько вы готовы к такому инциденту.

torque

Большинство советов по сборке Docker заканчиваются на порядке слоёв: сначала копируйте манифесты зависимостей, запускайте менеджер пакетов, затем копируйте остальной исходный код. Это полезно, но недостаточно для инструмента релиза. Инструмент релиза должен отвечать на более сложные вопросы. Какой процесс имел право читать дерево исходного кода? Какие учётные данные достигли сборщика? Был ли сокет Docker предоставлен недоверенной команде? Кэш пришёл из предыдущей ветки, общего бакета или пустого локального сборщика? Может ли агент объяснить, почему сборка была быстрой, без парсинга логов BuildKit? На все эти вопросы поможет ответить torque.

DevOps и CI/CD эволюционируют в сторону агентных систем: вместо ручных скриптов и разрозненных инструментов — декларативные стеки, верифицируемые планы и автономные агенты, которые выполняют, проверяют и фиксируют доставку. Статья показывает, что Torque — один из возможных путей к такому будущему, где инфраструктура становится предсказуемой, аудируемой и готовой к работе с ИИ-агентами.

Разбираем, как в отделе документации построили LLM-агента для автоматизированного перевода Markdown-документации. Архитектура, пайплайн, валидация, работа с Ollama, OpenWebUI и Qwen, плюсы и ограничения подхода. 

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

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

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.

Я делаю Valpero — uptime-мониторинг с проверками из 10 регионов мира. Когда я только собирал probe-сеть, я был уверен, что 10 географических точек это автоматически и 10 точек отказа. Открыл недавно AS-картину своего же парка — и обнаружил, что из 10 узлов у меня реально 4 разных автономных системы. 7 из 10 probe сидят на одном и том же AS209847.

Ниже расскажу о том, как сейчас выглядит сеть, какие провайдеры реально стоят, как я измерял AS-разнесённость, и что я планирую с этим делать.

В конце таблица с IP-адресами всех узлов и их AS — повторить расклад на своём проекте можно за вечер.

Полчаса в день у меня уходило на ручной обход шести нод 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.