Настройка PagerDuty: интеграция и управление инцидентами под ключ

Ваша команда тонет в море алертов: 200+ уведомлений в час, половина — дубли, остальные — предупреждения, не требующие реакции. Дежурные выгорают, реальные инциденты теряются, а MTTR растёт. Мы настраиваем PagerDuty так, что проблема уходит за 2–4 дня. Система управления инцидентами перестаёт быть головной болью.

Один из наших проектов: Prometheus генерировал 200+ алертов в час. После настройки PagerDuty с Event Intelligence количество инцидентов сократилось до 5–7 в день. MTTR упал с 45 до 8 минут — в 5 раз быстрее. Средняя стоимость минуты простоя для e-commerce высока, поэтому экономия составила существенные суммы. За более чем 5 лет мы выполнили более 50 подобных интеграций для команд разного размера. Гарантируем стабильную работу системы после внедрения.

Архитектура PagerDuty: ключевые компоненты

Services — логические единицы (backend API, payment service, database). Каждый сервис имеет свою escalation policy и on-call schedule.

Integrations — источники событий: Prometheus/Alertmanager, Datadog, CloudWatch, Grafana, Uptime Robot, кастомные webhooks. Каждая интеграция генерирует уникальный endpoint key.

Escalation Policies — правила: кто получает алерт, через сколько минут эскалация, куда эскалировать.

Schedules — on-call расписания с ротациями.

Как подключить Prometheus Alertmanager? (развёрнутый кейс из нашей практики)

Это самый частый сценарий. Действуем по шагам:

1. Создаём сервис в PagerDuty и добавляем интеграцию типа Prometheus. Получаем routing_key.
2. В конфиге Alertmanager настраиваем receiver с этим ключом. Обязательно указываем описание и severity.
3. Настраиваем группировку по alertname и кластеру, чтобы связанные алерты не плодили инциденты.
4. Проверяем, что тестовый алерт приходит в правильный сервис и эскалируется по политике.

Пример конфигурации receiver:

# alertmanager.yml
route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'pagerduty-critical'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
    - match:
        severity: warning
      receiver: 'slack-warnings'

receivers:
  - name: 'pagerduty-critical'
    pagerduty_configs:
      - routing_key: '<PAGERDUTY_INTEGRATION_KEY>'
        description: '{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'
        severity: '{{ .CommonLabels.severity }}'
        details:
          firing: '{{ template "pagerduty.default.instances" .Alerts.Firing }}'

В одном из проектов мы настроили группировку по кластеру и alertname. Это снизило количество создаваемых инцидентов на 70%.

Сравнение способов интеграции

Как PagerDuty помогает справиться с шумом алертов?

PagerDuty Event Intelligence (доступен в платных планах) автоматически подавляет шум. Он включает три механизма:

• Alert Grouping: связанные алерты объединяются в один инцидент. При аварии БД вы не получите 50 алертов от всех сервисов — только один.
• Intelligent Alert Grouping: ML-модель на основе исторических паттернов группирует похожие алерты.
• Suppression Rules: временное подавление алертов во время planned maintenance.

По данным документации PagerDuty, шумоподавление сокращает количество уведомлений до 90%. В одном из проектов мы добились снижения на 85%.

Преимущества PagerDuty перед email-оповещением

Email не умеет группировать алерты, не имеет эскалаций и не даёт статистики по MTTR. PagerDuty в 5 раз быстрее доставляет критические уведомления: push-уведомления приходят за секунды, в то время как письмо может задержаться на минуты. К тому же PagerDuty автоматически ведёт хронологию инцидентов, что помогает при постмортеме.

Таблица: ключевые метрики до и после внедрения PagerDuty

Автоматизация с вебхуками и Runbook

PagerDuty Webhooks отправляют события при создании, обновлении или закрытии инцидента. Пример обработчика на Python:

@app.route('/pd-webhook', methods=['POST'])
def pagerduty_webhook():
    data = request.json
    event_type = data['event']['event_type']
    incident = data['event']['data']
    
    if event_type == 'incident.triggered':
        create_incident_channel(incident['title'], incident['id'])
        update_status_page('major_outage', incident['title'])
    
    elif event_type == 'incident.resolved':
        archive_incident_channel(incident['id'])
        update_status_page('operational', '')
    
    return '', 200

Runbook Automation (бывший Rundeck) позволяет выполнять автоматические действия при алерте: перезапуск сервиса, очистку диска, масштабирование. Если скрипт исправляет проблему — инцидент закрывается автоматически, без пробуждения дежурного.

Что входит в нашу работу?

• Аудит текущих процессов мониторинга и инцидент-менеджмента.
• Проектирование структуры сервисов, эскалационных политик и расписаний.
• Настройка интеграций с Prometheus, Datadog, CloudWatch, Grafana и другими.
• Конфигурация вебхуков и автоматизация с Jira/Slack.
• Тестирование и обучение команды.
• Передача документации и доступов.
• Гарантия стабильной работы и поддержка после внедрения.
• Наши инженеры имеют сертификации PagerDuty и опыт более 50 интеграций.

Получите консультацию по оптимизации инцидент-менеджмента. Свяжитесь с нами для аудита вашей системы — мы оценим инфраструктуру и предложим оптимальную конфигурацию за 1–2 дня. Закажите интеграцию PagerDuty под ключ и получите снижение MTTR в 3–5 раз.

Техническая поддержка сайта: обновления, мониторинг, 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 раз быстрее реагирует на сбои, чем ручная проверка.