incident.io рассказала, как меряет надёжность on-call: клиент важнее контроля
Большинство сервисов хвастается 99,99% uptime. Но incident.io предлагает мерить не доступность API, а опыт дежурного: дошло ли уведомление, и дошло ли вовремя.
Когда сервис пишет в SLA 99,99% uptime, это звучит убедительно. Но представьте: API работает, алерт ушёл, а дежурный не проснулся, потому что push-уведомление застряло в единственном провайдере. Для инцидента разницы нет: он не был обнаружен вовремя.
Компания incident.io, которая делает платформу для управления инцидентами и дежурствами, опубликовала разбор того, как её команда измеряет надёжность продукта On-call. Главный тезис: мерять нужно не то, что контролируешь, а то, что чувствует клиент.
Ключевые выводы
incident.io сводит надёжность on-call к двум вещам: приём алертов и доставка уведомлений дежурным.
Вместо uptime API они меряют «хорошие минуты»: долю времени, когда ошибка приёма алертов ниже 10%.
За сбои сторонних провайдеров отвечает сам сервис: active-active redundancy для SMS/звонков.
Пользовательские задержки в escalation-цепочках вычитаются из общей задержки, чтобы измерять реальное время обработки.
Цель SLO — 99,99% в месяц для приёма алертов и для задержки уведомлений менее 5 минут.
Две метрики, которые на самом деле важны
У on-call продукта много функций: расписания дежурств, запросы замены, escalation-цепочки. Но с точки зрения надёжности incident.io оставляет только две критические операции: приём алертов и своевременная доставка уведомлений.
Для них выбраны два SLI — индикатора уровня сервиса: доступность приёма алертов и доля уведомлений, доставленных быстрее 5 минут. Внутренний SLO для обоих — 99,99% в месяц.
Приём алертов: измеряйте «хорошие минуты»
Классический SLI для HTTP API — доля ответов без ошибок:
Проблема в том, что эта метрика не видит ситуаций, когда запрос не дошёл до приложения. Например, если load balancer неправильно маршрутизирует трафик, application-метрики покажут ноль ошибок — просто потому, что запросов не было.
incident.io наблюдает трафик на уровне GCP load balancer — ближе к клиенту, чем application layer. Но и здесь есть шум: кратковременные сетевые блики, которые самолечатся за секунды. Чтобы не гоняться за каждым пиком, они меряют не запросы, а минуты:
Месяц делится на минуты. Минутка считается «хорошей», если доля ошибок в ней меньше 10%. Такой подход мотивирует и клиентов строить отказоустойчивую отправку алертов — с retries и backoff.
Третьи стороны: «не наша вина» не работает
Со стороны уведомлений вопрос сложнее: когда останавливать таймер? Простой ответ — когда уведомление передано провайдеру вроде Twilio или APNs. Если провайдер упал, разве это вина сервиса?
incident.io считает, что вина не важна — важен результат. Для SMS и звонков они используют двух провайдеров active-active: если один не справляется, срабатывает другой. Этот пробел они закрыли после инцидента в октябре 2025 года, когда единственный telecom-провайдер попал под AWS-аутедж.
Для push-уведомлений на iOS есть только один APNs, поэтому полную redundancy не построишь. Выход — подталкивать пользователей настроить несколько каналов: push, SMS и звонок одновременно. Так уведомление считается доставленным, когда его подтвердил хотя бы один провайдер.
Пользовательские задержки: как мерить то, что спрятано
Продукт позволяет гибко настраивать escalation. Например: сначала push и SMS, через 2 минуты — звонок. Если мерить время от алерта до звонка наивно, получится ложная задержка в те самые 2 минуты.
incident.io вычитает все намеренные задержки из общего времени:
Это означает: если звонок должен был прийти через 2 минуты, а пришёл через 7, — реальная задержка 5 минут, а не 7. «Это сложно мерить» не проходит краснолицый тест: компания сама рекомендует многоуровневые уведомления, поэтому должна нести ответственность и за их надёжность.
А что в России?
У нас типичная картина: Prometheus + Alertmanager шлют алерты в Telegram-бот или корпоративный мессенджер. Часто дежурство сводится к «если бот молчит — значит, всё нормально». Но мало кто меряет, доходит ли уведомление до человека, а не просто уходит ли HTTP-запрос.
Из статьи incident.io можно вынести три практических шага для российских команд:
- Меряйте доставку уведомлений, а не только отправку. Если дежурный не подтвердил получение — это инцидент для мониторинга.
- Стройте redundancy каналов. Telegram, SMS через провайдера, звонок — минимум два независимых пути.
- Учитывайте настроенные задержки в SLO. Иначе вы будете наказывать себя за собственные best practices.
Ещё один момент: российские облачные провайдеры и telecom-операторы тоже падают. Поэтому active-active между двумя SMS-провайдерами или fallback на звонок — не перестраховка, а норма.
Часто задаваемые вопросы
Что такое SLI, SLO и SLA в контексте on-call?
SLI — это измеряемый показатель (например, доля доставленных уведомлений). SLO — целевое значение SLI, например 99,99% в месяц. SLA — обязательство перед клиентом, часто с финансовыми последствиями при нарушении.
Почему incident.io меряет «хорошие минуты», а не запросы?
Чтобы отсеять кратковременные самолечащиеся сбои и фиксировать реальное влияние на клиента. Минута считается хорошей, если доля ошибок в ней ниже 10%.
Как быть с push-уведомлениями, если APNs единственный?
Нельзя сделать redundancy провайдера, но можно дублировать каналы: push + SMS + звонок. Уведомление считается доставленным, если подтвердил любой канал.
Как вычитать пользовательские задержки из SLO?
Нужно просуммировать все намеренные задержки в escalation-цепочке и вычесть их из фактического времени доставки. Остаётся только время обработки сервисом.
Выводы
Подход incident.io — хороший пример того, как техническая метрика перестраивается в метрику клиентского опыта. Вместо «наш API работает» — «алерт дошёл и дежурный его увидел вовремя». Вместо «провайдер виноват» — «у нас есть fallback». Вместо «это сложно мерить» — «мы меряем честно».
Customer outcomes matter more than any individual piece of the machine.
Источник: incident.io — Customers over control: how we measure On-call reliability.
Если у вас есть дежурства, пересмотрите свои SLO: они меряют опыт пользователя или просто красивые цифры для дашборда?
