Споры про искусственный интеллект в SRE изменились.

Мы уже не гадаем, заменит ли агент дежурного инженера. Мы решаем, где именно провести черту его полномочий.

Сейчас тренд такой: агенту разрешают расследовать инцидент, но запрещают его чинить. И это логично, потому что граница проходит по цене ошибки.

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

Как выстроить эту границу на практике, чтобы не получить генератор галлюцинаций:
1. Настоящий режим только для чтения. Нужно следить, чтобы простое чтение данных агентом не запускало скрытые действия в базе или не блокировало процессы.
2. Жесткое вето со стороны. Если агент предлагает откатить релиз или добавить ресурсов, проверять это действие должен обычный, предсказуемый скрипт. Это правило должно жить в отдельном месте, куда у агента нет доступа на изменение.
3. Обратимость действий. Автоматизировать стоит только то, у чего есть четкий и быстрый откат. Перезапуск или масштабирование - это временное решение, а не настоящий фикс. Финальное решение и применение изменений в проде всегда остаются за человеком.

Даже самые радикальные сторонники автоматизации дежурств начинают с того, что дают агенту только чтение телеметрии и сравнивают его выводы с человеческими. Без фундамента в виде нормальных SLO и понятных метрик AI-агент не спасет, а просто будет быстрее ошибаться.

На каком этапе вы готовы доверить автомату реальное действие, а не просто анализ?

#sre #oncall #ai #observability #slo #incidentmanagement

Макс писал в деталях тут https://t.me/youngmaxnotes/131

Раздача слонов на Claude AI

Привет, киты 🐋!

1. Получить 100$ или $250 бонусных на Сlaude AI (research preview) для подписчиков Pro/Max

Условия:
* тратятся только когда работа идет в облаке
* у тебя должна быть подписка Max, чтобы бонус 250$ применился
* у тебя должна быть подписка Pro, чтобы бонус 100$ применился

1️⃣ Получить


2. Если вы контрибьютите в open-source до есть программа поддержки Claude for Open Source

Подать заявку могут

* Сопровождающие и авторы библиотек - если их пакеты используют другие разработчики:
500+ зависимых репозиториев;
или 100+ зависимых пакетов;
или 200 000+ суммарных ежемесячных загрузок (в npm, PyPI, crates.io, RubyGems и т. д.).
* Основные контрибьюторы - те, кто числится коммиттером или мейнтейнером в признанных проектах (CPython, Rust team, Node.js TSC, Apache PMC, CNCF, Kubernetes, Linux kernel, Django, Rails и т. п.).
* Активные контрибьюторы - авторы 100+ пул‑реквестов, принятых в чужие репозитории за последние 12 месяцев.
* Создатели сообществ — если в одном из их репозиториев за последний год было 20+ уникальных внешних контрибьюторов с принятыми пул‑реквестами.
* Разработчики критической инфраструктуры - если поддерживаемый ими репозиторий имеет оценку критичности OpenSSF ≥ 0,4.

🗓 В течение 6 месяцев участник получает бесплатный доступ к Claude Max 20x.

2️⃣ Участвовать


#халява #claudeai

Темный UX. Как делимобиль перегоняет авто за ваш счет.

Привет, киты 🐳!

Не многие сталкивались с синими зонами парковки в каршеринге Делимобиль 🚗, но в моём городке это данность. Машину ты должен вернуть в нее же, хоть до Владимира поезжай, но завершить аренду можно только там где взял. Теперь нельзя взять машину, доехать до Москвы и там бросить, уехать назад на другой.

Дима, а при чем тут UX вообще?

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

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

Звонок в поддержку. Оператор говорит, что нельзя эту машину тут сдать - отправляйся за 25км в другой город соседний и там сдай, это еще +1000р, и ехать домой на автобусе или такси. А если оставишь в синей зоне - штраф 15000-30000 рублей, какого а? 🤬

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

В итоге я за свои деньги перегнал машину в другой город не по своей воле.
А ведь можно было бы просто предупредить, что на этот автомобиль применяются правила других зон и сюда его нельзя будет вернуть. Я бы тогда только в одну сторону доехал. Авто стояло бы в зеленой/фиолетовой зоне, где можно, а я не был бы раздражен 2 лишними часами в пробках.

