Перейти к содержимому
Экосистема AI Vibe
← Назад к AI Vibe News

Редакция 15 июля 2026 г.

Разборы

Observability для эпохи ИИ: PII, MCP и цепочка Self-Healing

Observability для эпохи ИИ: PII, MCP и цепочка Self-Healing.

Соло-разработчик с агентом в IDE быстро упирается не в промпт, а в доверие к данным: агент читает логи через MCP — и путь к персональным данным открывается без доступа к базе. CTO airCloset ryantsuji в второй части серии про observability в эпоху ИИ показывает, как защитить PII, сохранить поиск для ИИ и довести observability до автономного Self-Healing — от падения CI до PR; для агентного контура на Grafana MCP это условие работы с продакшеном, а не абстрактная безопасность.

Почему MCP меняет границу доверия к PII

До появления ИИ-агентов логи в основном читали инженеры с прямым доступом к базе. Модель в цикле разработки не участвовала — открытый email в query string был редкостью, а не системной дырой.

С MCP картина другая. Агент без доступа к БД получает логи как рабочий инструмент. Те же записи попадают в input модели и могут всплыть в output. Защита PII перестаёт быть «гигиеной» и становится перепроектированием trust boundary: открытый текст нельзя полагать на vendor terms — его нужно структурно держать вне модели.

Ручная схема «админ на экране хеширует email» для цепочки Self-Healing не масштабируется: бот должен починить сбой до того, как его заметит человек. ИИ-контур требует автоматического поиска по клиенту — но без plain-text email ни в Loki, ни в query string, ни в ответе модели.

Принцип из материала: «block the PII path» и «search by PII» не взаимоисключающие — поиск идёт через hash, открытый текст не пересекает observability-стек.

Шесть слоёв: от Policy Tag до маскировки на выходе MCP

В основе — функция hashEmail: HMAC-SHA256 с усечением до 12-символьного префикса (48 бит). Ключ HMAC живёт вне observability-стека — на write side и в search tool.

hashEmail(value) → HMAC-SHA256 → первые 12 символов

Шесть слоёв в airCloset выстроены последовательно:

  1. Write: BQ Policy Tag — CLS по колонкам (pii_high / pii_medium / pii_low); без fine-grained reader — Access Denied.
  2. Write: ETL DLP — Cloud DLP при трансформациях; плейсхолдеры [EMAIL_ADDRESS] / [PHONE_NUMBER].
  3. Write: log hashing — app-side hashEmail до emit в Loki; plain-text PII в Loki не попадает.
  4. Search: та же функция — query-side hashEmail перед запросом в Loki.
  5. Output: MCP masking — маскирование при выдаче AI (например, r***@air-closet.com, домен сохраняется).
  6. Identity separation — email сотрудников отдельно от customer PII; HMAC на Edge Router.

По полю применяются разные техники: same-function hashing для email и phone, partial masking для имён и адресов, full redaction для карт и токенов. Жёсткое правило: анонимизировать PII на каждом data path, который достигает ИИ — не только Loki, но и MCP-запросы к service DB.

Tool design: resolve_email_hash

Показательный пример для агентного слоя: MCP tool принимает non-PII ID (userId), email резолвится и хешируется внутри MCP server — модель видит только hash. Поиск в Loki идёт через Grafana MCP:

{service_name="subscription"} |~ "${hash}"

Агент работает с идентификатором и хешем; plain-text email не покидает доверенный периметр сервера.

Один backend для PI Lab и агентов: люди — Web, ИИ — MCP

Антипаттерн, который автор называет явно: отдельные «human dashboard aggregations» и «AI data feeds». Два канона, два расписания агрегаций, дрейф цифр между экраном для людей и контекстом для агента.

В airCloset выбран иной путь. Внутренняя AI-платформа cortex (кодовое имя, не путать со Snowflake Cortex или Palo Alto Cortex) держит один observability backend. Три хранилища observable data: Prometheus, BigQuery, Loki. Различается только presentation layer.

Канал Поверхность Как запрашивает данные
Человек PI Lab — React-портал internal API → BQ / Prometheus / Loki; агрегации на API layer
ИИ purpose-specific MCP Grafana MCP (LogQL / PromQL), BQ MCP через cortex-product-graph

В терминах DDD оба канала — I/O в один domain. Без AI-facing presentation layer (= MCP) цель «observability stack visible to AI», заложенная в Part 1 четырёх осей (application / infrastructure / CI / LLM), не достигается.

Для соло-workflow с агентом в IDE паттерн переносимый: не плодить второй «AI feed» с урезанными метриками — экспонировать тот же backend через MCP tools, что и ваш дашборд.

Self-Healing: от алерта в Loki до merge PR

Четвёртая ось из Part 1 — LLM — здесь выходит на сцену как исполнитель, а не только как объект мониторинга. Цепочка Self-Healing в материале описана пошагово:

  1. Detect — production alert или CI failure → Loki LogQL alert.
  2. Deliver — POST в внутренний webhook hub event-relay.
  3. Launch — auto-review bot на Claude Code.
  4. Gather context — логи через Grafana MCP; PR, commit и code через Product Graph MCP.
  5. Propose — fix PR.
  6. Verify — CI pass → auto-merge; иначе review другим ботом.

Условие срабатывания жёсткое: observability stack должен отдавать ИИ «what broke» в правильной форме — errors recognized, stacktraces preserved, related code reachable. Формулировка потолка из поста: «The quality of observability is the ceiling for AI autonomous operation.»

Детали harness вынесены в AI Harness Series Part 4 — в посте только отсылка, без отдельного URL. Но логика ясна: PII-слои и единый MCP-backend — не побочный security-проект, а фундамент, на котором агент может предложить PR без утечки email в контекст.

Что автор оставляет открытым

Не всё в серии закрыто. Observability target design — что считается error, как сохранять stacktrace — по-прежнему на людях; в тексте названы три неполных слоя: lint no-silent-catch, guideline doc, AI auto-review без observability checklist.

Static и dynamic editions — code-graph и production observability — «still sit side by side, not joined»; слияние обещано в следующей части.

Для читателя с агентом в цикле вывод практический: MCP и маскирование PII — необходимое, но не достаточное. Потолок автономии задаёт качество самих сигналов observability. Строить агентный CI/CD без этого — значит закладывать потолок ниже, чем кажется по демо с зелёным пайплайном.

Источники