Автоматизация инцидентов: мониторинг в Jira Service Management

Представьте: ночью падает прод-сервис, Alertmanager шлёт алерт в PagerDuty, а дежурный инженер вручную создаёт тикет в Jira Service Management. Пока он ищет шаблон, заполняет severity и назначает SLA, проходят минуты — каждый алерт превращается в десятки сообщений. Мы столкнулись с этой проблемой при обслуживании инфраструктуры с 200+ микросервисами у клиента в fintech-секторе. Результат автоматизации: время реакции сократилось на 60%, а операционные расходы на инциденты — в 2 раза за счёт устранения рутины. За 5+ лет работы с ITSM и мониторингом (более 30 внедрений) мы выработали оптимальные схемы интеграции.

Опыт подсказывает: универсального решения нет — подбирать метод нужно под конкретный стек и требования к гибкости. Ниже — сравнение подходов по ключевым параметрам.

Как работает webhook-интеграция Alertmanager с JSM?

Самый гибкий путь — webhook-получатель в Alertmanager, который вызывает Jira REST API:

# alertmanager.yml
receivers:
  - name: jira-incidents
    webhook_configs:
      - url: http://jsm-bridge:8080/alert
        send_resolved: true
        http_config:
          bearer_token_file: /etc/alertmanager/jsm_token
route:
  group_by: ['alertname', 'namespace', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 6h
  routes:
    - match:
        severity: critical
      receiver: jira-incidents
    - match:
        severity: warning
      receiver: jira-incidents
      continue: false

Webhook-сервис создаёт issue через POST /rest/api/3/issue с полями: summary, description, priority, labels. При send_resolved: true Alertmanager шлёт повторный запрос со статусом resolved — сервис находит открытый issue по JQL и закрывает его. Согласно документации Atlassian, этот метод позволяет контролировать каждое поле инцидента.

Что делать с дедупликацией алертов?

Без дедупликации один сбой генерирует десятки тикетов. Два уровня защиты:

На уровне Alertmanager: group_by: ['alertname','namespace','service'] объединяет связанные алерты в один webhook. group_wait: 30s собирает повторные срабатывания до первого вызова.

На уровне webhook-сервиса: перед созданием issue сервис выполняет JQL-запрос: project = INFRA AND issuetype = Incident AND status != Done AND labels = "alert:HighCPU" AND labels = "host:prod-01". Если тикет найден — добавляется комментарий, новый не создаётся. Так одно событие = один инцидент.

Нативная интеграция через Grafana OnCall

Если стек включает Grafana OnCall, JSM-коннектор настраивается за час. OnCall поддерживает создание JSM-инцидента при активации эскалации, автоматическое закрытие при resolve и двустороннюю синхронизацию статусов. Это проще, чем кастомный webhook, но гибкость ниже: нельзя кастомизировать маппинг полей под сложные сценарии. Grafana OnCall на 50% быстрее внедряется, чем webhook-подход.

Прямая интеграция Grafana Alerting

В последних версиях Grafana появился Contact Point типа Jira. Настройка: Jira URL, username, API token, project, issue type, summary. Ограничение — нет условного создания (только с routing rules) и кастомных полей.

Настройка JSM для инцидентов из мониторинга

В JSM необходимо:

• Service Project с SLA-политиками и очередью дежурных.
• Request Type «Monitoring Alert» с полями: severity, affected_service, alert_link.
• Automation Rules для автоматического назначения на дежурного (через on-call ротацию JSM) и перехода статусов в зависимости от priority.

Пример Automation Rule: при создании issue с типом запроса «Monitoring Alert» и приоритетом Critical — назначить дежурному через on-call ротацию и перевести в статус «In Progress».

const express = require('express');
const axios = require('axios');
const app = express();
app.use(express.json());
app.post('/alert', async (req, res) => {
  const { alerts } = req.body;
  for (const alert of alerts) {
    // поиск существующего issue по JQL
    const existing = await jira.search(`project = INFRA AND status != Done AND labels = "alert:${alert.labels.alertname}"`);
    if (existing.length === 0) {
      // создание нового issue
      await jira.createIssue({
        summary: alert.annotations.description,
        issueType: 'Incident',
        priority: alert.severity === 'critical' ? 'Highest' : 'High',
        labels: [`alert:${alert.labels.alertname}`]
      });
    } else {
      // добавление комментария
      await jira.addComment(existing[0].id, 'Повторный алерт');
    }
  }
  res.send('ok');
});
app.listen(8080);

Сравнение методов внедрения

Что входит в работу

Внедрение автоматизации включает:

• Аудит текущей схемы мониторинга и ITSM-процессов.
• Выбор метода интеграции с обоснованием.
• Настройку webhook/коннектора с дедупликацией и маппингом полей.
• Тестирование полного цикла: от алерта до закрытия тикета.
• Документацию конфигурации и инструкции для дежурных инженеров.
• Пост-релизную поддержку в течение 2 недель.

Процесс работы и сроки

Начинаем с согласования: проект, issue type, кастомные поля, SLA-политики. Это занимает 1 день. Техническая реализация — от 1 до 2 дней, включая деплой и тестирование. Сроки — от 2 до 3 дней. Стоимость рассчитывается индивидуально, зависит от сложности скоупа.

Когда стоит выбрать webhook, а когда Grafana OnCall?

• Webhook — если нужна полная кастомизация, нестандартные правила дедупликации или интеграция с legacy-системами.
• Grafana OnCall — если стек уже включает Grafana, а команда хочет минимальный порог входа и двустороннюю синхронизацию.
• Прямой коннектор — для простых сценариев без сложных полей и условной логики.

Почему это выгодно?

Автоматизация создания инцидентов из мониторинга экономит до 10 часов в неделю дежурному инженеру и снижает MTTR на 50% (реальные цифры с одного из внедрений). Средняя экономия бюджета на инциденты составляет 40% после внедрения. Гарантируем качество: все конфигурации мы тестируем на тестовом стенде перед деплоем в прод.

Чтобы избежать ручного создания тикетов, свяжитесь с нами для внедрения автоматизации. Закажите интеграцию уже сегодня — ваши алерты будут превращаться в инциденты без задержек.