🤖 ИИ-агенту теперь можно поставить задачу прямо в GitLab — и не расписывать каждый следующий шаг

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

При этом можно подключать не только готовых агентов, но и собственных — в том числе созданных с помощью Yandex AI Studio. Например, под конкретные задачи разработки или проверки безопасности кода.

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

Для тех, кто работает с Kubernetes и облачной инфраструктурой, в октябре намечается отличный повод выбраться из рабочих чатов и встретиться офлайн 👀

Обсудим:
– как пройти путь от бизнес-требования к ядру Linux
– как дать агенту управление кластером вашей инфраструктуры 
– как в MWS Cloud Platform доставляют системный софт в managed K8s
– мультитенантность в Kubernetes-платформе — «Проект вместо namespace»
– как работает LLM-диагностика инцидентов в Kubernetes и OpenStack

Не обойдётся и без дискуссий: на круглых столах разберём, действительно ли Kubernetes победил и что делать, если из-за ИИ нас всех уволят.

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

📍 Москва, 5-й Донской проезд, 17, Connect
📅 22 октября, 10:00–21:00

👉 Программу, билеты и подробности сможете найти на сайте Kuber Conf от АОТ!

Showboat и Rodney помогают показать работу ИИ-агента

Саймон Уиллисон собирает демонстрации кода с помощью двух своих инструментов. Showboat выполняет команды и записывает их вывод в документ. Rodney управляет Chrome из командной строки и делает скриншоты интерфейса.

uvx showboat --help

Эту команду автор предлагает дать агенту: в справке есть всё необходимое, чтобы тот создал документ с демонстрацией новой функции.

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

#ии #инструменты

Лишние поля логов можно убрать до экспорта

Cloudflare добавила Transformers в Logpush. Это SQL-запрос для конкретного набора логов: WHERE убирает неподходящие записи, SELECT выбирает поля и меняет их содержимое. Отфильтрованный результат уходит в хранилище уже в NDJSON.

Например, можно исключить health-check трафик, привести схему к формату других CDN и замаскировать часть IP. Внутри преобразование выполняет DataFusion на Arrow-батчах, прямо в сервисе доставки. Отдельного сетевого вызова в горячем пути нет.

Но маска IP ещё не делает весь лог анонимным: идентификаторы могут остаться в URL и других полях. Сначала посмотреть preview, затем привязать версию Transformer к совместимому Logpush job с тем же dataset.

Устройство и пример преобразования

#арсенал_инженера

Для простой admission-проверки webhook может быть лишним

Нужно проверить обязательную метку или ограничить число реплик? Прежде чем поднимать отдельный webhook-сервер, посмотрите на CEL-политики Kubernetes. ValidatingAdmissionPolicy выполняет проверку внутри API-сервера, без сетевого обращения к вашему сервису. Эта возможность стабильна с Kubernetes 1.30.

Webhook остаётся полезным для сложной логики, например вызова внешнего API. Но к нему добавляются доступность сервера, тайм-ауты и задержка admission. Mutating webhooks вызываются последовательно, иногда повторно. Validating webhooks работают параллельно.

Для CustomResource базовую валидацию и значения по умолчанию лучше задавать в самой CRD. Выбирать механизм стоит по задаче и версии кластера, а не по привычному шаблону с ещё одним Deployment.

Рекомендации Kubernetes

#архитектура_на_салфетке

PodDisruptionBudget не запретит kubectl delete

Три Ready-реплики, minAvailable: 2. При добровольном выселении через Eviction API бюджет не позволит опустить число доступных Pod ниже двух. На этом механизме основан и обычный kubectl drain.

А прямое удаление Pod или Deployment обходит PDB. Если удалить две реплики вручную, бюджет не превратит этот запрос в отказ. PDB также не предотвращает аппаратный сбой: он ограничивает определённые добровольные disruption, а не гарантирует доступность приложения.

При обслуживании проверяйте не только YAML с minAvailable, но и путь, которым инструмент убирает Pod. Eviction и DELETE похожи по результату, но разные по защите. Контроллер восстановит реплики, однако это не означает, что перерыва не было.

Какие disruption учитывает Kubernetes

#архитектура_на_салфетке