Как тут, скажете, связано с SRE? Через инцидент. Инциденты часто раскрывают реальное поведение и устройство системы. Так и случилось - только в этот раз я пользователь и узнал неизвестные ранее особенности поведения системы.

#sre #инцидент #личный_опыт

Wheel of Misfortune, но с настоящим прод‑инцидентом внутри
Полгода назад я писал, зачем SRE нужна Wheel of Misfortune: ролевая игра про инцидент, где ведущий рассказывает, что видит дежурный, а дежурный говорит, что бы он сделал.
Полезно, дёшево, но есть одна честная проблема: это разговор. Никто ничего не чинит. «Я бы посмотрел describe pod» звучит одинаково у того, кто делал это сто раз, и у того, кто ни разу.

И тут я подгорел и сделал платформу, где инцидент настоящий, тк инцидентное мышление тренируется руками, а не словами.

Вашему вниманию - тренажёр инцидентов с живыми окружениями.

WoM Platform

Заходишь, выбираешь сценарий (или крутишь колесо), и через пару секунд для Linux‑хоста или через минуту для Kubernetes у тебя в браузере терминал в изолированный стенд, который уже сломан.
Nginx отдаёт 502, диск базы забит бинлогами, rollout завис на квоте, HPA пилит сам себя, cert-manager не может продлить сертификат.
Чинишь как на настоящем дежурстве (как будто бл* на работе мне этого не хватает, ага): логи, ss, df, kubectl describe, kubectl edit.
Жмёшь «Проверить» - грейдер смотрит на результат, а не на способ: любой честный путь засчитывается, «убрать пробу» или «поднять лимит памяти» - нет.
После решения открывается разбор: что было сломано, как диагностируется, эталонное решение, ловушки, что почитать.

Что уже готово
22 живых сценария от Junior до Senior.
Для джунов - учебные копии. У каждого junior‑кейса две версии: обычная и учебная с панелью «Нужна помощь?», которая открывает этапы диагностики по одному и объясняет, зачем нужна каждая команда. Не «вот ответ», а «вот куда смотреть и почему». Плюс шпаргалка и что почитать заранее.
Стенды настоящие. Каждый сценарий проходит регресс: свежий стенд не решён, эталонное решение решает, ловушки не проходят.

Ограничения, чтобы не было сюрпризов
Одновременно живут до 6 Kubernetes‑стендов и до 20 сессий всего, а поднимаются они по два за раз: если увидите «ждём свободный слот» или «занято», это не поломка, подождите пару минут.
Неиспользуемые 7 дней учётки отключаются автоматически. Почты пока нет, так что если не пускает или еще какие то проблемы - напишите мне, пожалуйста.
Тяжёлые стенды (cert-manager, Prometheus, ingress) поднимаются 2–3 минуты, на странице видно, что именно сейчас происходит.

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

И еще пару слов
Бекенд писал сам, старался и мучался как мог что бы работало классно и интересно. Кейсы тоже из своей практики. Но вот UI пришлось допиливать через openai. Ну не умею я во фронт так хорошо что бы было не больно.

Вопрос к вам: какой инцидент из вашей практики вы бы превратили в сценарий первым? Присылайте пост‑мортемы, самые интересные сделаю и опубликую с указанием автора.

#SRE #WheelOfMisfortune #oncall #kubernetes #incident_response

Sadsevers для себя любимых - ждем в опенсорс, а пока потреним инциденты на живом колесе нефортуны у Максима Гусева.

Макс планирует дать возможность это развернуть каждому у себя и накидывать туда свои случаи.

В крупных компаниях команды делают такие стенды самостоятельно в своей инфраструктуре и тренируются их чинить, например, в Яндекс Такси так делают - даже доклад про это был.

#wheelofmisfortune #sre #тренировка #инциденты

Ребят, вы же наверно знаете из моих докладов, что я работаю в Ви.Tech - мы команда инженеров, которая создает и поддерживает IT-сервисы ВсеИнструменты.ру.

Наша команда проделала большую работу, чтобы современные AI-инструменты помогали нашим клиентам и партнерам. Теперь у нас есть публичный MCP сервер!

