DevOps *

Что получится, если собрать PostgreSQL, Airflow, JupyterLab, MinIO, Superset, шесть MCP-сервисов и локальную модель Ollama в одном Docker Compose-стенде?

Показываю полный путь синтетических промышленных данных: от витрин и проверок качества до Parquet-артефактов, MCP-инструментов и LLM-пояснений. Внутри — архитектура, воспроизводимый запуск, результаты проверок и открытый репозиторий.

SRE‑инженер Mindbox рассказывает, как DevOps‑команда столкнулась с неконтролируемым запуском хаос‑тестов, когда проводила плановые проверки с помощью Chaos Mesh. Что запускало «зомби‑тесты», какие пробовали решения и на чем в итоге остановились — делимся в статье.

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

Привет, Хабр! На связи Илья Шаров (@issharov), Head of DevSecOps, и Николай Лузгин, DevSecOps Lead из МТС Web Services. Мы тоже через это проходили и в какой-то момент пересмотрели весь подход. Если в прошлый раз мы рассказывали о пользе, ролях и о том, что стоит предусмотреть при внедрении Security Champion, то сегодня поделимся опытом трансформации: как сместили фокус на вовлеченность, развитие компетенций и естественное встраивание безопасности в повседневную работу команд.

Всё началось с обычной бытовой боли. У меня был сайт, и сайту иногда нужно было сказать мне что-то важное: «заказ оплачен», «диск на 91%», «пришёл ответ от банка».

Так родилась идея: сервис, куда сайт стучится одним HTTP-запросом, а на всех твоих устройствах через секунду загорается уведомление. Я назвал его Pheme.

А дальше случилось то, что случается со всеми пет-проектами. Ты пишешь «просто релей уведомлений», потом смотришь на код и понимаешь, что у тебя уже есть пользователи, устройства, каналы, история сообщений, лента, комментарии — и остаётся дописать «всего лишь» шифрование, звонки и федерацию, чтобы получился полноценный мессенджер. Что я и сделал.

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

Меня зовут Владимир Фидунин, я работаю в команде мессенджера VK WorkSpace. В статье расскажу, как мы прошли путь от Puppet + Helm до Helmwave и почему в итоге он стал для нас универсальным инструментом управления Helm-релизами. 

Разработчикам регулярно требовались виртуальные машины, но self-service не существовал. Образ, ресурсы, сеть и доступы настраивала инфраструктурная команда. По отдельности операции были несложными, но в сумме пользователи ждали, а инженерное время уходило на повторяемую ручную работу.

Так появился внутренний dev cloud на KubeVirt. Разработчик сам создаёт VM из поддерживаемого шаблона, управляет lifecycle и портами, меняет ресурсы, смотрит Events, метрики и serial-консоль. Платформа сохраняет контроль над доступами, шаблонами, бюджетами команд и ёмкостью нод.

В статье показано как на базе KubeVirt получился цельный внутренний продукт с минимальными трудозатратами, в котором разработчик действует самостоятельно, а платформа сохраняет контроль над dev-контуром и блокирует создание VM сверх бюджета команды.

Я давно привыкла первым делом спрашивать «а как это упадет?». Когда в наш ландшафт пришли ИИ‑агенты, выяснилось интересное: привычные ответы на этот вопрос здесь просто не работают. Агент в проде, дашборды настроены по классике: latency, error rate, uptime. Алертов нет, агент исправно отвечает на каждый запрос. А то, что он три дня подряд уверенно врет, вы узнаете из жалобы пользователя, и никак иначе.

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

Павел Монин, ведущий DevOps- и ИИ-инженер и студент курса «Английский для ИТ» от Across, работает в израильском офисе американской компании Autofleet.

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

В этой статье расскажу, как мы построили отдельный модуль управления корпоративными чатами и каналами на Django, PostgreSQL и Telethon. Без привязки к нашей внутренней инфраструктуре — только архитектура, технические решения и несколько выводов, которые могут пригодиться при решении похожей задачи.

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

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

