newsmode
search
Меню
arrow_back Назад

Stop monitoring systems; start monitoring outcomes

auto_awesomeКраткое саммари

Команда Intercom рассказывает о «метриках пульса» (heartbeat metrics) — ключевых сигналах, которые мгновенно показывают, выполняет ли система свою главную задачу для клиентов. Для Intercom такая метрика — частота новых сообщений и ответов, а для AI-агента Fin — успешные AI-ответы; при их падении инженеры реагируют немедленно, не дожидаясь жалоб. Подобный подход используют Amazon (объём заказов) и Affirm (попытки оформления заказа). На основе нескольких метрик пульса Intercom отслеживает работу Fin, Inbox, Web Messenger и Mobile Messenger, а также определяет два независимых SLA — Core Platform SLA и Fin SLA. При срабатывании алерта система автоматически откатывает свежий код, создаёт инцидент в incident.io и предлагает первые действия; в инциденте 24 апреля проблему с Inbox устранили за 10 минут. В отличие от статус-страниц, проверяющих лишь ответ сервера (HTTP 200), метрики пульса измеряют реальный результат для клиента, и автор предлагает плейбук для создания собственной такой метрики.

Когда через вашу платформу ежедневно проходят миллионы разговоров, надёжность — это не просто технический показатель, а основа доверия клиентов.

В Intercom, где наш AI-агент Fin автономно решает миллионы клиентских запросов, надёжность начинается с одного главного вопроса: могут ли наши клиенты делать ту работу, ради которой они нас наняли?

Этот вопрос привёл нас к разработке того, что мы называем «метриками пульса» (heartbeat metrics) — жизненных показателей, которые мгновенно сообщают нам, действительно ли наши системы выполняют своё предназначение. Эти метрики прорезаются сквозь шум сложных дашбордов мониторинга и дают немедленную ясность относительно влияния на клиента. Когда метрика пульса падает, мы не ждём жалоб клиентов. Мы действуем немедленно.

В этом посте я разберу, что такое метрики пульса, как мы используем их для определения SLA нашего Fin и платформы, и как вы можете создать собственный «пульс», чтобы держать ваши инженерные команды слаженными, а клиентов — довольными, даже по мере того как ваши системы становятся всё сложнее.

Что такое метрика пульса?

Современные системы сложны. Логи, дашборды и трассировка помогают отлаживать проблемы, как только вы о них узнали. Метрики пульса нужны для того, чтобы ускорить обнаружение и понимание влияния на клиента. Думайте об этом как о проверке пульса. Если пульс слабеет, ваши клиенты чувствуют это мгновенно. Метрика пульса — это самый чёткий сигнал, который вы можете получить о том, что ваш продукт жив и делает свою работу.

Для Intercom эта работа — разговоры. Поэтому наша основополагающая метрика пульса — это частота новых сообщений и ответов по всему Intercom. Для Fin это успешные AI-ответы. Если они проседают, это бьёт по вашей способности устанавливать связь. Это может быть переключение базы данных на резервную, неправильно сконфигурированный флот серверов или плохое изменение в коде — неважно. Важно то, что это бьёт по способности клиентов пользоваться Intercom.

Мы не одиноки в том, что имеем подобную концепцию. Amazon отслеживает объём заказов как свой пульс. Affirm следит за попытками оформления заказа. Если эти цифры падают ниже ожидаемого уровня, они не ждут тикета в поддержку, а сразу начинают разбираться. Потому что знают, что от этого зависит успех их клиентов.

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

Напрямую связана с ценностью для клиента: она должна отражать главную работу, ради которой наняли ваш продукт. Высокообъёмная и предсказуемая: объём позволяет системе обнаружения аномалий быстро замечать небольшие отклонения. Бинарная по духу: вам нужна метрика, у которой падение явно сигнализирует о поломке, а не просто о том, что «чуть медленнее обычного».

Мы обнаружили, что наличие метрики пульса:

Обнаруживает проблемы быстрее, чем когда-либо могли бы сообщения пользователей или тикеты в поддержку. Удерживает наш фокус на том, что действительно важно для наших клиентов. Напрямую связана с нашим SLA. Это способ нашей системы сказать: «Да, обещание, которое мы дали клиентам, выполняется».

Конечно, мы по-прежнему мониторим всё привычное: задержки, частоту ошибок, состояние инфраструктуры и так далее. Метрики пульса не заменяют их — они их дополняют. Это ваш короткий путь к быстрому пониманию влияния на клиента.

Множество пульсов: как мы мониторим