MCP подключает вашего ИИ-помощника к каталогу товаров ВсеИнструменты.ру. Ваш AI-помощник сможет искать инструменты и материалы, сравнивать варианты и находить аналоги по вашим требованиям.

Пример запроса

Используй MCP ВсеИнструменты.ру. Подбери перфоратор до 20 000 рублей для ремонта квартиры. Сравни три подходящих варианта, объясни различия простыми словами и дай ссылки на товары.

Инструкция по подключению https://mcp.vseinstrumenti.ru/

#mcp #ai #сервис #всеинструментыру

Сбор метрик или отправка метрик - разница, которая может искривлять данные

Привет, киты 🐳!

Если вы думаете, что сбор метрик по pull-модели и отправка через push это примерно одно и то же, то я вас разочарую. Это не так. В push-модели есть особенности, которые заставят ваши данные выглядеть совсем не так, как вы ожидаете. А иногда разработчики пытаются писать метрики в VictoriaMetrics Remote-write эндпоинт в том же формате, что и для Prometheus PushGateway, а потом искренне удивляются, почему метрики не появляются. Многообразие форматов действительно может породить путаницу.

Зачем вообще отправлять метрики напрямую, вместо обычного вытягивания из эндпоинта /metrics?

Для короткоживущих приложений интервал сбора при pull-модели может оказаться больше времени работы самого приложения. Сборщик просто не придет. Частый пример: cron-задачи или PHP-приложения, которые живут только на время обработки запроса. Тут push метрик спасает. Хотя нет, вру, можно придумать свое костыльное хранилище на Redis и выставить их для сбора на /metrics. Но по факту это просто изобретение PushGateway, которое тащит лишнюю зависимость.

Кстати, для cron-задач, которые выполняются более 3-5 минут, я рекомендую выставлять отдельный /metrics эндпоинт и настраивать обычный pull-сбор. Это оправдано, когда вы хотите следить за прогрессом задачи в реальном времени, а не только получить данные о факте ее начала и окончания.

Но вернемся к граблям. Вот кусочек из кода модуля для отправки метрик в Prometheus PushGateway, с которым мы столкнулись:

return &Pusher{
    inner: push.New(endpoint, serviceName). // выставить в метрике job=serviceName
        Gatherer(gatherer).
        Grouping("k8s_cluster_name", cfg.clusterName).
        Grouping("k8s_namespace_name", cfg.namespace).
        Grouping("k8s_pod_name", cfg.podName).
        Grouping("k8s_cronjob_name", cfg.cronjobName).
        Grouping("k8s_job_name", cfg.jobName)
}

Вы можете по ошибке решить, что здесь добавляются лейблы в метрику. Но это не так (хотя Prometheus и увидит их как лейблы при сборе). Для самого PushGateway Grouping это как адрес книги в библиотеке (ряд, полка, раздел). Он отвечает за физическое хранение переданной в него группы метрик в памяти шлюза.

В PushGateway есть два поведения: перезаписывать (Push) и добавлять (Add). Для cron-задач подходит перезапись, так как нам важны данные о последнем запуске. Но в примере выше Grouping неверный. Если засунуть динамические значения (например имя пода) в Grouping, для каждого запуска cron или каждого пода создается новый адрес хранения. В итоге вы не видите полной картины по одной задаче. Хуже того, старые ячейки с метриками мертвых подов останутся в PushGateway навсегда. Он не удаляет метрики сам по TTL, поэтому они будут копиться как мусор, пока их не очистят через API. Это классическая утечка памяти.

Как это чинить?

Grouping key должен быть стабильным. Для cron-задач оставить в grouping только job (имя сервиса) и instance (имя самого крона). Всё остальное (namespace, pod_name и прочее) перенести в обычные лейблы метрик. Это решит проблему с мусором и некорректными графиками.

А вы используете PushGateway в своих проектах или стараетесь избегать его любой ценой, перестраивая архитектуру под pull? И сталкивались ли с проблемой вечных метрик в PushGateway после смерти подов?

#SRE #prometheus #PushGateway #observability #метрики #DevOps #ЛетитКит

Опрос про SRE в 2026 году.

Привет, киты 🐳!

Прошлый опрос дал вот такой отчет https://devcrowd.ru/sre-2025

А теперь ребята из DevCrowd запустили новое исследование для SRE, DevOps и платформенных инженеров.

