DevOps *

На третий день в проде мой support-агент на LangGraph и GPT-4o слил email одного клиента в переписку с другим. Причина банальна: модель вставила сырой контекст из базы прямо в ответ, и ничто в пайплайне это не проверяло. Фреймворки для агентов дают оркестрацию, вызов инструментов и память — но не безопасность. В этой статье разбираю стек из четырёх guardrails (валидация входа, валидация выхода, circuit breaker по расходам и проверка вызова инструментов), который умещается в ~200 строк Python и добавляет менее 40 мс latency. С рабочим кодом, схемой пайплайна и честным разбором того, что эти guardrails ловят, а что — нет.

Скриптов «забэкапь мне сайт» в интернете тысячи. Большинство падает на shared-хостинге, потому что там либо нет crontab -e, либо нет rsync, либо mysqldump лежит в нестандартном месте, либо у вас нет root, чтобы починить права на /tmp. А ещё — почти все игнорируют ротацию, и через два месяца ваш FTP забит 300 архивами по 200 МБ каждый.

В этой статье — рабочая схема для типичного клиентского сайта на Beget/Timeweb/Rusonyx-подобном хостинге, без панельных «бэкап-сервисов» за деньги, с дампом базы, ротацией и без хранения паролей в git.

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

В статье разбираем, как измерять архитектурный долг через метрики, находить реальные точки трения и не допускать превращения проекта в Big Ball of Mud.

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

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

Именно для этого существуют Deployment Strategies — набор подходов, которые определяют, каким образом новая версия приложения попадает в продакшен. В этой статье разберём самые популярные стратегии деплоя: Recreate, Rolling Update, Blue-Green, Canary и Shadow, посмотрим их плюсы и минусы, а также выясним, в каких сценариях каждая из них действительно полезна.

Привет, Хабр! Я Миша Онянов, Python-разработчик и платформенный инженер в крупнейшем проекте MAGNIT TECH – F&R. Из статьи вы узнаете, как с помощью механизма Cluster Policies в Apache Airflow вынести требования к DAG’ам в исполняемый код:

- Поговорим о том, когда и зачем нужен отдельный слой Policies.

- Посмотрим на примеры требований в больших data-инженерных проектах и способ их реализации с помощью политик.

- Покажу нашу архитектуру, примеры кода и способы внедрения.

- Сделаем выводы из моих ошибок, допущенных при разработке и внедрении.

- В конце посмотрим, в каких ещё системах используется аналогичный механизм.

Материал будет полезен всем, кто собирается внедрять или уже работает с Apache Airflow ✌️🥸

Я работаю в IT-консалтинге первый год и параллельно веду несколько пет-проектов вместе с Claude Code. И в какой-то момент меня начало беспокоить одно и то же:

«А код, который мне написал AI, вообще безопасный?»

Несколько личных проектов я собрал в связке с Claude Code, и раз уж большую часть code review я отдаю модели, то вполне реально, что куда-нибудь просочится:

Когда Docker-образ backend-приложения начинает весить 1,5 GB, это уже хороший повод хотя бы посмотреть, что вообще лежит внутри. Пока все работает, мало кто задумывается, сколько мусора, dev-зависимостей и ненужных файлов уезжает в production вместе с приложением. Но на самом деле от «лишнего веса» нужно избавляться, потому что каждый лишний мегабайт — это более долгие сборки и дополнительные сложности.  

В прошлой статье цикла мы закончили разворачивать инфраструктуру будущего РБПО: установили GitLab, Nexus, HashiCorp Vault, Dependency-Track и DefectDojo, подготовили отдельную виртуальную машину с инструментами безопасности и убедились, что все сервисы успешно запускаются.

Но установить сервисы — это только половина дела. Теперь их нужно настроить и подготовить к совместной работе. Без этого GitLab останется просто GitLab, Vault — просто хранилищем секретов, а DefectDojo и Dependency-Track — красивыми веб-интерфейсами без практической пользы.

В этой статье займемся базовой конфигурацией. Настроим GitLab и GitLab Runner, подготовим Nexus к приему артефактов, научим Vault доверять GitLab через JWT-аутентификацию и создадим необходимые сущности в DefectDojo и Dependency-Track.

Документация открыта, терминал запущен, банка кваса на месте. Начинаем настройку инструментов.

В современных веб-приложениях хранение файлов часто отдают специализированным объектным хранилищам, таким как S3. Это удобно, масштабируемо и надежно. Однако здесь возникает классическая проблема проектирования: как обеспечить безопасный доступ к файлам, когда архитектура требует, чтобы хранилище было приватным, а бизнес-логика прав доступа — централизованной? Оставлять S3-бакет публичным — плохая практика, а проксировать каждый запрос на скачивание через бэкенд-сервис — значит, превратить его в «бутылочное горлышко», которое неизбежно захлебнется при росте трафика.

В этой статье я познакомлю вас с реализацией бэкенд-сервиса, который решает эту проблему элегантно: S3 отвечает за хранение и отправку данных, а мое приложение — за проверку прав и генерацию одноразовых, короткоживущих ключей доступа (Pre-signed URL). Я разберу архитектуру решения, покажу, как настроить безопасное разграничение доступа между публичными и приватными объектами, а также продемонстрирую механизм, который позволяет клиентам скачивать файлы напрямую из хранилища, минуя сервер приложения.

Материал будет полезен бэкенд-разработчикам, системным архитекторам и DevOps-инженерам, которые сталкиваются с задачами организации безопасного хранения и выдачи файлов, ищут способы снижения нагрузки на API своего сервиса и стремятся построить надежную систему разграничения прав доступа с использованием современных объектных хранилищ.

