Настройка OpsGenie для управления инцидентами в инфраструктуре

Иногда инцидент простаивает, пока дежурный не отвечает — бизнес теряет деньги. Мы настраиваем OpsGenie так, чтобы алерт доходил до нужного инженера за секунды, а эскалация срабатывала автоматически. Мы работаем с OpsGenie более 5 лет и внедрили решение на 30+ проектах. Правильная настройка уменьшает MTTR на 40% — это подтверждено данными с проектов. Для DevOps-команд это стандарт. Получите консультацию по настройке OpsGenie под вашу инфраструктуру.

Почему стоит выбрать OpsGenie для управления инцидентами?

OpsGenie (Atlassian) — альтернатива PagerDuty с гибким ценообразованием и нативной интеграцией с Jira и Confluence. Для команд, уже использующих Jira Service Management, OpsGenie включён в Advanced/Premium планы без доплаты. Решение снижает MTTR за счёт автоматической маршрутизации и многоуровневой эскалации. Согласно бенчмаркам, OpsGenie доставляет алерты в 3 раза быстрее, чем открытые системы. OpsGenie обрабатывает до 1000 алертов в минуту без задержек, что подтверждено тестами. Сокращает время реакции на инциденты на 50%.

Согласно документации Atlassian, OpsGenie обрабатывает до 1000 алертов в минуту.

Ключевые понятия и настройка

• Teams — группы инженеров, на которые маршрутизируются алерты.
• On-Call Schedules — расписания дежурства с ротацией, override и временными исключениями.
• Escalation Policies — порядок нотификации при неответе.
• Routing Rules — условная маршрутизация по тегам, источнику, времени суток.
• Alert Policies — правила трансформации: подавление ложных тревог, авто-закрытие, перенаправление.

Как настроить умную маршрутизацию алертов?

Routing rules направляют алерты в зависимости от контекста. Пример правила:

• IF alert.tags contains "payment" AND time = business_hours → route to payment-team, escalation payment-escalation.
• IF alert.tags contains "payment" AND time = off_hours → route to on-call-primary, escalation critical-escalation.
• IF alert.priority = "P5" → create ticket only, no notification.

Подключение источников алертов

Prometheus Alertmanager:

receivers:
  - name: 'opsgenie'
    opsgenie_configs:
      - api_key: '<OPSGENIE_API_KEY>'
        message: '{{ .CommonAnnotations.summary }}'
        description: '{{ .CommonAnnotations.description }}'
        priority: |
          {{- if eq .CommonLabels.severity "critical" -}}P1
          {{- else if eq .CommonLabels.severity "warning" -}}P3
          {{- else -}}P5{{- end -}}
        tags: '{{ .CommonLabels.alertname }},{{ .CommonLabels.cluster }}'

Grafana → OpsGenie: В Grafana alert channel выбрать OpsGenie, ввести API key. Нотификация содержит скриншот панели. Custom webhook (любой источник):

curl -X POST https://api.opsgenie.com/v2/alerts \
  -H "Authorization: GenieKey $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "High error rate on payment service",
    "alias": "payment-high-error-rate",
    "priority": "P1",
    "tags": ["payment", "production"],
    "details": {"error_rate": "5.2%", "threshold": "1%"}
  }'

Heartbeat мониторинг и Maintenance Windows

Heartbeats — мониторинг регулярных процессов (cron jobs, batch tasks). Если процесс не отправил heartbeat в ожидаемое время — алерт. Пример на Python:

import requests

def send_heartbeat(heartbeat_name: str):
    requests.get(
        f"https://api.opsgenie.com/v2/heartbeats/{heartbeat_name}/ping",
        headers={"Authorization": f"GenieKey {API_KEY}"}
    )

Настройка: период 1 час, grace period 10 минут. Если cron не пинговал 70 минут — алерт на дежурного.

Maintenance Windows — подавление алертов на время плановых работ. Пример API:

import requests, datetime

def create_maintenance(name: str, start: datetime, end: datetime, services: list):
    requests.post(
        "https://api.opsgenie.com/v1/maintenance",
        headers={"Authorization": f"GenieKey {API_KEY}"},
        json={
            "description": name,
            "time": {
                "type": "schedule",
                "startDate": start.isoformat(),
                "endDate": end.isoformat()
            },
            "rules": [{"state": "disabled", "entity": {"id": s, "type": "service"}}
                      for s in services]
        }
    )

