Редакция 2 июня 2026 г.

Исправлено до того, как заметили: self-healing в проде с двумя агентами Claude

Production-алерт больше не обязан заканчиваться ночным созвоном: Ryan Tsuji (CTO airCloset) в четвёртой части серии про внутреннюю AI-платформу cortex описывает цепочку «расследование → fix PR → независимый AI-review → merge → redeploy», где каждый цикл ещё и ужесточает lint, CI и guidelines, чтобы тот же антипаттерн отсекался автоматически. разбор на Dev.to

Материал вышел 1 июня 2026 года на Dev.to — продолжение нарратива после harness, Product Graph и auto-review, с фокусом на observability и предотвращении повторов.

Когда Grafana стреляет: от webhook до `MODE=self-healing`

Сигнал идёт по знакомому для on-call маршруту, но дальше вместо ручного тикета включается агентный контур.

Grafana Alert Rule шлёт POST на /webhook/grafana.
Event Relay (in-house, Firestore) принимает событие и отдаёт его по SSE (event: grafana-alert).
Тот же webhook-server, что в Part 3 серии, но в режиме MODE=self-healing, слушает firing alerts.
В отдельном worktree: git worktree add -b hotfix/auto-alert-{service}-{ts}, затем расследование и git push + gh pr create.
Дальше срабатывает автоматика Part 3: APPROVE → auto-merge → auto-redeploy.

cortex в тексте автора — внутренний коднейм AI-платформы airCloset, а не Snowflake Cortex и не Palo Alto Networks Cortex.

Тот же fingerprint алерта не обрабатывают повторно 4 часа (throttle). Если в alertname есть credential, сценарий уходит человеку — риск утечки в логах и фиксе выше, чем выгода от полной автономии.

Расследование: два `claude -p`, MCP и разный контекст

«AI investigation» здесь — не абстрактный copilot в IDE, а отдельные процессы claude -p с разным входом и без общего контекста между ними.

Роль	Задача	Вход
Fixer (Self-Healing)	Остановить инцидент	alert + выборка из Loki через Grafana MCP + связанный код через Product Graph MCP
Reviewer (Part 3)	Проверить diff по контракту	diff + cpg + review-guidelines

Fixer и reviewer не делят сессию: один не «апрувит» вывод другого — Self-Healing PR может получить REQUEST_CHANGES от reviewer. Оба проходят те же 9 lenses, что и обычный auto-review: Graph, Architecture, Security, Test, Doc, Impact, Observability, AI-Antipattern и Recurrence.

Версии моделей Claude в посте не названы — только интерфейс claude -p.

Guides: как ИИ и люди запоминают урок после фикса

Recurrence prevention в их терминологии — не «заведём задачу на lint потом», а обязательное усиление Guides (термины Fowler Guides/Sensors из Part 1) в том же PR, что и hotfix.

Machine-read Guides — custom ESLint (@cortex/eslint-plugin-graph), oxlint, CI-скрипты scripts/check-*.ts, пороги coverage, Prettier. На момент публикации автор перечисляет 26 правил плагина, 13 CI guards, 183 oxlint-правила с уровнем error, 9 strict TypeScript gates и пороги покрытия 90% по statements и branches.

Human-and-AI-read Guides — репозиторий review-guidelines (recurrence-prevention.md, severity.md, ai-antipattern.md и др.) как критерии для auto-review.

Каждый Self-Healing PR должен добавить новый Guide — lint, CI guard, type constraint или запись в guideline — чтобы тот же anti-pattern auto-rejectился дальше. Матрица [Recurrence] в auto-review задаёт, когда lint обязателен, когда нужен horizontal expansion по cpg (Product Graph из Part 2), а когда достаточно записи в guideline.

Примеры «механических ловушек» из поста: graph/no-silent-catch, cortex-quality/require-fetch-timeout, check-otel-env-injection — многие появились после конкретных инцидентов, а не из абстрактного аудита стиля.

Три слоя Part 4 и стек наблюдения

Архитектуру автор раскладывает на три слоя поверх cpg и observability stack из предыдущих частей:

Observation — OpenTelemetry (@cortex/otel), Loki (Pino + trace_id), Mimir, Tempo, Faro, alert rules в Pulumi (группы BOT, Pipeline, Transformer, Generator, Gemini, CI, Deploy, Service Catch-All). Уровни warn / error / fatal привязаны к business impact, не к имени exception.
Repair — Self-Healing по цепочке выше; в основном пороги error, fatal эскалируют человеку.
Strengthening — накопление Guides после каждого цикла («quality gates compound over time»).

Кодовая база — «several-hundred-thousand-line»; без Product Graph impact tracing для агентов и review, по словам автора, не сходится.

Цифры за 30 дней: 115 PR — не 115 инцидентов для пользователей

В разделе про «last month's numbers» Tsuji фиксирует 115 merged Self-Healing PR за последние 30 дней, «effectively all» — merge и deploy без участия человека. Это не 115 user-facing инцидентов:

около 54 — класс Deploy Failed (CI/Pulumi до prod);
около 61 — production-runtime alerts (error-log / consecutive-failure);
AI, по описанию, поглощает многие сбои до распространения на пользователей.

Повторяемость: только по gcs-transformer — 25 из 61 runtime alerts. Часть всплеска — catch-up после правила no-silent-catch: раньше «silent catch» маскировали ошибки.

Отдельные корзины: несколько раз в месяц AI помечает кейс как «not fixable in code»; human-acknowledged incidents — low single digits per month. Заголовок 115 считает циклы Self-Healing, дошедшие до PR created → merged → deployed, а не «часть из 115 провалилась».

Иллюстрация из поста: 21 мая 2026 Self-Healing PR fix(meet-subscription-renewal): auto-fix for Service Error Log Detected — конфликт 409 ALREADY_EXISTS на Meet subscription; фикс через idempotent createMeetSubscription и тесты.

Где автономия заканчивается

Self-Healing, по дисклеймеру автора, не видит UI-ошибки без exception, silent data corruption и деградацию UX до порога SLO/latency — «дыры в observation» остаются слепыми зонами.

Серия на Dev.to продолжается: Parts 5–6 помечены как Coming soon (масштабирование harness к toC и wrap-up). Parts 1–3 в таблице автора названы по slug (ai-harness-intro, cortex-product-graph, cortex-auto-review) без полных URL в том же посте — для деталей harness и auto-review нужны отдельные статьи серии.

Источники

Ryan Tsuji — «Fixed Before Anyone Notices, Stronger After Every Fix: Self-Healing + Recurrence Prevention (Series Part 4)», Dev.to, опубликовано 2026-06-01T23:57:25Z: Dev.to (дата доступа: 2026-06-02)
Метаданные Dev.to на момент публикации в ленте: время чтения ~22 мин, 10 реакций, 0 комментариев