Пятничный деплой

Toil в работе SRE. Измерять, или "мы и так знаем что работы дофига“? Привет, киты 🐳. Поразмышляем. Коротко про базу, чтобы синхронизировать понятия. Что такое Toil? По определению Google SRE, toil - это операционная работа, которая: - ручная и повторяющаяся - автоматизируемая - реактивная, а не стратегическая - не создает долгосрочной ценности - масштабируется линейно с ростом сервиса Toil и технический долг - одно и то же? Нет. Технический долг - это компромиссы в архитектуре/коде, которые усложняют будущие изменения. Toil - это операционные затраты на поддержку системы. Часто техдолг генерирует toil, но это разные категории. Погашение долга - engineering work, ручное обслуживание последствий - toil. Плановые задачи vs задачи дежурства. Что из этого toil? Не инструмент и не источник задачи определяют суть, а её характер: - "Раз в неделю вручную чистить логи на 50 нодах" из беклога - toil. - "Написать оператор для авто-очистки" - engineering. - "Дайте доступ", "Почему не деплоится", "Перезапустите под" из дежурства - классический toil, особенно если повторяется. Как понять, что пора автоматизировать? 1. Замерить. Без цифр всё субъективно. 2. Оценить ROI: время на разработку автоматизации vs время, которое она сэкономит. 3. Начать с простого: структурированный запрос -> бот -> подсказка или маршрутизация. Именно так мы сейчас делаем: бот отвечает на частые вопросы разработчиков и зовет нужного специалиста (DevOps/SRE/DBA) в зависимости от контекста. Это классический первый шаг который предлагает Google. Целевой toil ratio для SRE-команды по гайдлайнам Google - не более 50%. Остальное инженерная работа - проекты, которые уменьшают будущую рутину и повышают надежность. 🥸 Измеряете toil ratio у себя? Если нет - что мешает начать: отсутствие метрик, времени или просто неочевидна ценность? #SRE #Toil #Автоматизация #ИнцидентМенеджмент #ЛетитКит #SLO

Ваши разрабы не хотят разгребать легаси и рефакторить кронтаски в отдельный scheduler с очередью? У вас есть сотни кронтасок в проде, которые вы хотите таки контролировать в контейнерах? У вас айсикью выше 70, раз вы все еще не описали каждую строку crontab в отдельном Kubernetes ресурсе (Job/Cronjob)? тут уже говорили про недостатки крона Supercronic пытается решить некоторые из них: кронтаски наследуют переменные окружения, выводит логи в stderr, логирует запуски результат выполнения и ошибки, посылает SIGTERM/SIGINT и что-то там еще.

Supercronic is a crontab-compatible job runner, designed specifically to run in containers.

Legacy не убить!

https://github.com/mezmo/aura смотрите какая штуковина

OWASP выпустили Agent Memory Guard, защиту от одной из самых неприятных атак на AI-агентов: отравления памяти. Проблема в том, что агент может сохранить вредоносную инструкцию в долгосрочную память, а потом продолжить выполнять её даже после очистки контекста. Обычные prompt injection-фильтры здесь уже не особо помогают. Agent Memory Guard ставится между агентом и хранилищем памяти и проверяет каждую запись. Он умеет ловить prompt injection, утечки секретов и PII, попытки изменить защищённые ключи, аномально большие записи и циклы, когда агент начинает сам усиливать уже записанную вредоносную инструкцию. Политики задаются через YAML, а подозрительную запись можно пропустить, замаскировать, отправить в карантин или полностью заблокировать. Есть снапшоты и rollback для восстановления памяти после атаки. В опубликованном бенчмарке на 55 вредоносных payload'ах проект показывает 92,5% detection rate, 100% precision и медианную задержку всего 59 мкс. GitHub: https://github.com/OWASP/www-project-agent-memory-guard

