Реагування на інциденти

Ескалація, що працює, поки хтось не підтвердить

Використовуйте WardenPoint як шар сповіщень для вашого реагування на інциденти. Підтвердження закриває ланцюг; resolve-хуки його скасовують; журнал аудиту живить ваш post-mortem. Тихі години та пауза шанують час чергового, не блокуючи P1 — критичний пріоритет завжди оминає.

Почати безкоштовно Поговорити з incident-lead
З урахуванням підтверджень Багатоканальний ланцюг Timeline, готовий до аудиту

Timeline інциденту

  1. 00:00
    Джерело
    Sentry critical error · ChargeFailedException spike
  2. 00:02
    WardenPoint
    Telegram + голос до чергового координатора інциденту
  3. 00:07
    Commander
    Acks · відкриває оперативний штаб · команда платежів
  4. 00:18
    Джерело
    Resolved hook · WardenPoint скасовує chain · audit закривається

Де команди реагування страждають

Біль реагування на інциденти — і що ми міняємо

Три скарги від лідерів реагування на інциденти про їхній поточний шар сповіщень.

Втома від сповіщень притуплює сигнал

Критичні alerts накладаються на галасливі warnings. Чергові перестають їм довіряти; SLA страждає.

Fix

Тільки severity=critical палить голос. Severity — контракт, не натяк.

Немає структурованого timeline

Автори post-mortem зшивають Slack scrollback-и, експорти PagerDuty і email-треди.

Fix

Один журнал аудиту на UUID інциденту. Кожне відправлення, підтвердження і resolve — рядок поряд.

Прогалини у hand-off

Коли черговий передає інцидент спеціалісту, alerts продовжують будити не ту людину.

Fix

Ручне підтвердження зупиняє ланцюг; новий ланцюг стартує до нового одержувача. Без залишкових retry.

Політика ескалації

Рецепт: ескалація координатора інциденту

Підходить командам з роллю Координатор інциденту. Ланцюг починається голосно й стає голоснішим, але зупиняється щойно хтось бере ownership.

  1. 1
    На хвилині
    0:00

    Primary IC голосом + Telegram

    Хто IC на ротації — отримує дзвінок і Telegram-повідомлення одночасно.

    voice_calltelegram_voice
  2. 2
    На хвилині
    0:03

    Backup IC голосом

    Якщо не підтверджено — резервний IC отримує виклик. Email падає на war-room канал.

    voice_callemail
  3. 3
    На хвилині
    0:08

    Розбудити менеджера

    Менеджер інженерів отримує дзвінок. У цю хвилину ситуація має очевидні staffing-наслідки.

    voice_call
  4. 4
    На хвилині
    0:15

    Виклик чергового директора

    Остання інстанція. Рідко тригериться; тестується щоквартально через 'Надіслати тест'.

    voice_calltelegram_voicesms

Джерела інцидентів

Звідки приходять інциденти

IR-команди мають приймати сигнали звідусіль — моніторинг, error tracking, uptime, business metrics.

Grafana
Метрики + логи
Sentry
Application errors
Prometheus
Alertmanager
Uptime Kuma
Endpoint uptime
Webhooks
Виявлення аномалій

Що зміниться

Що IR-команди звітують

Швидші підтвердження

Доставка спочатку по телефону невеликій групі визначених одержувачів скорочує час між надсиланням alert і підтвердженням.

Timeline, придатний для аудиту

Post-mortems тягнуть структурований журнал аудиту напряму. Без археології «хто і коли отримав виклик».

Ланцюг чисто зупиняється

Підтвердження — канонічне. Без двох чергових, які думають, що вони ще на гачку.

FAQ IR

Питання incident-response

Кожен інцидент має свій UUID і свій ланцюг ескалації. Підтвердження одного не впливає на інші. Одержувачі бачать окремі alerts.
Безкоштовний план

Спробуйте ланцюг, що зупиняється, коли хтось бере інцидент на себе

Підключіть приклад політики, надішліть тест через curl і подивіться, як audit timeline рендериться в реальному часі.

Почати безкоштовно Поговорити з incident-lead
  • Підтвердження скасовує ланцюг
  • Auditable timeline
  • Чисті передачі змін