Як побудувати AI агентів для on-call

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Ця стаття пояснює, як ми розробили ієрархічного AI агента за допомогою Claude Skills + Grafana MCP, який автономно діагностує несправності нашого пайплайну збору історії. Він агрегує складну телеметрію — метрики, логи та внутрішні API-дані — у зрозумілі та практичні інсайти (всього за 3 хв).

Щось не працює, але де?

«Наш збір історії виконується вже 15 годин, і він все ще на 25%. Це блокує наш квартальний звіт. Що відбувається?»

Це повідомлення від одного з наших найбільших клієнтів. Наш on-call інженер — який працює всього кілька місяців — дивиться на екран. Який це сервіс? Які логи перевірити? Яка панель на дашборді показує... стоп, яка саме панель у Grafana?

Черговий інженер має не лише знати, де шукати релевантну інформацію — логи, дашборди, метрики — а й уміти пов’язати ці дані між собою. Саме це зазвичай і є найскладнішою частиною. У розподілених системах відповідь може ховатися у будь-якій частині. А клієнт чекає...

І тут мене осінило: а що, якби runbook міг сам себе виконувати?

Проблема: надто багато рухомих частин

Збір історії в YouScan дозволяє клієнтам отримувати згадки в соціальних мережах аж до 2014 року. Під капотом це доволі складний танець розподілених систем:

Фаза 1: Пошук

Знайти релевантні згадки в нашому масивному історичному кластері Elasticsearch розміром 2,48 петабайта. Продуктивність залежить від:

• Поточного навантаження на кластер (скільки паралельних зборів виконується?)
• Глибини пошуку (ми тримаємо останній рік даних на SSD, а інші на HDD для економії)
• Складність пошукового запиту
• Стан кластера (неприсвоєні шарди? проблеми на нодах еластіка?)

Фаза 2: Збереження

Обробка знайдених згадок у пайплайні збагачення.

Типові проблеми:

• стан зовнішніх сервісів (тональність, сутності, розпізнавання зображень і багато інших)
• бекпрешер у пайплайні (чи заповнені блоки?)

Класичний runbook порадив би: «Перевір API зборів → потім дашборд A → потім ці логи → потім звір із дашбордом B...»

Але в якому порядку? Що важливіше? Як корелювати знахідки з різних джерел?

Рішення: Claude Skills як ваш експерт з Observability

Claude Skills — це AI-агенти для конкретних задач. Ви створюєте файл SKILL.md, в якому описуєте, що саме повинен робити агент, коли це робити і якими інструментами (API, MCP) користуватися. Це автоматизовані процедури, які справді розуміють контекст.

Для нашої задачі це було ідеально. Нам потрібен був агент, який міг би:

• досліджувати кілька напрямів паралельно, а не послідовно;
• синтезувати результати з різних джерел;
• пріоритизувати рекомендації;
• пояснювати свою логіку, навчаючи нових інженерів;

Ключова ідея: ієрархічна мультиагентна архітектура.

Побудова оркестратора : агенти, агенти, агенти

Замість одного монолітного агента, який намагається робити все (і роздувати контекстне вікно кожним рядком логу), ми побудували координовану команду:

Головний Оркестратор (SKILL.md)
├── Координатор фази пошуку (search-subagent.md)
│   ├── Агент аналізу зборів (API запити)
│   ├── Агент стану кластера (метрики Grafana)
│   └── Агент логів помилок (логи Elasticsearch)
└── Координатор фази збереження (save-subagent.md)
    ├── Агент аналізу повільного збереження (логи Elasticsearch)
    └── Агент зовнішніх сервісів (показники помилок Grafana)

Ось поточна версія нашого головного оркестратора: 👉 SKILL.MD 👈

Ці агенти працюють паралельно: один дістає метрики, інший — логи, третій — API-дані. Кожен повертає стислий і структурований висновок.

Переваги такої архітектури:

1. Швидкість — результат за хвилини замість довгої послідовної діагностики.
2. Контроль контексту — кожен агент працює з малим, чистим контекстом.

Потім фазові координатори збирають результати, а головний оркестратор визначає корінну проблему: Пошук? Збереження? Обидві фази? Чи вони блокують одна одну?

Коли ми запустили skill на реальному інциденті, ось що він знайшов менш ніж за 3 хвилини:

Executive Summary:
History collection health: Degraded (Search bottleneck)
Primary issue: 208 active collections (HIGH), 1 power users
Cluster load: 17.4 avg (elevated), search latency: 2800ms (2.5x baseline)
External services: All healthy
Severity: High
...

Prioritized Actions:
CRITICAL (immediate):
1. Check collections from *** account, launched by *** user.
2. Stop 5 lowest-priority collections targeting 2022 data.

HIGH (urgent):
1. Monitor cluster load after reduction

MEDIUM (short-term):
1. Implement per-account limit: max 20 concurrent collections

Це конкретна інформація з конкретними email користувачів і конкретними ID збірок для зупинки. Не просто «перевір логи і подивись, чи щось виглядає дивно».

Структуроване виведення є критичним

Кожен субагент повертає структуровані знахідки, а не сирі дані. Це підтримує контекстні вікна керованими та робить консолідацію можливою:

Agent Output Format:
  summary: "2-3 sentence assessment"
  key_findings: ["bullet", "point", "list"]
  root_cause: "What's actually wrong"
  severity: "LOW/MEDIUM/HIGH/CRITICAL"
  recommendations: ["Specific", "Actionable", "Prioritized"] 

Контекст є критичним для ефективної роботи агентів; ось гарна стаття від Anthropic про стратегії управління контекстом.

Навчай, а не просто розповідай

Наш skill не просто каже «зупини ці збори». Він пояснює:

• Чому вони проблемні (Warm nodes, 2+ років, у користувача 190 одночасних зборів)
• Який вплив вони мають (навантаження на кластер 17,4, затримка пошуку 2,5x від базової)
• Як запобігти повторенню (впровадити ліміти на акаунт, розподіляти збори на теплих нодах)

Це перетворює кожен інцидент на можливість навчання для нових інженерів.

А що далі?

Збір історії — це лише один сценарій усунення несправностей; ми можемо мати окремий Claude skill для будь-чого.

Але ось де це стає дійсно цікавим: агентам не треба чекати, поки ви запитаєте.

Уявіть собі, що ваш діагностувач історії запускається автоматично, коли навантаження кластера перевищує пороги. Або ваш агент затримки API спрацьовує, коли p95 час відповіді перетинає 500ms.

Вони розслідують, синтезують знахідки і або:

• Автоматично вирішують прості проблеми (перезапустити застряглий сервіс, очистити кеш)
• Представляють діагностовані знахідки інженерам (повністю пропускаючи фазу розслідування)
• Ескалують із вже зібраним повним контекстом

Для досвідчених інженерів Агенти для Observability — це економія часу та мультиплікатори сили. Для нових інженерів вони — прискорене навчання: спостереження експертних патернів усунення несправностей в дії, з поясненнями. А для всіх вони — невтомні спостерігачі, які можуть моніторити та діагностувати 24/7.

А як у вас?

• Які сценарії чергування у вас найскладніші?
• Експериментуєте з AI-асистованим інцидент-респонсом?
• Що би ви автоматизували першочергово?

AI-агенти — це вже не просто хайп. Це реальний інструмент Observability і Troubleshooting.