DevOps *

Финал цикла про облачную LLM на 16 ГБ VRAM.

За две предыдущие статьи мы подняли собственную локальную модель на облачном сервере с GPU на 16 ГБ VRAM, разобрались с vLLM и tool calling, собрали агентный бэкенд на LangGraph с MCP-серверами, получили вокруг него полноценный REST API из коробки и обернули все это в FastAPI-сервис через LangGraph SDK.

В этой части закрываем полный стек: к готовому агентному бэкенду на LangGraph подключаем официальный ChatGPT-подобный фронтенд от LangChain — agent-chat-ui. Переводим на русский, добавляем переключатель между тремя агентами разной архитектуры и удаление чатов. Закрываем API Bearer-авторизацией с разбором нюансов, которых нет в документации. Деплоим всё на VPS с доменом и SSL — LangGraph внутри контура, наружу смотрит только фронт.

Когда речь заходит о Flipper Zero, большинство вспоминает RFID, NFC, Sub-GHz и бесконечные ролики про открытие шлагбаумов. Но одна из самых интересных возможностей устройства — встроенный JavaScript-движок и модуль BadUSB, который позволяет превратить Flipper в программируемую USB-клавиатуру.

В этой статье разберём небольшой, но показательный скрипт, который автоматически устанавливает набор инструментов для пентеста на macOS через Homebrew. Заодно посмотрим, почему JavaScript на Flipper оказывается значительно интереснее классического DuckyScript.

Привет, Хабр! Меня зовут Антон Алексеев, я MLOps-инженер в Авито. 

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

Статья будет полезна не только тем, кто разрабатывает и использует платформы в больших компаниях, но и тем, кто работает на DevBox-машинах или небольших платформах для юнит-команд от 10 до 100 человек.

На связи Андрей, руководитель направления безопасности облака в Selectel. Под катом расскажу, как настроить автоматический сбор данных о работающих Docker-контейнерах — образах, привилегиях и capabilities — и передать их в Wazuh для мониторинга и алертинга.

Если вы работаете техническим инженером в отделе эксплуатации, то с вероятностью 99,9% вы знакомы с Prometheus и прекрасно разбираетесь в языке запросов promQL. Но даже в «родной и знакомой» сфере есть области, которые остаются вопросительными пятнами. Например, «Сравнение векторов»/«Сопоставление векторов». Это механизмы promQL, которые применяются не так часто, плохо документированы и неочевидны для понимания. Привет, Хабр! На связи Александр, руководитель кластера надёжности в компании ecom.tech, кластер надёжности занимается SRE, проводит тестирование нагрузкой и обеспечивает стек Observability. Этой статьей я постараюсь сделать вашу жизнь чуточку проще, на примерах объяснив нюансы непростой механики сопоставления.

2 июня мой мониторинг аптайма разом отрапортовал, что упало почти всё: 932 инцидента за 25 минут. Сайты были живы — все до единого. Виноваты дефолтный лимит файловых дескрипторов 1024 и «оптимизация», тихо размножившаяся в 60 раз. Разбираю по приборам: /proc, ss, EMFILE и почему docker compose restart не спасает.

Когда у вас один AI-агент в браузере, всё просто. Когда их пять и они параллельно ходят по разным сайтам через Playwright MCP, начинается война за вкладку. Штатный @playwright/mcp работает в общем BrowserContext, и агенты перехватывают страницы друг у друга. Отдельный контекст через newContext() решает изоляцию, но убивает логины.

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

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

Я старался писать для разных грейдов: от базовой гигиены вроде workflow:rules, cache, artifacts и needs до более продакшеновых тем вроде OIDC, Vault, CI_JOB_TOKEN, защищённых окружений, ревью-окружений, очередей слияния, BuildKit без root-прав, CI/CD-компонентов и усиления защиты раннеров.