Обо всём этом в статье!

Всем привет! Меня зовут Рома, я бэкенд-инженер в Банки.ру. Мы перевели мобильное API на KrakenD, и сейчас через него идёт весь трафик приложения.

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

Сегодня Kubernetes стал де-факто стандартом для развёртывания SaaS-приложений и сервисов. Практически каждый разработчик работает с ним ежедневно, но большая часть этой работы связана с установкой уже готовых компонентов и манифестов. Если базового функционала начинает не хватать, возникает потребность в расширении. И вот тут начинается путешествие в уникальный мир k8s-операторов.

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

Меня зовут Антон Железнов, я разработчик в команде Managed Kubernetes облака MWS Cloud Platform. И в этой статье я хочу рассказать о тестировании операторов не на абстрактных примерах, а на устройстве нашего решения. Итак, поехали! 

Казалось бы, учетная запись в GitLab — не самая удачная стартовая точка для инфраструктурного пентеста. Ни VPN в корпоративную сеть, ни доменного аккаунта, ни даже RDP на рабочую станцию, только креды рядового разработчика. Вряд ли в начале проекта заказчик ожидал серьезного импакта, но мы доказали, что при типовых настройках CI/CD такая учетка находится на расстоянии нескольких прыжков до контроля над облаком. 

Давайте вместе пройдем эту цепочку.

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

Во второй части мы поищем ответы на вопросы кто и на какой платформе будет сопровождать production через Kubernetes, инфраструктурные платформы, DevOps as a Service, облака, data-платформы и инструменты разработчика. Команды пытаются снять рутину эксплуатации, собрать внутренние платформы, автоматизировать инфраструктуру через API и Terraform, а заодно встроить AI и data-инструменты в SDLC так, чтобы они помогали разработчику, но не получали бесконтрольный доступ к критичным средам.

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

Пока их двадцать, это терпимо. Когда приходит сорок первый клиент, ты открываешь кабинет и снова кликаешь: создать проверку, интервал, порог, теги, сохранить. Четыре раза. А потом кто-то спрашивает: «а почему у этого сайта порог два, а у соседнего три?» — и честный ответ звучит как «не помню».

Инфраструктуру мы описываем кодом уже лет десять. Мониторинг — почему-то нет. Хотя это ровно такая же конфигурация: её надо ревьюить, версионировать и уметь воспроизвести.

Я делаю внутреннего read-only LLM-агента для инфраструктурных расследований. Инженер задаёт вопрос обычным языком, а агент собирает доказательства из Kubernetes, метрик, логов, GitLab, Grafana и других эксплуатационных источников.

Один реальный кейс показал, почему «умного промпта» недостаточно: edge вернул 502, хотя приложение для того же request_id записало успешный редирект 302. Чтобы найти причину и не придумать удобное объяснение, агенту пришлось научиться связывать источники, удерживать время и scope, различать факты, гипотезы и отсутствующие данные.

В статье разбираю архитектуру агента на Go, DeepSeek, Qwen и MCP: планирование по evidence, контракты tools, память треда, подключение командных skills через n8n и evaluation на реальных сценариях. В последнем полном прогоне прошли 44 из 45 сценариев, включая все 29 обязательных.

Kubernetes незаметно стал платформой по умолчанию для ИИ и машинного обучения. Запускаете ли вы серверы notebook-ов для дата-сайентистов, планируете распределённые задачи обучения, настраиваете гиперпараметры или оркестрируете многоэтапные ML-пайплайны. Эти нагрузки всё чаще оказываются в кластере Kubernetes. Kubeflow — один из самых популярных способов собрать этот стек, причём Kubernetes-нативным путём: каждая возможность описана как CRD (Custom Resource Definition, описание пользовательского типа ресурса Kubernetes).