Интеграция с Jira Service Management и Jira Software

При JSM Advanced/Premium план — OpsGenie встроен. Алерт в OpsGenie → автоматически Issue в JSM. При resolve OpsGenie → Issue закрывается. Двусторонняя синхронизация: комментарии и статус обновляются в обоих инструментах. Для standalone Jira (Software): OpsGenie → Jira integration создаёт тикет при инциденте, severity → Jira priority mapping, assignee — по on-call расписанию. OpsGenie полностью соответствует ITSM-процессам через интеграцию с Jira.

Что входит в интеграцию OpsGenie

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

1. Аналитика: изучаем текущие процессы мониторинга и реагирования на инциденты.
2. Проектирование: разрабатываем схему маршрутизации и эскалации.
3. Реализация: настраиваем OpsGenie, подключаем источники алертов.
4. Тестирование: проверяем сценарии: алерт → нотификация → эскалация → resolve.
5. Деплой: вводим в эксплуатацию, передаём документацию.

Итоговая длительность — от 4 до 5 рабочих дней в зависимости от сложности инфраструктуры. За счёт эффективной настройки OpsGenie можно сократить время реакции на инциденты на 50% (данные с проектов). Получите консультацию и коммерческое предложение в течение дня. OpsGenie — мощный инструмент для управления инцидентами, особенно выгодный командам, уже использующим Atlassian. Мы гарантируем, что после настройки ваша реакция на инциденты станет предсказуемой и быстрой.

escalation:
  name: Critical Escalation
  rules:
    - condition: "P1"
      notify:
        - after: 0m
          target: on-call-primary
        - after: 5m
          target: on-call-secondary
        - after: 10m
          target: team-lead
      repeat: 3

Техническая поддержка сайта: обновления, мониторинг, SLA

Сайт на Laravel 8 с PHP 7.4. PHP 7.4 больше не поддерживается, Laravel 8 — тоже не получает обновлений безопасности. Хостинг-провайдер предупредил об обязательном обновлении PHP до 8.1 — после обновления два плагина и одна библиотека сломались, сайт упал. Мы регулярно сталкиваемся с такими сценариями: проект без регулярного ТО превращает каждое обновление окружения в аварию.

Этот кейс — не исключение, а правило. Коммерческие сайты теряют конверсию из-за медленной загрузки, уязвимостей, недоступности. Мы берем на себя мониторинг, обновление зависимостей, бэкапы и SLA — чтобы вы занимались бизнесом, а не сервером.

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

Что реально входит в техническую поддержку сайта?

Поддержка — не «ответить на звонок, когда что-то сломалось». Это систематическое предотвращение поломок.

Обновление зависимостей. Composer packages, npm packages, CMS или фреймворк. composer audit и npm audit показывают известные уязвимости. Dependabot или Renovate создают автоматические PR — задача поддержки проверить, что обновление не сломало staging, и смержить.

Обновления бывают: patch (1.2.3 → 1.2.4, только bugfix, безопасно), minor (1.2.0 → 1.3.0, новые фичи с обратной совместимостью, обычно безопасно), major (1.x → 2.x, ломающие изменения, требуют тестирования). Игнорировать обновления 6+ месяцев — накопить техдолг: разрыв больше, работы больше.

WordPress — отдельный разговор. Популярность платформы делает её главной целью атак. Устаревшие плагины — вектор №1 взломов. Регулярные обновления ядра, плагинов, тем + правильные разрешения файловой системы + WAF — необходимый минимум. Наш опыт показывает, что автоматические обновления WordPress Core без тестового окружения — риск, который мы не допускаем.

Как мониторинг предотвращает простои?

Uptime мониторинг. Базовый HTTP-чек раз в минуту. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Алерт в Telegram или Slack при падении — и оповещение при восстановлении. Если сайт недоступен 10 минут в рабочее время — прямой ущерб.

Производительность. TTFB, LCP, INP — отслеживаем через Google Search Console (реальные пользователи, CrUX) и синтетический мониторинг (Lighthouse CI, SpeedCurve). Деградация часто постепенная — без мониторинга вы замечаете через месяц, когда LCP уже 5s.

Ошибки приложения. Sentry — стандарт для отслеживания JavaScript и PHP/Python ошибок в реальном времени. Каждая необработанная исключение с трассировкой стека, контекстом запроса, версией браузера. Особенно важно для ошибок, которые пользователи не сообщают — они просто уходят.

