DevOps *

SRE‑инженер Mindbox Дима Рыбалка рассказывает, как команда за два месяца перенесла 40 кластеров ClickHouse в Yandex Cloud. Внутри — как выбирали стратегию миграции, связывали кластеры без VPN, переключали клиентов через cutover без даунтайма и с какими столкнулись проблемами после миграции. Материал будет полезен SRE‑, DevOps‑ и DBA‑инженерам, которые работают с ClickHouse в Kubernetes.

По прогнозу Gartner, к концу 2026 года task-specific AI-агенты будут встроены в 40% корпоративных приложений против менее чем 5% в 2025-м по оценке той же Gartner. Безопасность агента обычно сводят к guardrails, промпт-фильтрам и хорошо написанной системной инструкции. Однако в июле 2025-го случился инцидент —  агент Replit удалил прод-базу SaaStr, хотя его несколько раз просили ничего не менять. А в июле 2026-го на Хабре был опубликован разбор того, как имя, работодатель и город пользователя ушли наружу через Claude без единого клика с его стороны.

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

Переименование проекта в Docker Compose может создать новые пустые volumes, пока старые данные спокойно остаются на диске. Разбираю, какие внутренние идентификаторы нельзя менять через Replace All и как провести ребрендинг с возможностью отката.

Объём неиспользуемых ресурсов не уменьшается (хотя вроде как должен), а узлы бесконечно ротируются. Это нормально для автоскейлера или пора что-то чинить?

В статье — детально о механизме консолидации в Karpenter, а главное — можно (и нужно) ли как-то его исправлять.

Привет! Меня зовут Женя, я деврел в Банки.ру. Короче, у нас есть подкаст “про код.ии.прод” и на Хабре в комментариях нам предложили расшифровать выпуски и оформить их в статьи. Мы любим эксперименты — поэтому решили попробовать. Главное, чтоб зашло вам, друзья.

В прошлый раз мы разгоняли про вайбкодинг: усиливает он инженера или ведет к деградации навыков. Идем дальше. Принимаем как факт, что ИИ помогает писать код быстрее. Но разработка это не только написание кода. Есть постановка задач, ревью, тесты, интеграция, деплой, поддержка, инциденты... Главный вопрос выпуска: ИИ ускоряет путь от идеи до прода целиком или просто генерирует больше кода и пулл-реквестов?

Эта статья — история о том, как небольшая команда перевела медицинскую информационную систему с устаревшей платформы 1С 7.7 на 1С 8.3 и выстроила вокруг неё современные практики разработки: контроль версий, код-ревью, автотесты, CI/CD. Дальше — сама история.

В начале двухтысячных классные специалисты разработали систему для клиники на базе 1С 7.7. Функционал включал как административно-хозяйственную часть, так и работу с пациентами. Программный продукт проработал почти два десятилетия, код отладили и протестировали самой жизнью, а идея, что новый код может оказаться лучше старого, казалась совершенно абсурдной. Система при этом технологически устарела: ручное формирование XML отнимало значительное количество времени у программиста, а запросы к БД и обработка данных таблиц для отчётов могли занимать десятки минут. Казалось бы, простые интеграции как XML и REST реализовывали через костыли. Экстренную правку кода приходилось вносить с отключением всех пользователей программы на несколько минут — динамическое обновление для семёрки попросту не разрабатывали.

В 2020 году руководство клиники приняло решение о миграции на новый технологический стек и через год привлекли разработчиков. Всерьёз рассматривался только вариант 1С 8.3: на момент принятия решения других вариантов, сопоставимых по зрелости экосистемы и доступности специалистов на рынке, просто не существовало. Речь шла не о внедрении готового отраслевого решения, а о разработке под одного конкретного заказчика — максимально повторяющей то, к чему сотрудники клиники привыкли за два десятилетия. Устоявшиеся процессы, интерфейсы документов и порядок работы заказчик менять не планировал.

Продолжая поиски интересных курсов(в этот раз не авито), я наткнулся на необычный материал по контейнеризации. Обычно всё выглядит одинаково: Docker, команды, образы, и в конце внезапно появляются Ansible и Kubernetes. Как будто без них нельзя объяснить, что такое контейнер. Или авторы просто пытаются запихнуть побольше в один курс, чтобы казалось, будто его стоимость оправдана. Ну да ладно.

А мне хотелось чего-то другого. Помните книгу про внутреннее устройство Linux Кетова?
Ещё в 2022 году мне понравилось, как подавался материал про контейнеризацию — от самых её зачатков (chroot) до самого Docker. Вот именно такое я хотел увидеть у кого-нибудь, но с актуализированной информацией.

И такой курс нашёлся на Степике(не реклама если что). Автор как раз пошёл от самого начала: chroot, пространства имён, контрольные группы, ручной запуск контейнера без Docker, и только потом — сам Docker со всеми его фишками. По сути, это получилась современная версия той самой главы из книги Кетова про контейнеризацию.

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

