Строим первую линию техподдержки на n8n за 250$ в месяц. Часть 2

• attachmentsAnalyzer — разбирает скриншоты и текстовые логи;
  
• httpProbeTool — корректно проверяет доступность ендпоинтов, не роняя цепочку с агентом;
  
• errorReporter — страхует на случай, когда падает сам workflow и автор обращения остаётся в неведении.

• Расследователь инцидентов — самая капризная категория, у неё самый низкий процент автономного разрешения и самые интересные подводные камни;
  
• Менеджер задач — обработка запросов на модификацию инфраструктуры с автоматическим заведением тикетов в Jira;
  
• Консультант по вопросам инфраструктуры — ответы на «а где у нас настроен X?» с хитростью в виде автогенерации README в IaC-репозиториях.

{
  "message": "Текст обращения в чате",
  "post_id": "ID поста — нужен, чтобы ответить именно в этот тред",
  "channel_id": "ID канала Mattermost",
  "channel_name": "Название канала, прокидывается в промпт для контекста",
  "user_name": "Автор обращения, упоминается в финальном ответе",
  "user_id": "ID пользователя",
  "file_ids": ["ID вложений, если есть"],
  "category": "incident",
  "confidence": 0.95,
  "summary": "Краткое описание от классификатора",
  "is_thread": true,
  "thread_root_id": "ID корневого сообщения треда",
  "on_call_user": "Имя дежурного — пригодится при эскалации"
}

• K8S_CLUSTERS — список доступных контекстов (у нас два: dev и prod, оба в DigitalOcean Frankfurt);
  
• K8S_NAMESPACE — основной namespace с прод-нагрузкой;
  
• GITHUB_ORG — название организации в GitHub, чтобы агент не пытался искать код вообще везде;
  
• prometheus_uid и loki_uid — UID datasource в Grafana, без них агенту неоткуда узнать, куда стучаться за метриками и логами;
  
• reply_root_id — ID поста, в который агент будет отвечать (либо корневой пост треда, либо сам пост обращения).

• Kubernetes MCP — посмотреть поды, события, прочитать логи контейнера. В системном промпте отдельно прописано: pods_log для одного и того же пода больше двух раз не вызывать. Без этого ограничения агент любит зацикливаться в попытках «уточнить ещё разок».
  
• Grafana MCP — запросы в Prometheus (query_prometheus) и Loki (query_loki_logs). Здесь же — поиск по дашбордам, если агент хочет дать в ответе ссылку на готовую панель.
  
• DigitalOcean MCP — нужен, когда инцидент касается уровня инфраструктуры: App Platform, дроплеты, кластер DOKS, балансировщики.
  
• GitHub MCP — посмотреть последние коммиты, прогоны Actions, открытые PR. Особенно полезен в сценарии «всё сломалось ровно после деплоя» — а такие сценарии у нас, как и у всех, не редкость.
  
• Mattermost MCP — только на чтение. Используется в основном для get_thread в самом начале расследования. Отправку ответа агенту не доверяем — это делает отдельная нода после получения output. Если что-то пойдёт не так на этапе постинга, тред просто останется без финального ответа, но execution не упадёт.
  
• Qdrant Vector Store — база знаний по нашей инфраструктуре: описание компонентов, связи сервисов, конвенции именования, полезные лейблы. Используется, когда агент натыкается на имя незнакомого ему сервиса и хочет понять, где он живёт и с кем общается.

{
  "keywords": ["postgres", "pgbouncer"],
  "match_mode": "any"
}

Пример подключения tool

Пример использования

{
  "summary": "<область>: <что нужно сделать>",
  "description": "<1-3 предложения с деталями>",
  "label": "<одно из направлений>"
}

• Qdrant Vector Store — посмотреть, как у нас в принципе устроена область, к которой относится запрос. Это нужно, чтобы агент не выдумывал новое название там, где уже есть существующее.
  
• Mattermost MCP — если запрос пришёл в тред, прочитать предысторию. Часто люди уточняют детали именно в треде, а в первом сообщении пишут одну строчку.
  
• HTTP Request — на случай, если в запросе есть ссылка на чей-то PR, документ в Confluence или внешнюю спеку.

Пример настройки

Jira node

Create Jira API token

Пример использования

## Overview
## Repository layout
| Directory | Tooling | Purpose |
|-----------|---------|---------|
## terraform/
Описание структуры директорий
### Resource catalog
| Cloud | Region | Units |
|-------|--------|-------|
### How to run
## ansible/
Описание инвенторя, плейбуков, ролей
### Galaxy requirements
### How to run
## helm/
Структура helmfile кода
### Environments and kube contexts
| Helmfile environment | kubeContext |
|----------------------|-------------|
### Helm repositories
| Name | URL | OCI |
|------|-----|-----|
### App catalog
| Release | Chart | Version | Namespace |
|---------|-------|---------|-----------|
### How to run
## manifests/
| Environment | Subfolders |
|-------------|------------|
### File inventory
### How to run
## .github/
### Workflows
| Product | Files |
|---------|-------|
### Secrets consumed
## Local tooling
Список необходимых утилит с версиями необходимые для работы

Пример использования

• Расследователь инцидентов — закрывает 40% обращений полностью; в остальных случаях дежурный получает на руки готовый разбор с гипотезами и экономит 10–15 минут на старте.
  
• Менеджер задач — практически все запросы на модификацию доходят до Jira с осмысленным summary и проставленным label; ручные правки нужны редко, обычно по тексту описания.
  
• Консультант — закрывает 70% вопросов без участия инженера; для оставшихся ответ агента всё равно полезен как стартовая точка для дежурного.
  
• Совокупная стоимость при нашем потоке держится в районе $250 в месяц на оплату LLM. С учётом того, что система работает 24/7 и не уходит в отпуск — это смешные деньги.

• Расширить инструментарий агентов до уровня «действия, а не только чтение» — аккуратно дать доступ к перезапуску подов, применению готовых манифестов, restart'ам systemd-сервисов. Понятно, что это территория с минами, поэтому делать буду через явное подтверждение от инженера в Mattermost — без подтверждения никакие изменения не уезжают.
  
• Добавить обработку анонсов техработ — пока такие сообщения просто помечаются и игнорируются, но их можно было бы пушить в отдельный канал-дайджест с автоматическим саммари «что планируется на этой неделе».
  
• Подключить отдельную ветку для security-вопросов — со своей базой знаний по нашим compliance-документам и политике безопасности.
  
• Прикрутить аналитику по обработанным обращениям — какие категории растут, где какой процент автономного разрешения, сколько токенов уходит на категорию. Без цифр трудно понять, что именно стоит улучшать в первую очередь.