Поэтому язык подачи здесь намеренно сухой, прямой и инженерный: без долгих заходов, без воды и без пересказа документации ради пересказа. Я хотел сделать не обзорную статью, а рабочую памятку, к которой можно вернуться при написании нового пайплайна, ревью .gitlab-ci.yml, переносе проекта в GitLab или наведении порядка в уже существующей CI/CD-платформе.

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

Оглавление:

1. Зачем вообще думать о GitLab CI/CD

2. Архитектура пайплайна и базовая YAML-гигиена

3. rules, workflow:rules и управление созданием пайплайна

4. DAG, needs, параллелизм, матрицы и быстрые пров...

Ubuntu Server ставит security-обновления сам, по умолчанию — это не настройка, которую кто-то включил, а поведение из коробки. У механизма два типичных следствия, которые админ месяцами не может опознать.

Одиночный сервер «моргает» каждое утро в районе 06:xx на 10–30 секунд: сервис остановлен и тут же запущен, виновного в журнале будто нет, и даунтайм списывают то на сеть, то на GC. Кластер из трёх–пяти узлов, который спокойно переживает падение одного узла, в какой-то момент роняет себя сам: обновление с перезапуском прилетело на все узлы в одно утро — кворума не осталось.

Источник у обоих один: таймеры автообновлений с узким окном после шести утра плюс needrestart, который перезапускает не только обновлённый сервис, но и всё, что слинковано с обновившейся системной библиотекой (libssl3, libc6, zlib1g). Разберём, как подтвердить диагноз за две минуты и как развести узлы во времени — от drop-in к таймеру до координации через Ansible и PodDisruptionBudget.

Статья посвящена практической реализации агента с изолированной средой исполнения кода. Рассказываю как устроен агент, который пишет и исполняет код в Docker песочнице.

Это вторая часть серии про LLM Sandbox. В первой части мы разобрали риски исполнения кода от LLM, ограничения песочницы, способы изоляции (Docker, Wasm, gVisor, microVM) и минимальную архитектуру агент+песочница.

Код реализации агента, skills, полные логи и артефакты примера — в открытом GitHub-репозитории.

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

Проект был разбит на множество микросервисов, каждый из которых хранил данные в собственной PostgreSQL-базе. Чтобы строить сквозные отчеты, информацию нужно было где-то объединять.

На тот момент аналитика уже работала через ETL: раз в сутки Airflow восстанавливал общую PostgreSQL из ежедневных бекапов, а Redash выполнял запросы уже к ней. Решение было надежным и не требовало нагрузки на production, но для real-time оно не годилось — в лучшем случае отчеты показывали состояние системы на начало дня.

За шесть предыдущих выпусков мы собрали собственный конвейер безопасной разработки: развернули виртуальные машины, подняли инфраструктуру из GitLab, Vault, Nexus, DefectDojo и Dependency-Track, написали CI/CD-пайплайн, подключили сканеры безопасности и настроили резервное копирование.

Остается главный вопрос: сможет ли наш конвейер находить реальные уязвимости, а не просто радовать разработчиков зелеными галочками в интерфейсе GitLab? 

Как говорили старые DevSecOps-бояре, «в нашем деле на слово не верят — безопасность нужно проверять».

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

Привет, Хабр! Меня зовут Дмитрий Гоголев, я занимаюсь развитием платформы управления виртуальной и облачной инфраструктурой Cloudlink и направлением частного облака Orion Private Cloud (OPC) в Orion soft. Многое в ИТ-инфраструктуре можно сделать своими руками. Чем больше вы занимаетесь этим, тем лучше понимаете, как это сделать… но иногда легче все-таки с автоматизацией. 

В большинстве случаев у DevOps уже есть набор инструментов автоматизации. Практически все используют Ansible и Terraform или их аналоги для создания окружений. Многие переходят на IaC. Проблемы начинаются в крупных, иногда распределенных инфраструктурах. При отсутствии централизованной платформы, которой могут пользоваться не только сами инженеры, приходится тратить значительное время на согласования, ручные операции и разбор инфраструктурных ограничений. При отсутствии единого каталога типовых сервисов, включающего ВМ, Kubernetes-кластеры, namespaces, хранилища, сети, шаблоны окружений, создание окружения может занимать дни или недели, потому что требует ручных согласований.

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