Надёжная инженерия в масштабе означает признание того, что сложным системам нужно несколько жизненных показателей. Хотя концепция проста, реализация требует внимательного учёта того, что действительно важно для клиентов.

В Intercom мы начали с простого: создают ли клиенты сообщения с ожидаемой частотой?

Этот сигнал оказался настолько сильным, что мы разбили его дальше, отслеживая разные метрики пульса по ключевым системам Intercom.

Каждая из наших метрик пульса даёт нам отдельный угол зрения на то, могут ли пользователи Intercom — как люди, так и AI — делать то, что им нужно:

Fin отвечает вашим клиентам. Сотрудники отвечают в Inbox. Сотрудники взаимодействуют с интерфейсом Inbox. Пользователи на вашем сайте могут писать через Web Messenger. Пользователи в вашем приложении могут писать через Mobile Messenger.

Вместе эти метрики формируют более полную картину общего состояния Intercom. Если падает хотя бы одна из них, это серьёзная проблема, затрагивающая клиентов.

От обнаружения к действию

Когда срабатывает тревога по пульсу, скорость решает всё.

После месяцев надёжного сигнала о её эффективности мы подключили её к автоматизации, чтобы быстрее устранять проблемы, при этом инженеры всегда перепроверяют результат. Вот что происходит, когда метрика пульса падает:

Если мы только что развернули новый код в продакшен, мы автоматически откатываем его. Откат недавних изменений — это безопасная и быстрая операция. Мы автоматически создаём инцидент в incident.io и вызываем по пейджеру инженеров и командира инцидента. Если эта тревога сработала, скорее всего, нам понадобится полное реагирование на инцидент, включая обновления статус-страницы. Система автоматически предлагает первичные действия тем, кто реагирует первым. Например, мы используем функцию Investigations от incident.io, чтобы получить фору в поиске первопричин.

Этот автоматизированный отклик безупречно проявил себя во время недавнего инцидента:

24 апреля проблема на сервере замедлила работу Inbox, что повлияло на способность сотрудников пользоваться Inbox. Наши метрики пульса быстро это поймали, и мы устранили проблему за 10 минут. На втором графике видно, что обмен сообщениями с конечными пользователями не пострадал. Этот инцидент засчитался как простой в нашем SLA, и мы публично поделились полным анализом первопричин здесь.

SLA, основанные на пульсе

Наши метрики пульса не просто мониторят — они также определяют наши SLA, удерживая нас в ответственности перед клиентами. Мы используем эти важные метрики для измерения двух независимых SLA:

SLA основной платформы (Core Platform SLA): если ваша команда не может отвечать в Inbox или клиенты не могут писать через Messenger — это простой. Fin SLA: если Fin не может генерировать текстовые ответы, мы фиксируем простой.

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

Измерение имеет значение. Многие статус-страницы остаются зелёными, пока HTTP-проба возвращает 200 OK, даже когда пользователи застряли. Метрики пульса закрывают этот разрыв, проверяя реальные результаты для клиента, а не просто ответы сервера.

Мы не просто высматриваем абсолютные падения до нуля. Мы используем обнаружение аномалий, отслеживая ожидаемые паттерны сообщений во времени и отмечая, когда что-то выглядит не так. При необходимости у нас есть дополнительный инструментарий, который позволяет спуститься на уровень отдельного клиента, чтобы расследовать индивидуальное влияние.

Плейбук для построения собственного пульса надёжности

Если у вас ещё нет метрики пульса, начните с простого. Вот наш плейбук:

Определите обязательную задачу вашего продукта: что то единственное, чего клиентам абсолютно необходимо достичь, чтобы добиться успеха с вашим продуктом? Выберите метрику с объёмом: вам нужно что-то достаточно предсказуемое, чтобы быстро замечать аномалии, а не только полные отказы. Сделайте её бинарной по духу: если метрика падает, это должно быть из-за того, что что-то сломалось. Привяжите её к вашим алертам: сделайте её громкой и убедитесь, что она доходит до нужных людей. Используйте её для слаженности команд: когда пульс сбивается, все должны понимать, что это значит и что делать дальше. Держитесь за неё круглосуточно: надёжность — это не работа с 9 до 5.

Вот монитор Datadog, который мы используем для пульса Inbox (синтаксис Terraform, упрощён для наглядности):

Сила метрик пульса — в их простоте. Хотя современные системы становятся всё сложнее, фундаментальный вопрос остаётся освежающе прямым: «Могут ли наши клиенты сделать то, ради чего они сюда пришли?»

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