DevOps *

Привет Хабр! Это небольшой рассказ о моей домашней лаборатории на которой я обучаюсь различным решениям необходимых DevOps‑инженеру. Для начала пробежимся мини‑обзором оборудования, а после — расскажу о том, над чем еще стоит поработать.

Если администрировать Linux-сервера достаточно долго, рано или поздно сталкиваешься с сетевой фильтрацией. Где-то нужно закрыть лишние порты, где-то ограничить доступ между сегментами сети, а где-то настроить NAT.

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

В этой статье разберёмся, как появился nftables, чем он отличается от привычного iptables, как устроена его архитектура и как на практике использовать его для настройки firewall на Linux-сервере.

Документация к инфраструктуре устаревает быстрее, чем коммиты попадают в main ветку, но мы решили эту «боль», отдав её на откуп ИИ. В статье разбираем, как связка из нескольких LLM-агентов автоматически парсит Ansible-плейбуки, генерирует пользовательские инструкции, проверяет и переводит их. Всё это крутится на четырёх Tesla V100 с ручной балансировкой через Ollama и OpenWebUI — без свежего железа, но с десятками сэкономленных часов и гарантией актуальности текстов.

Когда MCP-серверов стало шесть, а коллег — десять, фраза «просто запусти npx локально» перестала работать. Не у всех есть желания ставить Node.js, у менеджеров нет Docker, а локальный claude_desktop_config.json начинает напоминать хранилище секретов от всех систем.

Я прошёл путь от remote MCP → локальный запуск → Docker → Kubernetes с единым Helm-чартом и JWT-аутентификацией через Envoy. Расскажу, на что напоролся, что получилось, и что еще предстоит решить.

Как найти причину латенси в пайплайне обработки HTTP запроса за 5 минут: разбираем шаг за шагом

Я достаточно ленивый и рациональный человек. В конце прошлого года у CloudFlare и его клиентов были непростые дни и утро Infra инженеров начиналось не с кофе. Плюс, те, кто много работает с CF знают про 503 и 520 ошибки и, если вы не на Enterprise тарифе, они также могу доставить неприятности. Хочу поделиться подходом и инструментом, которые помогли решить эти проблема и рационализировать/автоматизировать их решение в последствии.

Алерт в три часа ночи: время ответа выросло с 150 ms до 1.2 секунды. Или хуже — пользователи получают 502/503/504. Дежурный инженер открывает дашборд и видит красный график. Что-то тормозит. Но что именно?

Это CDN? Ingress? Приложение? База? Сеть между чем-то из вышеперечисленного? Каждый вариант ведёт к совершенно разному исправлению: перезапуск пода не поможет, если проблема в маршрутизации CDN, а звонок в поддержку хостера бесполезен, если у вас медленный SQL-запрос. Гадать дорого — особенно в три часа ночи.

В этой статье я покажу системный подход к поиску узкого места. Шаг за шагом, с минимумом телодвижений, используя данные, которые у вас скорее всего уже есть (или которые легко начать собирать). Акцент будет на CDN, Hosting Provider, Ingress.

Путь запроса

Прежде чем искать проблему, давайте зафиксируем, через какие этапы проходит типичный HTTP-запрос. Это простая архитектура, характерная для небольшой команды — но знакомая и наглядная(межсерверное взаимодействие в Netflix в качестве примера не будем использовать):

User → CDN → SLB (Nginx) → App(POD) → Connection Pooler → RDBMS

Шесть слоёв. Каждый может вносить свою задержку, свои ошибки — и каждый дает свои сигналы для диагностики.

Ключевое наблюдение: SLB (балансировщик, Nginx, HAProxy, ALB) сидит в центре и является вашей точкой отсчёта. Его логи подскажут, куда смотреть — налево (сеть, CDN) или направо (приложение, база).

Шаг 1. Точка опоры: логи балансировщика

Это лучший стартовый шаг — особенно если у вас еще нет развитого observability-стека и внешнего мониторинга. Достаточно Nginx access log.

Два ключевых значения:

Переменная Nginx Что измеряет $request_time Полное время обработки запроса — от первого байта клиента до последнего байта ответа $upstream_response_time Время ожидания ответа от upstream (вашего приложения)

Если вы ещё не логируете эти значения, добавьте их в log_format:

log_format timing '$remote_addr - $request_uri ' 'status=$status ' 'rt=$request_time ' 'uct=$upstream_connect_time ' 'urt=$upstream_response_time'; access_log /var/log/nginx/access.log timing;

Теперь у ва

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

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

Если ты тоже смотришь на Dart как на backend-альтернативу для Node.js, лучше пройти этот путь на чужих ошибках. Полные результаты benchmark'а — Go, Node.js, Dart, Bun, Deno, .NET — с методологией, конфигурацией и сырыми цифрами лежат на GitHub. Под катом — сама история. Не технический отчёт, а инженерская драма: как 2 недели ушли на перенос архитектуры, почему всё выглядело идеально на бумаге, и как гипотеза с "экономией памяти" разбилась о реалии raw benchmark. И ещё — почему AI-агент сделал всё правильно, и именно это оказалось проблемой.

Мы пытались отправлять уведомления о деплое из GitLab CI в MAX Messenger и долго шли по ложному следу, потому что проблема выглядела как сетевая. Но MAX API честно подсказывал обратное: proto.payload означал, что запрос доходит, а ломается именно body. В итоге решение оказалось не в DNS, а в минимальном JSON payload, очистке переменных окружения и отказе от хрупких shell-конструкций внутри CI job.