Статья про то, как удалёнка незаметно меняет тело. Перед длинными выходными особенно актуально :)

🍔 Это не про «ЗОЖ-героизм» или «срочно всем в зал», а про честную инженерную диагностику собственного режима: где сломались метрики, почему это долго не было видно и что пришлось поменять, чтобы вернуть организм из состояния «вроде работает» к нормальной эксплуатации.

🧘🏼‍♂️ Внутри: удалёнка, движение, питание, спортзал, skinny fat и немного DevOps-подхода к себе.

Заходите, читайте и делитесь своим мнением и опытом ❤️

Немного практики для "пощупать" HPA в кластере, поиграться параметрами масштабирования. Можно было бы быстро перейти от теории к практике, ну или наоборот. В примерах используется масштабирование на основе очереди RabbitMQ. Можно использовать minikube, MicroK8s, или где вам удобно... Для удобства развёртывания примеры k8s-hpa-rabbitmq-demo.

Если вы запускаете GPU-нагрузки (графические ускорители) на Kubernetes — vLLM, Triton, обучающие задачи или более новые стеки агентного инференса, — вы наверняка сталкивались со знакомой проблемой: стандартный автоскейлинг по-прежнему мыслит в категориях CPU и памяти, а GPU, который реально делает работу, остается невидимым. Из-за этого простаивает дорогая емкость ускорителей, растет задержка инференса и расходуется лишняя энергия — ровно там, где компании пытаются ответственно масштабировать LLM и Agentic Ops (подходы к эксплуатации Agentic-систем).

VK Cloud перевела статью автора, который хотел бы, чтобы KEDA масштабировался по сигналам, которые важны для GPU-нагрузок: утилизации, памяти, температуре и энергопотреблению. На практике это не только вопрос стоимости. Это еще и вопрос GreenOps (экологичный подход к эксплуатации с минимизацией углеродного следа): впустую потраченные GPU-циклы напрямую превращаются в потраченную энергию и более высокие выбросы категории Scope 3 (косвенные выбросы в цепочке создания стоимости).

Оказалось, что это сложнее, чем кажется. Дальше повествование идет от его лица

Я реализовал свою первую задачу по замене «Яндекс Диска», довёл скорость до 1,1 ГБ/с и пошёл дальше — установил Kubernetes дома. Я не инженер DevOps, но на своём кластере из старых Mac mini я запустил полноценный K8s с Managed Services.

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

В этой статье (ее первой части) разберём среду изолированного исполнения кода: песочницу (sandbox).

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

И тут появляется вопрос: где этот код запускать?

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

В этой статье разберём:
- основные риски исполнения кода в неизолированной среде;
- что такое песочница и её ограничения;
- какие бывают подходы к реализации песочницы;
- вариант логики работы агента с песочницей.

Мы использовали Terraform как полагается. Потом сделали плановый apply — и положили прод второй раз за неделю. Разбираю, почему IaC не гарантирует консистентность, откуда берётся конфигурационный дрейф и почему «введём процессы» его не остановит.

Есть устойчивое поверье: интеграционные тесты медленные, потому что ходят в настоящую базу. «Подними SQLite в памяти», «замокай репозитории», «не гоняй Postgres в CI» — стандартный набор советов. Мокать я не люблю, но крыть упрёк «настоящая база — это медленно» было нечем. Поэтому я сел, спрофилировал и померил: 3316 интеграционных тестов, прогон 30 минут. После трёх правок инфраструктуры — 109 секунд. База оказалась ни при чём, а совет «чисти базу через TRUNCATE, это быстрее DELETE» у меня работал ровно наоборот — обидно вдвойне, потому что эта рекомендация уже лежала в черновике моей следующей статьи.

Продолжение истории про переезд ИИ-агента Паспарту с OpenClaw на Hermes. На этот раз — как я пересадил его на дешёвый DeepSeek, научил переключать модели на лету, подключил бесплатную NVIDIA Nemotron через OpenRouter и приделал Codex, который доводит сложные задачи до конца сам, пока ноутбук выключен. Грабли №16–25: стали мельче, но никуда не делись.

Дисклаймер: вся статья это мнение автора, если вы не согласны или готовы предложить что-то, то прошу в комментарии.

IT охватывают огромный простор навыков и идей, многие из них специфичны и предназчена для узкого круга профессий. При этом существуют навыки, которые или универсальны для всех, или не будут лишними точно. В данной статье пойдет речь про Git, SQL и NoSQL, Linux, базовый азы алгоритмов и структур данных и о английском языке. Дополнительно поставил себе задачу, добавить как можно больше бесплатных или квази-бесплатных ресурсов.

По данным исследования, 69% интернет-магазинов в периоды высокого трафика сталкиваются со снижением скорости работы сайта, 38% — со сбоями отдельных функций, а четверть — с полной остановкой сайта. В сезон под ударом вся инфраструктура.

Меня зовут Эдуард, я руковожу отделом DevOps и отвечаю за сопровождение проектов по SLA 24/7 в компании KISLOROD. Сегодня расскажу о том, как пиковая нагрузка системы влияет на интернет-магазины и как готовить бизнес к дню икс.

Ранее уже выкладывал способ, Как починить блокировку легальных сайтов РКН ТСПУ одной строчкой в Chrome - он работает, но не для всех.

Теперь же мы разберем ситуацию, как починить Ваш сайт если Вы Владелец / Администратор, расскажу как к этому пришёл и почему это работает.