Встречаемся на ПерфКонф #12? ДА!

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

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

В этом году поговорим о нагрузочном тестировании, оптимизации производительности, DevOps и CI/CD, SRE и Observability, применении ИИ, хаос-инжиниринге и других актуальных задачах.

📍 Москва, Loft Hall на Автозаводской
💻 Также можно участвовать онлайн
🗓 9 сентября 2026 года

А для тех, кто покупает билет как физлицо, есть промокод pk20 — укажите его при оформлении.

Буду рад встретиться, обсудить доклады и поговорить о том, что сейчас происходит в мире высоконагруженных систем. Присоединяйтесь!

До встречи на ПерфКонф #12! 🚀

#ПерфКонф #Performance #SRE #DevOps #НагрузочноеТестирование

Самый опасный деплой 2026 года - тот, который никто не считал деплоем

Залез перечитывать большие постмортемы этого года. Пока мы спорим, пускать ли AI-агента в on-call, три самых громких аутэджа года говорят совсем о другом.

Cloudflare, 20 февраля. Azure, 23 июля. Google Cloud, 20 августа. Три компании, три стека, одна причина: плановая, рутинная, «безопасная» операция, которую выполняла автоматика. Никто не катил релиз. Никто не лез в прод руками. Всё по регламенту.

1. Cloudflare: cleanup с пустым параметром
Задача чистила BYOIP-префиксы, помеченные на удаление. Параметр pending_delete ушёл в API без значения - и сервер вернул вообще все префиксы. Система честно начала удалять их вместе с зависимыми объектами. Из BGP ушли ~1 100 из 4 306 префиксов, четверть. 6 часов 7 минут. Код отработал правильно. Просто вопрос был задан неправильно. Знакомо?
2. Azure West US: blast radius посчитали не так
Рутинный break-fix на сети. Система анализа blast radius из-за дефекта расширила scope на все оптические устройства датацентра. Safety validation тоже отработала и сказала «безопасно»: она проверяла устройства по одному, а не эффект от изоляции всех сразу. Маршруты между ДЦ и WAN исчезли, около 5 часов. Алерты сработали через минуту, а вот связать аномалию с maintenance-триггером смогли только через 2,5 часа. Откат - руками.
3. Google Cloud us-west1: failover не сделал failover
Плановые работы на оптике между ДЦ. Ёмкость просела сильнее ожидаемого, automated rerouting «failed to properly redistribute traffic». Деградация трёх десятков продуктов. 2 часа 22 минуты. В remediation Google обещает «stricter safety checks and circuit redundancy requirements prior to routine maintenance». У Google. Если казалось, что только у вас так - нет.

Что общего
Uptime Institute в Annual Outage Analysis 2026: 92% считают человеческий фактор хотя бы частичной причиной последнего серьёзного сбоя, самая частая форма - failure to follow procedures (59%). 87% говорят, что аутэдж можно было избежать.
Но заметьте: во всех трёх кейсах процедуры были. И им следовали. Проблема в том, что плановые работы и «служебная» автоматика живут вне контура безопасности, который мы построили для деплоев. У релиза есть canary, progressive rollout, откат по SLO, feature flag. У «чистим префиксы» и «изолируем железку» - тикет и окно. Ну и надежда.

Что стоит проверить в любой инфраструктуре
1. Инвентаризация «не-деплоев». Cleanup-джобы, cron по удалению ресурсов, вывод нод из ротации, работы на сети и СХД, миграции DNS. Всё, что меняет прод, - это change. Даже bash по расписанию.
2. Blast radius до, а не после. Cleanup обычно удаляет 5 объектов, а собрался 25% всего? Это должно остановить задачу, а не попасть в постмортем. Cloudflare ровно это и внедряет.
3. Safety-check на совокупность, а не поштучно. Если pre-flight проверяет элементы независимо, у вас нет pre-flight.
4. Failover тестируется до maintenance. Автоматический rerouting - тоже код. Плановое окно - не время узнавать, что запасной путь не тянет.
5. Связь «что делали» и «что сломалось». Плановые работы и запуски автоматики должны быть annotation'ами на дашбордах и событиями в timeline, как деплои.
6. Ручной откат отрепетирован. Во всех трёх кейсах автоматика не откатила себя сама. Я такое гонял на Wheel of Misfortune: сценарий «плановые работы пошли не по плану» отлично ложится в формат, в моей платформе собирается за вечер. Отрезвляет, когда на словах все знают, где кнопка «стоп», а на игре её ищут пять минут.