Привет, Хабр! Меня зовут Михаил Шпаков, я развиваю Statuser — сервис мониторинга доступности сайтов. Раньше я рассказывал, как он появился и что я узнал за год, мониторя 6 500 сайтов.

Недавно мне написал пользователь Statuser. В его продукте модель разбирала обращения клиентов и готовила для операторов черновики ответов. В какой-то момент эта функция перестала работать, хотя обычный HTTP-монитор, настроенный на адрес ИИ-гейтвея, продолжал показывать зелёный статус. О проблеме сообщили операторы поддержки, а не мониторинг.

Причина оказалась простой: провайдер снял выбранную модель с обслуживания, но сам гейтвей продолжал работать. HTTP-монитор проверял его обычным GET-запросом и получал успешный ответ. Запрос на генерацию он не отправлял, поэтому состояние конкретной модели не видел.

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

После этого случая я понял, что не хватает отдельного типа мониторинга. Он должен не просто обращаться к адресу гейтвея, а отправлять настоящий запрос выбранной модели и проверять её ответ. Так в Statuser появился мониторинг ИИ-моделей.

— Есть Grafana.
— Есть n8n.
— Есть Dockge.
— Есть несколько внутренних админок и staging‑сайтов.

У каждого из них уже есть собственная авторизация. Казалось бы, что ещё нужно?

Но меня долго смущала одна простая вещь: почему форму логина вообще должен видеть весь интернет?

Привет, Хабр. 26 августа 2024 года я получил у BotFather первый токен и написал кривой телеграм‑бот с одной моделью — обычная история «хочу ChatGPT без танцев с бубном, сделаю себе сам». Бот был честно плохой: одна модель, никакого контекста, падал от длинных сообщений. Но он работал, им начали пользоваться дети и знакомые, и я решил «немного доделать».

«Немного доделать» продолжается второй год. Сейчас это платформа с веб‑приложением, шестью каналами доставки (Telegram, VK, MAX, Discord, веб и — для уведомлений и результатов долгих задач — email), биллингом, голосовым агентом и RAG по документам. А под ней — 66 контейнеров на двух нодах, BGP‑маршрутизация, собственный CI, хелпдеск и GPU‑нода с локальными моделями. Всё на железе, которое стоит под столом и потребляло меньше, чем игровая приставка, — до недавнего появления второй ноды с 3090; теперь приставка нервно курит. Эта статья — про то, во что превращается домашняя инфраструктура, когда backend‑разработчик два года не может остановиться.

Пишу это по двум причинам. Во‑первых, когда я начинал, мне отчаянно не хватало такой статьи — целостной картины, как это выглядит, когда селф‑хостишь ВСЁ. Во‑вторых, я почти наверняка делаю что‑то не так, и комментарии Хабра — самый быстрый способ об этом узнать. Не стесняйтесь.

Иногда самый опасный баг в CI/CD — тот, который не меняет цвет сборки. Jenkins продолжает показывать зелёный статус, а внутри уже формируется неверный результат: переменная превращается в null, ошибка маскируется под успешное выполнение, а метрики начинают показывать искаженную картину. Разбираем реальные места, где пайплайн может незаметно врать, и способы сделать его честнее.

Меня зовут Стас Погоржельский, я технологический евангелист VK Cloud и последние месяцы гоняю Prometheus и VictoriaMetrics на одном стенде, чтобы понять, сколько на самом деле стоит одна точка метрики на диске.

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

Когда место под метрики кончается, первым на планёрке звучит «сменим движок». Публичные бенчмарки подталкивают к тому же: Флант показывает, что Prom++, форк Prometheus, тратит памяти в 7,8 раза меньше Prometheus v2 (разбор на Habr), VictoriaMetrics показывает трёхкратную экономию диска против Grafana Mimir (бенчмарк VictoriaMetrics, замер вендора, 2022 год).

На моём стенде картина оказалась сложнее. В Prometheus 3.13 и VictoriaMetrics 1.149 ушёл один и тот же набор: 2,88 млн сэмплов, шесть профилей данных, один генератор с фиксированным seed. Внутри одного движка цена сэмпла различалась в 139 раз у VictoriaMetrics и в 12,8 раза у Prometheus. Между движками на одних данных разрыв доходил до 30,7 раза на шести профилях и до 34,3 раза в опыте с точностью. На равномерно случайных float64 движки менялись местами. Один лишний знак после запятой поднимал цену сэмпла у Prometheus в восемь раз, у VictoriaMetrics на 12%.

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

До версии 1.31.5 для этого применяли тяжелые скрипты (медленно) и лабиринты из редиректов (неудобно). Теперь можно создать блоки location на базе любой переменной. В этом блоге разбираем методики чтения запроса и показываем примеры паттернов конфигурирования NGINX, которые вы можете применять для любого API или AI-трафика.