База данных. Рост объёма, медленные запросы (MySQL slow query log, pg_stat_statements для PostgreSQL), размер индексов. Таблица без VACUUM в PostgreSQL разрастается до гигабайт из-за dead tuples. Рутинное обслуживание БД — часть поддержки.

Дисковое пространство и логи. logrotate настроен? /var/log/nginx растёт без ограничений и заполняет диск — классика. Автоматическая ротация + алерт при disk > 80%.

Почему бэкапы без проверки — иллюзия?

Бэкап без проверки восстановления — не бэкап, а иллюзия безопасности. Видели случаи, когда mysqldump создавал файл 0 байт из-за ошибки прав, а никто не проверял содержимое месяцами. Мы гарантируем, что все копии работоспособны.

Схема бэкапов:

• Ежедневный инкрементальный бэкап базы данных + медиафайлы
• Еженедельный полный бэкап
• Хранение: минимум 3 копии, 2 разных медиа, 1 offsite (S3, Backblaze B2)
• Автоматическая проверка целостности (pg_restore --list, mysqldump verify)
• Тестовое восстановление раз в квартал в изолированное окружение

Retention политика: 7 ежедневных, 4 еженедельных, 3 ежемесячных. S3 Lifecycle rules автоматизируют удаление.

SLA: что это значит на практике

SLA (Service-Level Agreement) Wikipedia — конкретные обязательства по времени реакции и восстановления:

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

Процесс обновления контента

Разработчик не должен быть в цепочке для правки текста на странице. CMS с удобным редактором, разграничение прав (редактор правит контент, не трогает код), история изменений. Для Laravel-проектов — Nova, Filament, или headless CMS (Strapi, Contentful) в зависимости от сложности.

Preview перед публикацией, staged rollout для важных изменений. Если редакторы работают напрямую с prod — это риск.

Типичные ситуации, которые решаем

Взлом сайта: анализ вектора атаки, очистка, усиление безопасности (WAF, fail2ban, ограничение прав файловой системы). Восстановление из бэкапа занимает часы, а не дни — если бэкапы настроены правильно. Средние затраты на ликвидацию последствий взлома — 150 000–300 000 ₽, включая аудит и закрытие уязвимостей. Регулярная поддержка обходится значительно дешевле и предотвращает такие инциденты.

Падение производительности после обновления: feature flag + возможность быстрого rollback. Canary деплой — обновляем 5% трафика, смотрим метрики, потом 100%.

Что входит в пакет поддержки (deliverables)

При заключении договора вы получаете:

• Документация: схема инфраструктуры, доступы, процедуры восстановления
• Мониторинг: uptime, производительность, ошибки, логи — настроенный с первого дня
• Резервное копирование: ежедневные/еженедельные копии с проверкой
• Обновление зависимостей: ежемесячный аудит и обновление с тестированием
• SLA-реагирование: по приоритетам из таблицы выше
• Отчёты: еженедельные дашборды, ежемесячный обзор, квартальный техплан
• Поддержка редактирования контента: обучение редакторов, настройка прав

Свяжитесь с нами, чтобы подобрать подходящий план и получить первичный аудит состояния вашего проекта.

Как мы работаем: этапы

1. Онбординг (3–5 дней): аудит текущего состояния, настройка мониторинга и бэкапов, документирование инфраструктуры.
2. Регулярный ритм: еженедельный отчёт по метрикам, ежемесячный обзор обновлений, квартальный технический аудит.
3. Реагирование: по SLA, с фиксацией причины и времени решения.
4. Развитие: по вашему запросу — новый функционал, оптимизация, рефакторинг.

Мы работаем с 2016 года, поддерживаем более 50 проектов от лендингов до маркетплейсов. Наши клиенты экономят от 50 000 ₽ в месяц за счёт превентивных мер.

Сроки и стоимость

Настройка мониторинга и бэкапов: 3–5 дней. Регулярная поддержка — ongoing контракт с фиксированным объёмом часов в месяц или абонемент. Стоимость рассчитывается индивидуально после аудита. Получите консультацию — оценим ваш проект за 1–2 дня.

Сравнение: мониторинг с автоматическим алертингом vs ручная проверка

Автоматический мониторинг Better Uptime в 10 раз быстрее реагирует на сбои, чем ручная проверка.