Всем привет, меня зовут Вячеслав, я Team Lead SRE в Купере. Рассказ в этой статье пойдет о том, как мы внедряли SLO, чего достигли и какие лайфхаки нашли по дороге.

За последние годы я несколько раз видел одну и ту же картину в небольших и средних компаниях. Для приложений поднимают S3-совместимое хранилище. Для людей — отдельный файловый сервис или сетевые шары. LDAP/OIDC живёт отдельно. Бэкапы — третий контур. Мониторинг — четвёртый. Всё работает, пока не приходит внутренний аудит или новый филиал с формулировкой: «нам нужен корпоративный диск с SSO, журналом и данными только у нас».

В статье разбираем на боевом примере (Spring Boot 4.1, Java 21, GitLab 19.1), как поймать уязвимую зависимость в merge request — до прода, не уронив пайплайн. Подключаем SBOM‑сканер нового поколения, включаем reachability, чтобы отсеять весь шум, и ставим security‑гейт, который реагирует, только на уязвимости, которые несет в себе конкретный MR.

Однажды я зашёл в компанию через неделю после крупного падения и попросил показать постмортем. Мне показали — с гордостью. Таймлайн поминутно, five whys, аккуратный список action items, owner напротив каждого, разослано по всем спискам. Красиво. «Видите, мы серьёзно подошли».

Я задал один вопрос: а постмортем по прошлому такому же падению — где? Нашли. Открыли. Те же action items. Слово в слово. С прошлого раза не закрыт ни один.

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

И вот тут важно не поспешить с выводом «разгильдяи, не довели». Потому что если присмотреться, этот постмортем не провалился. Он отлично сработал. Просто работа у него была не та, что написана на упаковке.

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

Привет! Меня зовут Евгений, я работаю в БКС Мир инвестиций владельцем сервиса «Портфель».

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

Для клиента это обычный экран в приложении или личном кабинете. Открыл, посмотрел, что происходит с деньгами, принял какое‑то решение.

Но внутри компании за этим экраном стоит много всего. Backend‑сервисы, frontend, интеграции, биржевые данные, банковские продукты, сетевой путь, мониторинги, SLA, обращения клиентов в контактный центр, поддержка, аналитика, релизы и ожидания бизнеса.

На стыке всего этого и появляется роль Service Owner.

В прошлой статье мы завершили сборку конвейера безопасной разработки: настроили GitLab CI/CD, подключили Vault для безопасной работы с секретами, добавили статический и динамический анализ, генерацию SBOM, а также интеграцию с DefectDojo, Dependency-Track и Nexus. Теперь у нас есть пайплайн, который автоматически собирает приложение, проверяет его на уязвимости и сохраняет результаты анализа. 

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

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

Несколько месяцев назад в публичном пространстве появилась история, которую в engineering-сообществе стали называть поучительной. Команда AWS использовала внутренний AI-инструмент Kira для ускорения работы. Kira предложила джуниорам сценарий: переразверни продакшн-слой. Инженеры согласились. Следующие шесть часов весь AWS не работал. После разбора полётов компания объявила новое правило: финальный апрув на изменения, предложенные агентом, должен давать сениор-инженер.

На первый взгляд, решение логичное. На второй, уже менее. Если агент генерирует изменения в темпе, к которому люди не привыкли, один сениор превращается в бутылочное горлышко для бесконечного потока PR. Это не решение проблемы. Это антипаттерн, оформленный как процесс.

История AWS точно формулирует главный вызов 2025-2026 годов: AI научился быстро писать код, но индустрия пока не научилась с такой же скоростью его доставлять, проверять и принимать решения о нём. Данные, собранные в рамках масштабного исследования State of AI4SDLC, это подтверждают.