Мы научились не бояться деплоев: сделали их частыми, маленькими и обратимыми. Плановые работы пока живут в 2015 году: редкие, большие и «там всё проверено».
Ломает прод не то, что вы считаете рискованным. А то, что перестали считать изменением.

Вопрос к вам: у ваших плановых работ и cleanup-джобов есть хоть что-то из того, что есть у деплоя? Или тоже тикет, окно и надежда?

#sre #incidentresponse #changemanagement #postmortem #wheelofmisfortune

Агенту разрешают расследовать, но не разрешают чинить. Почему граница именно здесь????

В ноябре я писал про 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

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

Приносите свои кейсы, будем прожаривать :)

Что увидят в вашей архитектуре разработчик, безопасник, SRE, финансист, продакт и аналитик?

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

19 ноября на московской конференции Импульс Т1 мы проведём Прожарку архитектурных кейсов. Зовем смоллтех показать свою архитектуру!

Как всё пройдёт:
— автор за 5–7 минут показывает схему, описывает задачу, ограничения и выбранное решение;
— эксперты разбирают кейс с позиций разработки, ИБ, финансов, продукта, надёжности и эксплуатации;
— вместе смотрим на аналитику и данные;
— аудитория тоже оценивает решение и задаёт вопросы.
Автор получает многодоменный разбор: что в решении уже убедительно, какие риски стоит проверить и какие вопросы могли остаться за рамками обычного архитектурного ревью.

Детали под NDA не нужны, компанию и цифры можно обезличить.

Подать кейс нужно до 2 ноября

Game of Incidents теперь в open source

Понимаю, сейчас половина айтишников в РФ обсуждает падения всем известного облака. А вторая половина поднимает свои сервисы после этих падений. Ребята из Додо, душой и сердцем я с вами. Крепитесь.
Но, обещал - сделал. Тренажёр в опенсорсе.

Что внутри:
- 22 сценария: 3 на Linux-хосте и 19 на Kubernetes. От junior («Nginx отдаёт 502», «Сломанные пробы») до senior («Фантомная сеть», «Обновление пошло не так»). У пяти junior-кейсов есть учебные версии с пошаговыми подсказками.
- Установка одной командой на чистый Debian 13 или Ubuntu 24.04:
bash scripts/provision/provision.sh --host <ip> --domain <домен>

Можно и без домена, просто по IP.
- Всё для своих сценариев. Сценарий - это папка с scenario.yaml, брифом, разбором, Dockerfile или манифестами и скриптами поломки, проверки и эталона. Есть инструкция для LLM-агента: описываешь ему свой инцидент и инфраструктуру, он пишет сценарий, проверяет и загружает на платформу.
- Лицензии: код - Apache-2.0, сценарии и документация — CC BY 4.0.

Теперь важный момент.
Платформа запускает недоверенный код игрока в песочницах. В Kubernetes-сценариях нода кластера - привилегированный контейнер. Поэтому ставьте на выделенный сервер или ВМ и читайте SECURITY.md, прежде чем открывать регистрацию незнакомым людям.
Интерфейс и большая часть документации - на русском. README и инструкция по установке есть и на английском.

Попробовать: game.sresh.ru - регистрация по логину и паролю, почта не нужна.

Забрать исходники: github.com/fadeinflames/game-of-incidents

Буду рад сценариям из ваших постмортемов, с соблюдением NDA, пожалуйста. Для идей в репозитории есть шаблон issue - «Идея сценария». Готовые сценарии можно прислать через pull request или загрузить прямо в кабинете автора на сайте.
Об уязвимостях - только в личку, не в issues.

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

#SRE #DevOps #Linux #Kubernetes #OpenSource #GameOfIncidents