Такая архитектура подарок операторам кластера: ML-нагрузки можно наблюдать и управлять ими теми же примитивами, что и всем остальным в кластере. Но на практике специализированные ML-дашборды, которые поставляются с этими платформами, скрывают лежащий под ними слой Kubernetes. Когда notebook застревает или задача обучения падает, оператор часто вынужден откатываться к kubectl, чтобы выяснить, что на самом деле произошло на уровне Pod.

Команда VK Cloud перевела статью о плагине Headlamp Kubeflow, который закрывает этот разрыв и выводит пользовательские ресурсы Kubeflow прямо внутри универсального Kubernetes UI. Это проработанный пример паттерна, которому может следовать любая насыщенная CRD платформа: встречать операторов там, где они уже работают, и показывать им истину на уровне кластера.

Сам Headlamp это расширяемый веб-UI для Kubernetes, поддерживаемый в рамках Kubernetes SIG UI и лицензированный под Apache 2.0. Он работает как десктопное приложение или внутри кластера, а через систему плагинов кто угодно может добавить полноценные представления для пользовательских ресурсов.

Когда Atlassian объявила о завершении продаж Opsgenie, я сначала отреагировал как нормальный инженер: решил ничего не переписывать. Потом календарь напомнил, что нормальность имеет срок действия. Продажи Opsgenie прекратились 4 июня 2025 года, а поддержка завершится 5 апреля 2027 года. После этого сервис станет недоступен, а немигрированные данные будут удалены. Это не слух из рабочего чата, а официальная позиция Atlassian (условия и даты завершения Opsgenie).

Предлагаемый путь ведёт прежде всего в Jira Service Management, причём Atlassian описывает автоматизированную миграцию данных и конфигурации (официальная страница миграции). Для многих компаний это разумный маршрут. В моём случае требование было другим: сохранить существующую self-hosted Jira, не превращать замену on-call инструмента в миграцию всей сервисной модели и получить контроль над данными, интеграциями и deployment.

Я посмотрел альтернативы. Ближе всего по общей идее оказался OpsKnight: проект позиционирует себя как open-source self-hosted платформу для incident response, on-call, routing и status pages (официальный сайт OpsKnight). На бумаге соседство было почти семейным. Но мой набор требований включал автоматическое создание задач именно в нашей Jira, Slack и eXpress, прозрачную передачу L2 в L3, русский и английский интерфейс, простое развёртывание и предсказуемое поведение в небольшом внутреннем контуре. В моём тестировании OpsKnight с этим набором не совпал и не дал нужной уверенности. Это не универсальный вердикт проекту, а описание моего опыта и моей планки риска.

Классическая сцена. Команда выкатывает релиз, деплой проходит зелёным, kubectl rollout status рапортует об успехе — а в графиках ингресса на минуту вырастает горка пятисотых. Не тысячи, обычно доли процента, но стабильно, каждый деплой.

Дальше начинается фольклор. «Ну это же рестарт, при рестарте всегда так». «Добавьте ретраи на клиенте». «Деплойтесь ночью». Самый частый вариант — на графики просто перестают смотреть в момент выката.

На самом деле rolling update умеет проходить вообще без потерь, и readiness-проба тут ни при чём — она отвечает за другую половину задачи. Потери происходят на выключении подов, и причина в том, что удаление пода — это не последовательность шагов, а гонка.

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

Поэтому часто в современной DevOps-практике используется Infrastructure as Code (IaC) — подход, при котором инфраструктура описывается в виде кода и может быть создана или изменена одной командой. Одним из самых популярных инструментов для этого является Terraform.

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

С момента как появился домашний сервер было желание сделать нормальный медиа сервер - чтобы по красоте смотреть фильмы и сериалы в 4K, без костылей.

Хотелось свести получение любого фильма или сериала к одному действию: нашёл → нажал «скачать» → посмотрел. Всё остальное - поиск релиза, скачивание, проверка качества и языка дорожки, переименование файла, раскладка по нужным папкам библиотеки - должно происходить где-то фоново, без меня.