Три часа ночи, воскресенье. «Пачка» уведомлений от системы мониторинга в почте и Telegram. Mission‑critical система «лежит», потому что истёк TLS‑сертификат, который упустили из вида и не включили в «эксельный» реестр.

Ситуация знакома? Тогда эта статья для вас. Разберём, почему вопросы управления цифровыми сертификатами резко обострились, какие классы решений есть на рынке, и почему «просто поставить cert‑manager» — это не всегда финал истории.

У нас в публичном облаке VK Cloud у каждого бакета Object Storage есть Bucket Access Policy. Это набор правил в формате JSON, который лежит на самом бакете и говорит, кому какие операции с какими объектами разрешены. Хранилище проверяет эти правила само на каждый запрос. Включается политика в личном кабинете и через S3 API, и я регулярно вижу проекты, где её не настраивали ни разу.

В статье разбираю состав бакет-политики, её отличия от AWS-руководства и что задавать областью действия ключа, а что политикой. Дальше три механизма проверки на endpoint и порядок между ними, перенос политики из AWS-руководства как есть с разбором, почему он не работает, и четыре итерации доводки (Resource, Principal, aws:SourceIp, явный Deny). Затем матрица из 16 запросов с ожидаемыми кодами и скрипт прогона, метрика доли отказов по Cloud Audit, регуляторика, чек-лист переноса между AWS S3, Ceph, MinIO и VK Object Storage.

Пригодится тем, кто держит прокси перед хранилищем и хочет перенести правила доступа в само хранилище, и специалистам по ИБ, которым нужно доказать разграничение доступа выгрузкой, а не скриншотом консоли. Для другого S3-совместимого хранилища применима основная часть: механика проверки и матрица тестов от платформы не зависят.

Привет, Хабр! На связи команда разработки Just AI. Хотим рассказать, как мы автоматизировали часть рутинных задач вокруг разработки с помощью LLM-агента. Не генерацию функций и не написание кода — нас интересовало то, что происходит с задачей до и после написания кода: создание merge request, сборка, обновление Jira, передача задачи на тестирование и другие повторяющиеся действия.

На небольшой задаче таких шагов набирается около десяти. Нужно помнить порядок действий, договоренности команды и постоянно переключаться между разными инструментами. Мы решили передать эту рутину агенту: описали правила команды текстовыми инструкциями и подключили инструменты для работы с Jira, GitLab, Jenkins и Sentry.

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

Привет, Хабр! Была одна вещь, которая давно (примерно 3 дня) не давала мне покоя в Sheeternetes. Весь смысл проекта — «таблица и есть кластер»: Deployments, Nodes, Pods живут во вкладках, таблица — источник истины. Вот только в первых версиях мы покривили душой и шли против истины. Планировщик — та самая часть, что решает, какой под на какую ноду поедет, — был Python-функцией, которая читала таблицу снаружи. То есть таблица хранила состояние, а думал Python.

Это жульничество, и оно меня грызло (на самом деле нет, это клод так придумал). Поэтому я решил убрать последний внешний мозг: переписать планировщик как формулу таблицы. Без Python, без Apps Script, без bash. Одна =LET(…) на под, которая читает вкладку Nodes и решает, куда его поставить, — пользуясь только тем, что встроено в Google Sheets.

И оно работает. Воспроизводит bin-packing, capacity, spread, sticky placement, cordon, affinity и taints — и выдаёт ровно ту же раскладку, что и настоящий Python-планировщик, на всех девяти его юнит-тестах.

В Kubernetes-кластере рано или поздно встаёт вопрос: где собирать Docker image приложений? Вариант «на своей машине разработчика» не масштабируется на команду. Вынос сборок на отдельную виртуальную машину решает эту проблему, но создаёт накладные расходы на обслуживание инфраструктуры и лишает ключевых преимуществ k8s: отдельная ВМ не масштабируется горизонтально под нагрузку, параллельные джобы конкурируют за общие CPU, RAM и диск, а накапливающийся кэш требует регулярной очистки.

Kubernetes executor с Kaniko, BuildKit или Buildah лишён этих недостатков: сборка происходит в изолированных подах прямо на нодах кластера, ресурсы динамически масштабируются, а виртуальные машины для Docker-демона больше не требуются.

Раскатка обновлений INTEKEY WMS больше не зависит от того, у кого сегодня открыт SSH и кто помнит, какая сборка где стоит. Мы создали оркестратор, который берёт на себя весь цикл: сборку, проверки, раскатку по стендам, точки отката и отчётность. Ниже как он устроен.

ИИ уже умеет генерировать Ansible-плейбуки, собирать роли, искать ошибки и помогать с рефакторингом. Но между «модель написала YAML» и «это можно пускать в прод» всё ещё лежит несколько обязательных проверок.

Разбираемся, как использовать Claude, ChatGPT, Copilot и другие ИИ-инструменты для работы с Ansible: как составлять промпты, проверять синтаксис и идемпотентность, работать с секретами и не превращать ускорение разработки в новый источник инцидентов.