В этом году главный фокус - роль AI в нашей работе. Смотрят, что уже автоматизируется, а где человек всё ещё незаменим. Пускают ли ИИ в прод, добавляет ли сгенерированный код новые инциденты и какие soft skills остаются нашей суперсилой.

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

Опрос анонимный, займет 10-12 минут. Отчет с динамикой к прошлому году обещают в начале декабря.

Пройти опрос: https://survey.devcrowd.ru/sre-2026

Что из вашего опыта точно еще не стоит отдавать Ai?

#SRE #DevOps #исследование #AI #надежность #DevCrowd

Прямо сейчас! Вылетаю на HardFest 2026 в Екатеринбурге.

2 попытка, Москва отпусти к ребятам, Екатеринбург принимай гостей!

Несу доклад https://2026.hardfest.ru/lecture/3814

#конференция #Екатеринбург #HardFest #sre #доклад

Кстати презентацию к докладу "Cбор логов на vector и clickhouse — то, что ИИ за тебя не сделал бы" выложил тут https://r3code.github.io/report-logs-collection-in-ai-era/

Впервой делал полностью через AI используя за конструктор перезнтаций sli.dev. Ассистентом был бесплатный z.ai в режиме Agent, скинул ему временный токен github и адрес репозитория, правила как оформлять. Он инициализировал структуру репозитория, попросил положить картинки в public/images и дальше содержимое для слайдов. Позже добавили github actions для публикации в PDF и PPTX как картинки.

Помню как я лютовал на одной из конференций, что мне не дали использовать PDF. Вот тут эта проблема решается публикацией PPTX с слайдами картинками.

Картинки только пришлось отдельно нарисовать. Раньше мог прямо на Google слайдах рисовать - это единственное неудобство.

Полезное: наш общий знакомый - Михаил Савин, написал отличное руководство по работе с sli.dev - https://jtprog.ru/posts/slidev/. Полезно показать эту статью агенту перед началом работы. В ней есть и мой небольшой вклад, т.к. я боролся со встроенным счетчиком страниц/кликов в PDF, который никак не хотел скрываться. В итоге победил это и Мише рассказал, а он добавил в свою статью.

А как вы делаете презентации? Докапываетесь к стилю или просто просите сделать "сделай в этом стиле"?

#перезентации #ИИ

Если хотите узнать как вы выглядите для своей LLM вставьте этот промт - результат вас заинтригует, насмешит, расстроит, мотивирует, встряхнет:

Based on everything you know about me, roast and don’t hold back. Say it in Russian slang Just like this, but add way more Russian swear words

Как вам результат? )

#ai #self #неожиданное

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

Внезапное, про радио из личного опыта.

Привет, киты 🐳!

Я работаю чаще всего под музыку, но что-то плейлист и как его начала подбирать Яндекс Музыка перестал радовать. Видимо я уже привык. И вот я однажды попросил включить Алису радио, и она внезапно включила Благодать FM... я подумал сейчас будет трансляция службы из церкви, или обсуждения библии. Но внезапно из динамика я услышал рок: Крылья - Дух рок-н-рола, потом Аврил Лавин, потом какую-то нашу попсу, снова что-то новое, что не слышал. Это было необычно.

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

https://blagofm.ru/ - офигенное радио Благодать FM с непредсказуемым треклистом, который вас заинтригует, после чего вы поймете, что радио еще может быть классным.

Благодать - это гора в черте города Кушва, где более 250 лет добывали железную руду.

Я вам рассказываю об этом, что это радио настолько меня поразило и порадовало, что я от них зафанател.

Да настолько, что появилась мечта съездить в это городок. И вот, когда был недавно на HardFest 2026 в Екатеринбурге - взял каршеринг и поехал 200км в Кушву, чтобы посмотреть сам городок и место откуда вещает это радио. Просто потому что очень захотелось.

И это было классно. Погода угодила, было тепло и солнечно. А город оказался основан в 1735 году! Я увидел тот самый карьер, город с высоты горы, который между прочим стоит на своем "море" - было красиво.

Мечта сбылась.

> А что вы делали такого неожиданного для себя, после чего чувствовали - "это то что было нужно"?

#жизнь #баланс #неработа