Мониторинг отвечает на вопросы, которые мы заранее знали. Observability нужна, когда система ломается способом, которого мы не предусмотрели

Metric показывает, что тенденция изменилась.

Trace — где запрос провёл время и через какие зависимости прошёл.

Log — что конкретно произошло внутри компонента.

По отдельности каждый сигнал ограничен.

Вместе они позволяют восстановить поведение распределённой системы.

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

Correlation ID, trace context и business identifiers позволяют пройти путь конкретной операции между сервисами.

AMPE связывает техническую трассировку с бизнес-объектом, где это оправдано.

Когда инциденты долго диагностируются.

Когда команда знает, что сервис «медленный», но не знает где.

Когда alerting создаёт слишком много шума.

Когда микросервисы и async processing сделали request path неочевидным.

Когда business failures не отражаются в infrastructure metrics.

Когда нужно управлять SLO и error budget.

Когда эксплуатация зависит от нескольких людей, которые «знают, куда смотреть».

SLI — измерение фактического уровня сервиса.

SLO — целевой уровень, который команда стремится удерживать.

SLA — внешнее обязательство и последствия его нарушения.

AMPE сначала определяет, какой пользовательский результат действительно важен, и только потом выбирает измерение.

Если система стабильно значительно выше SLO, часть ресурса можно направить на изменения.

Если error budget быстро сгорает, риск дальнейших релизов становится выше.

Это не автоматическое правило остановки разработки, а общий язык между product и reliability.

Сообщение «CPU 80%» само по себе не обязательно требует человека.

Если autoscaling справляется, это telemetry.

Если рост CPU сопровождается нарушением SLO и исчерпанием capacity, появляется инцидентный смысл.

AMPE разделяет наблюдение и действие, чтобы alert fatigue не уничтожала чувствительность команды.

Сильный operational dashboard отвечает на вопросы: работает ли пользовательский результат; какой компонент ограничивает; где меняется error rate; какие зависимости нестабильны; что произошло относительно deployment или другого события.

Всё остальное может оставаться доступным для drill-down.

Business transaction получает trace context.

Metrics показывают состояние сервиса. Logs дают детали. Traces связывают путь. SLI отражает пользовательский результат. SLO задаёт норму. Alert запускает действие только при значимом отклонении.

Так observability сокращает путь от жалобы до причины.

Диагностика распределённых сбоев ускоряется.

Alerting становится тише и полезнее.

Надёжность измеряется ближе к пользовательскому результату.

Релизы легче сопоставлять с изменением поведения.

SRE получает общий язык с продуктом и бизнесом.

И главное — система перестаёт быть чёрным ящиком даже тогда, когда ломается новым способом.