Агенту разрешают расследовать, но не разрешают чинить. Почему граница именно здесь???? В ноябре я писал про SRE Agent от PagerDuty: начинайте с read-only. Прошло десять месяцев, и спор сместился: уже не «заменит ли AI дежурного», а «где проходит граница». 24 августа в r/sre инженер после полугода on-call заметил одно и то же во всех обзорах AI SRE-инструментов: расследовать агенту дают одному, чинить - никто. Это навсегда? Что говорят цифры ORCA-bench, 30 июля, Cornell Tech, Columbia и Traversal (последние продают AI SRE-агента, держите в уме). Стенд: 19 микросервисов на OpenTelemetry, шесть дней телеметрии в Prometheus, Jaeger и OpenSearch, доступ к коду, 1 079 задач на root cause, пять фронтирных моделей. Лучшая точность RCA на задачах средней сложности (реалистичный ввод) - 25,3%, на сложных - 10,0%, разрыв сохраняется даже с Claude Fable 5. Слабейшая модель выдумывает неправдоподобную причину в 40% отчётов. Типичная ошибка: хватается за заметный симптом ниже по потоку вместо причины выше. Авторы называют это нижней границей: прод больше и грязнее стенда. Комментатор в треде сформулировал точно: плохой анализ в худшем случае тратит ваше время, запись в прод без человека - катастрофа. Граница проходит по цене ошибки. NeatContext в июле выключили автономного агента с доступом к логам: таймаут платёжного шлюза он связал со всплеском коннектов к БД двенадцатью часами раньше, через RAG унаследовал устаревший runbook и не умел сказать «не знаю». «Получили уверенный генератор галлюцинаций». Они продают свой инструмент, но симптомы знакомые. Как границу строят руками 1. Read-only, который действительно read-only. HyperProbe (Launch HN, 5 августа) даёт агентам ставить виртуальные пробы в работающий процесс. Главный вопрос треда: чем «только чтение» гарантия, а не договорённость? В Python чтение атрибута может дёрнуть @property с ленивой загрузкой из БД, в Java геттер - взять лок. Ответ: условия без вызовов методов и доступа к свойствам (order.total > 5 нельзя, total > 50 можно) плюс бюджеты. 2. Вето вне агента. В r/kubernetes: LLM предлагает scale, rollback, cordon, drain, а детерминированный Safety Engine без LLM проверяет действие по живому состоянию API. Комментарии: вето должно жить там, где агент не может исполнять код (отдельный процесс, admission webhook), иначе «вы построили второе мнение, а не вето»; оно должно быть stateful (бюджет blast radius, cooldown, проверка результата) и перепроверять состояние прямо перед мутацией. 3. Обратимость как критерий. Security patching автоматизировали, потому что у каждого действия известен откат. Rollback, scale, restart - митигации, а не фиксы. Команды на GitOps уже пускают агентов открывать PR («большинство RCA были верными»), но мержить и катить - человек. Mezmo выложили в open source AURA : их SRE-команда упёрлась в переполнение контекста, галлюцинации и approval fatigue и «провела жёсткую черту: права в проде не ослабляем». Инструменты проверяются вне контекста агента, approval через webhook, по таймауту - fail-closed. Другой полюс Boris Tane (ex-Baselime и Cloudflare, теперь строит Polylane: «никто не должен дежурить в 2026») 21 августа опубликовал On-Call Is Now Theatre: дежурство - признание поражения, если пейджить агента бесплатно, алертов нужно радикально больше, а единственный валидный результат расследования - diff. Он продаёт это будущее. Но даже его рецепт на первую неделю - дать агенту read-доступ к телеметрии на самом шумном алерте и две недели сравнивать его triage с людьми. То есть read-only. Что я из этого я бы точно себе забрал? Граница - не вопрос доверия, а отсутствие того, что в треде назвали bounded authority: система должна знать, что ей можно, при каких доказательствах и когда нужен второй approve. Без базы из ноябрьского поста (SLO, связная телеметрия, живые runbook'и) агент просто быстрее ошибается. И измеряйте: прогоните агента по своим постмортемам и посчитайте долю неверных вердиктов. Вопрос к вам: что вашему агенту уже разрешено делать в проде без человека? И кто это разрешил - policy или привычка? #sre #oncall #ai #incidentresponse #observability

Забираем локальную память для ИИ-агентов - myc не даст Claude Code забыть, что вы с ним решили, даже когда контекст уже сжали. Работает без сети и без ключей, в одном файле рядом с проектом: • пакет контекста собирается за 0,6 мс; • поиск по 100 000 записей - за 8 мс; • решения из переписки не считаются фактами, пока вы их не подтвердите. Подхватывает Claude Code, Codex, opencode и Kimi одной командой, а между машинами переезжает через обычный git. Только Bun, автор из Питера, проекту неделя. Забираем - лежит тут.

Спасибо подписчикам за то что приносите интересные проекты!

🐳 Docker выпустила Sandboxes - изолированные среды специально для AI coding agents. Идея простая: дать агентам вроде Claude Code, Codex, Gemini CLI, Copilot CLI, OpenCode и Kiro больше свободы, но не давать им свободно ломать хост-систему. Каждый агент запускается в отдельной microVM и получает только рабочую директорию проекта. Внутри он может: - устанавливать пакеты; - менять конфиги; - запускать сервисы; - поднимать собственные Docker-контейнеры; - выполнять долгие задачи без постоянного подтверждения действий. При этом Docker позволяет отдельно контролировать filesystem, network и credentials, а сам sandbox после работы можно просто удалить. Это инфраструктурный слой для эпохи автономных coding agents: агенту дают почти полный контроль внутри песочницы, но хост остаётся изолированным. https://www.docker.com/products/docker-sandboxes/ #Docker #AI #AIAgents #DevOps #Programming

Как AWS у опенсорсера пакеты отжимал Нерегулярная рубрика "посмотрите, что творится!". Данная история была в оригинале рассказана Кареном в нашем чате (там регулярно происходит интересное), публикую в своем канале с его разрешения. Новый SDK для AWS от Карена (автора zapros, автора httpx-aiohttp, топ-3 контрибьютора httpx): https://github.com/kap-sh/capo

Как-то я решил написать нормальный SDK для AWS. Их текущий SDK — boto3 — это суперлегаси с кучей костылей: без нормальной типизации, без поддержки асинхронности, почему-то с PascalCase и ещё кучей странных решений. У меня уже был хороший опыт работы с SDK: до этого я работал над SDK для OpenAI и Anthropic на Python и TypeScript, так что успел накопить некоторое понимание того, как делать SDK хорошо. С AWS всё немного сложнее: у них около 450 сервисов и примерно 17 миллионов строк сгенерированного кода. Конечно, я не собирался писать всё это вручную. Вместо этого я пишу кодогенератор, который генерирует SDK из спецификаций Smithy (язык и тулинг для спецификаций). Примерно такой же подход я использовал, работая над SDK для OpenAI и Anthropic. И, конечно, я не стал делать это одним пакетом на PyPI. Прикиньте, устанавливать 17 миллионов строк кода только для того, чтобы создать S3-бакет. Поэтому я делаю отдельный пакет для каждого сервиса. Для всех пакетов я выбрал префикс aws-sdk: aws-sdk-s3, aws-sdk-ecs и так далее. Успешно опубликовал около 60 сервисов на PyPI. А на следующий день до меня достучались ребята из AWS. Они заметили мою работу, пореспектовали, но сказали, что именно эти имена они сами давно хотели использовать для своего нового SDK — замены boto3. И попросили вернуть им эти имена. И тут есть ещё одно интересное совпадение: в тот же день PyPI заморозил мой аккаунт. В заморозке он продержался больше месяца. Причины мне так и не объяснили, но, думаю, каждый может сделать свои выводы 🙂 Я не стал с ними бороться и согласился вернуть имена.

Что интересно в данном контексте? 1. Существует PEP, который определяет разрешение конфликтов в пакетах: https://peps.python.org/pep-0541 Там есть пункт о том, что если пакет "нарушает торговую марку", то он может быть отозван как "некорректный". Но там есть важная оговорка, что "честное использование" (например для создания SDK) - разрешено 2. AWS являются спонсорами PyPI: https://aws.amazon.com/ru/blogs/opensource/securing-pypi-for-the-future Кстати, история про left-pad начиналась так же. Техническая часть Что удивительно, так то, что сами AWS не могу сделать нормальный SDK для питона. А один человек в опенсорсе - может. Сделать и синхронную, и асинхронные версии - довольно сложно. Вот так оно выглядит у capo:

from capo_s3 import AsyncS3Client

async def main():
    async with AsyncS3Client() as s3:
        response = await s3.create_bucket("capo")
        print(response)

и

from capo_s3 import S3Client

with S3Client() as s3:
    response = s3.create_bucket("capo")
    print(response)

Внутри, конечно же, zapros, как HTTP фреймворк для запросов. Что прикольно: все модели данных построены на TypedDict, все ответы типизированы, но с 0 дополнительных кастов. Но типизация все еще помогает понять, какие ответы от каких сервисов можно использовать как входные данные для других, а где - так сделать будет нельзя. Развязка Карену поступило предложение работы в AWS с релокацией в США (да, после опенсорс проекта), он отказался по личным причинам. Они созвонились с разработчиками оттуда, выразили друг другу уважение (как капо и делают 🌚), обсудили технические решения. Кажется, никто не остался в обиде. Хорошо, что история хорошо закончилась: у нас есть и контент для канала, и новая библиотека, и счастливый финал. Обсуждение: Как вы думаете, что на самом деле там произошло? Почему аккаунт заморозили? Как вы думаете, найм через такой опенсорс - реальность или супер-редкая уникальная история? Насколько сильно вы страдали от boto3? | Поддержать | YouTube | GitHub | Чат |

Вот страшилка на выходных

OpsKnight Центр управления инцидентами с открытым исходным кодом. Весь жизненный цикл инцидента, графики дежурств и страницы состояния — на одной мощной платформе. OpsKnight — это альтернатива с открытым исходным кодом PagerDuty и OpsGenie, разработанная для команд, которые хотят получить полный контроль над своей системой управления инцидентами без затрат на SaaS-сервисы. Репыч на Гитхаб Страница проекта 📱 Telegram | 📲 MAX

argo9s

A K9s-inspired terminal UI for monitoring Argo CD resources in real-time

https://github.com/vvrnv/argo9s

Сколько незаконченных Git-репозиториев лежит у вас на диске? drydock показывает их все в одном терминальном интерфейсе: - где остались незакоммиченные изменения; - какие коммиты ещё не отправлены; - где забыты stash, конфликт или незавершённый rebase; - какие проекты изменились после последнего тега и готовы к новому релизу. Инструмент проверяет не только текущую ветку, поэтому забытая работа в локальной feature-ветке тоже попадёт в список.

brew install yetidevworks/drydock/drydock

# или
cargo install drydock

После установки достаточно запустить:

drydock

Есть фильтры, fuzzy-поиск, JSON-вывод, открытие проекта в редакторе и массовый fetch. Состояние репозиториев обновляется автоматически через файловый watcher. drydock написан на Rust с использованием Ratatui и работает на macOS и Linux. Полезная утилита для разработчиков, у которых папка Projects давно превратилась в кладбище почти законченных идей. GitHub: https://github.com/yetidevworks/drydock

🎙️ На волне DevOps FM! Пятница — отличный повод немного отвлечься от рабочих задач и послушать что-нибудь интересное. В прошлых подборках нас просили больше русскоязычного контента, поэтому собрали три выпуска, которые стоит добавить в список для прослушивания. 🗣 DevOps в 2026: Platform Engineering, AI-агенты и будущее джунов от DevOps Kitchen Talks. Что происходит, когда у вас уже 600 сервисов и 3600 пайплайнов? Обсуждают internal platform, её архитектуру и self-service-возможности для разработчиков, а также границы ответственности platform team. Отдельный фокус — AI-агенты и multi-agent workflows: что происходит, когда автоматизация начинает работать уже не только с инфраструктурой, но и непосредственно с engineering-процессами. 🗣 Kubernetes 2035: кто будет управлять инфраструктурой? от «В SREду на кухне» / AvitoTech. GitOps, Crossplane, автоматизация Kubernetes и развитие абстракций над инфраструктурой. Интересный вопрос выпуска — сколько деталей инфраструктуры разработчику действительно нужно видеть и какие операции со временем можно передать платформе и автоматизации. 🗣 Инфраструктура & MLOps от [I'ML]. Здесь уже про инфраструктуру для ML и AI-систем. Обсуждают ML Platform, Data Platform, вывод моделей в production и особенности эксплуатации AI workloads. Хороший выпуск, чтобы посмотреть, какие привычные DevOps-подходы приходится адаптировать для AI. Желаем приятного прослушивания и дежурств без алертов!🛡 #пятничная_подборка #подкаст #DevOps #PlatformEngineering #AIEngineering

⚡️ KubeGUI - open-source десктопный клиент для Kubernetes с нормальным современным интерфейсом. Позволяет управлять ресурсами кластера без постоянной работы через kubectl: - Deployments, DaemonSets, Pods и CRD - live-обновления ресурсов - встроенный YAML-редактор с валидацией - работа сразу с несколькими кластерами - просмотр логов - shell прямо внутрь workload - port-forwarding - графы NetworkPolicy и RBAC - просмотр Helm-чартов и релизов - on-demand сканирование уязвимостей через Trivy Отдельный плюс - kubectl вообще не обязателен: приложение само работает с Kubernetes API. Под капотом Go + Wails, а интерфейс собран на React, TypeScript и Vite. https://github.com/gerbil/kubegui

Announcing vmestimator: Real-time Cardinality Estimations for VictoriaMetrics and Prometheus А вот и подоспела статья о vmestimator в блоге VM. vmestimator запускается в точке сбора данных, вычисляя кардинальность на основе входящего потока и предоставляя их в виде метрик через /metrics, совместимых с Prometheus, для сбора данных и оповещений. 📱 Telegram | 📲 MAX

CVE-2021-25740 — уязвимость в Kubernetes, которую фактически невозможно полностью исправить патчем (unpatchable), потому что проблема заложена в самой архитектуре Kubernetes. Атакующий с правами на изменение Endpoints или EndpointSlices может перенаправлять трафик туда, куда у него обычно нет доступа. Главная опасность в том, что уязвимость позволяет обходить сетевые ограничения и использовать ingress/load balancer как “confused deputy” — доверенный компонент, который выполняет действия от имени злоумышленника. Это превращает даже ограниченные RBAC-права в потенциальный путь к lateral movement внутри кластера. Авторы статьи делают акцент на том, что защититься можно только организационными мерами: жёстким RBAC, admission controllers и мониторингом изменений Endpoints/Services. Очередной хороший пример того, как некоторые проблемы Kubernetes нельзя «закрыть обновлением» — их приходится учитывать как часть threat model всей платформы.

Cursor выпустили конкурента GitHub – Origin Репозитории с GitHub можно засинкать напрямую за минуту, также можно создавать репозитории с нуля. Основная идея в том, что Origin должен стать гитхабом для агентов. GitHub архитектурно рассчитан на человеческий темп: один разработчик, одна ветка, PR раз в несколько часов. Агенты же пушат постоянно, и под такой сценарий и делается Origin. Для понимания, Cursor демонстрировали 22.6 коммита в секунду в один репозиторий. Пока никаких фичей для автоматического разрешения конфликтов слияния или обработки параллельных агентов нет, сейчас в продукте только база + привычные агенты. Но есть интересные вещи вроде интеграции Vercel: подключаешь к репе, и каждый PR автоматически получает preview-деплой. https://cursor.com/changelog/origin-code-hosting

KEDA как финансовый гардрейл: scale-to-zero, лимиты реплик и автоскейлинг по событиям в Kubernetes В этой статье разбирают KEDA как практический инструмент для Kubernetes-workloads с непостоянной нагрузкой: очередями, расписаниями, HTTP-пиками и внешними метриками. Материал не про «поставили автоскейлер и сразу сэкономили», а про production-подход: где KEDA действительно помогает, какие параметры нужно ограничивать заранее, как проверять экономику пилота и что может пойти не так при раскатке. @usr_bin_linux