Сначала rate, потом sum

После рестарта реплики на графике RPS появился всплеск? Проверьте порядок операций в PromQL.

rate() считает средний прирост counter в секунду и учитывает его сбросы. Если сначала сложить счётчики разных реплик, информация о сбросе отдельной серии потеряется. Поэтому сначала считаем скорость для каждой серии, затем суммируем:

sum by (job) (
  rate(http_requests_total{job="api-server"}[5m])
)

Это запрос для Prometheus, где уже есть counter http_requests_total с меткой job="api-server". Результат — среднее число запросов в секунду за выбранное окно, суммарно по сериям этого job. Имена метрики и меток подставьте из своей системы.

Окно 5m здесь пример. Его нужно соотнести с интервалом сбора и нужной чувствительностью графика. Для gauge, например текущей занятой памяти, rate() не подходит.

Документация Prometheus

#арсенал_инженера

Почему ожидающий деплой исчез из GitHub Actions

cancel-in-progress: false сохраняет выполняющийся запуск. Но само по себе это не гарантирует, что все ожидающие деплои дойдут до исполнения.

Например, на уровне workflow в GitHub.com задано:

concurrency:
  group: production
  cancel-in-progress: false

В стандартном режиме queue: single у группы один выполняющийся и один ожидающий запуск. A деплоится, B ждёт. Приходит C — и заменяет ожидающий B. Запущенный A при этом продолжает работать.

Если важно сохранить несколько ожидающих запусков, в текущей документации есть другой режим:

concurrency:
  group: production
  queue: max

Так могут ждать до 100 запусков. Когда очередь заполнена, новые отменяются. Сочетание queue: max и cancel-in-progress: true вызовет ошибку валидации workflow.

Есть нюанс и с порядком. FIFO считается по моменту начала ожидания concurrency-группы, а не по времени отправки workflow. Порядок коммитов сам по себе не гарантирует порядок деплоев.

Используйте одну группу для workflow одного репозитория, которые должны делить блокировку. Внешнюю систему деплоя имя production не остановит. Для GitHub Enterprise Server доступность режима нужно сверить с документацией вашей версии.

Как работает concurrency

#арсенал_инженера

Сервис восстановился, а SLO-алерт всё ещё горит

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

В SRE Workbook Google разбирает проверку по двум окнам. Длинное показывает значимый расход error budget, короткое проверяет, продолжаются ли ошибки сейчас.

В примере для SLO 99,9% за 30 дней алерт требует одновременно:

— burn rate выше 14,4 за последний час
— burn rate выше 14,4 за последние 5 минут

Burn rate — скорость расходования бюджета ошибок относительно допустимой. Для этого SLO значение 14,4 соответствует доле ошибок 1,44%. Час с таким расходом — 2% бюджета за 30 дней в расчёте из книги.

Внутри пары нужен AND. Когда показатель за короткое окно опустится ниже порога, условие перестанет выполняться, хотя часовое окно ещё помнит сбой. Если добавляете пары для других скоростей расхода, их объединяют через OR.

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

Разбор и примеры правил в SRE Workbook

#архитектура_на_салфетке

Что сделает systemd с пропущенным ночным запуском

Сервер был выключен ночью, и календарный таймер не запустил задачу. Чтобы при следующей активации таймера наверстать пропуск, у systemd есть Persistent=true.

Пример секции для backup.timer на Linux с systemd:

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=15m

Это только секция таймера. Для выполнения работы нужен отдельный backup.service. По умолчанию таймер активирует сервис с тем же базовым именем.

С Persistent=true systemd хранит время последнего срабатывания на диске. Если в период неактивности таймер должен был сработать хотя бы раз, при активации он вызовет сервис. Но не по разу за каждую пропущенную ночь.

У этой настройки две важные границы:

— она действует только с OnCalendar=. Для OnBootSec= и других монотонных таймеров эффекта нет
— догоняющий запуск тоже учитывает RandomizedDelaySec=. В примере он может дополнительно задержаться на случайный интервал до 15 минут

Точной секунды пример не обещает: у таймера есть ещё AccuracySec=, по умолчанию одна минута.

Параметры systemd.timer

#root_prompt