Нужен был реестр артефактов. Показать студентам цепочку поставки софта: сборка, тесты, push в реестр, деплой. Стандартная задача, казалось бы. "Вошли и вышли, приключение на 20 минут."

Растянулось на несколько месяцев.

В итоге написал свой реестр. Один бинарник. 7 форматов. 12 МБ RAM. Без базы данных.

AI-агент для управления VPS через Telegram

В прошлой статье я показал идею: AI-агент на VPS, который позволяет управлять сервером через Telegram и практически забыть про SSH.

Главный вопрос в комментариях был один: «Как это повторить у себя?»

В этой статье — полный разбор и готовый open-source комплект, который можно развернуть за ~10 минут:

docker-compose конфигурация

набор bash-скриптов для управления сервером

конфиги агента

deploy-скрипт

Разбираем архитектуру, инструменты и принципы работы, чтобы это был не «чёрный ящик», а понятная система, которую можно адаптировать под себя.

Ваши логи забиты попытками входа в .env, .git и wp-login.php? Пока бот стучится в Nginx, ваш сервер уже тратит драгоценные ресурсы. Я решил перенести фильтрацию в ядро Linux и делюсь рабочим кейсом эшелонированной обороны на базе ipset и CrowdSec.

Привет! Я Алиса, DevOps-инженер в KTS.

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

В общем, делюсь практическим опытом построения масштабируемой инфраструктуры с автоскейлингом. Если тема вам актуальна — приглашаю к прочтению.

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

Разбираю как выглядит нормальный QA-пайплайн в GitHub Actions: от линтинга до E2E тестов на Playwright. С рабочими конфигами, кэшированием и уведомлениями о падениях.

Запущенный на сервере OpenClaw решает большинство задач, которые пользователи ставят перед агентами. Для личного использования, параллельных запусков и несложной автоматизации его возможностей хватит с запасом. Одного VPS перестает хватать, когда приходят они: пиковые нагрузки.

В продакшене пиковые нагрузки у OpenClaw появляются раньше, чем можно ожидать. И когда это случается, варианта остается два: подбросить в печь больше вычислительных мощностей или пересмотреть архитектуру. Если второй вариант вам ближе, то эта статья для вас. Сегодня мы разберем контейнеризацию в Docker, отказоустойчивый деплой через Kubernetes, а также управление stateful-хранилищем, без которого стабильный запуск нескольких инстансов невозможен.

Как правило, разработчики, да и тестировщики не всегда могут заранее предусмотреть, какие именно некорректные входные данные придут в их веб-приложение. Привычные методы тестирования — ручные, интеграционные и даже unit-тесты — хорошо справляются с ожидаемыми сценариями. А вот для проверки непредсказуемых нужны другие подходы.

Привет, Хабр! Меня зовут Алексей Ломай, я младший системный инженер отдела DevOps в IBS. В этой статье расскажу о фаззинге как о мощном инструменте тестирования безопасности веб-приложений. Поговорим об истории и развитии подхода, о доступных инструментах и двух вариантах реализации в CI/CD.

Я посадил AI-агента на свой VPS и перестал открывать SSH. На сервере крутится дюжина Docker-контейнеров — клиентские проекты, SaaS, мониторинг, базы. Раньше любая мелочь требовала SSH: глянуть логи, рестартнуть контейнер, проверить место на диске.

Теперь я пишу в Telegram «память за 90%, разберись» — и через минуту получаю ответ: что случилось, что починил, сколько памяти сейчас.

В статье — реальные сценарии: SQL-запросы к PostgreSQL из Telegram, автодиагностика упавших сайтов, правка конфигов, мониторинг с авторестартом и управление задачами в YouTrack. Всё через кастомные shell-скрипты и AI-агент OpenClaw.

Три года назад CI/CD можно было считать дополнительным плюсом в резюме. Сегодня это уже не «приятный бонус», а один из признаков того, что специалист работает в зрелой инженерной среде и может претендовать на более дорогие задачи.

По данным Большого опроса сообщества Инфостарт за 2022, 2023 и 2025 годы, владение практиками автоматизированной сборки, тестирования и деплоя все заметнее связано с ростом дохода. Если упростить вывод до одной фразы, он будет звучать так: рынок начал платить не только за код, но и за способность поставлять изменения быстро, предсказуемо и без ручного хаоса.

Привет, Хабр! На связи — любопытный DevOps Владимир Лила, и это вторая часть материала о девконтейнерах по мотивам моего доклада для DevOps Conf. Этот материал посвящён одновременно практике организации работы команды и инструменту, реализующему эту практику.

В предыдущей части мы познакомились с девконтейнерами в целом, изучили его составляющие, способы организации, упаковку репозиториев, как работать с более чем одним контейнером и прочим. Освежить эти знания в памяти вы можете по ссылке, а сегодня — двигаемся дальше. И первый вопрос на повестке дня — безопасность.

Небольшой спойлер: в этой статье вас ждёт небольшой полезный подарок!

О том, как одна базовая задумка – сделать разработку управляемой, пережила эпоху тяжелых каскадных проектов, DevOps, CI/CD, и подошла к 2026 году уже в совсем зрелом виде.