Как вы выявляете проблемы до того, как на них пожалуются пользователи?

Question

Accepted Answer

Цель состоит в том, чтобы выявить проблемы **до выхода страницы в production** — найти деградацию, пока есть запас прочности для её поглощения. Это означает мониторинг **ведущих индикаторов**, определение **SLO с бюджетами ошибок** и активное тестирование системы вместо ожидания отказа.

## SLO и бюджеты ошибок

**SLO** превращает надёжность в число (например, 99,9% запросов успешны). Оставшиеся 0,1% — это ваш **бюджет ошибок**. Отслеживание **скорости расхода** позволяет создавать оповещения, когда вы тратите бюджет слишком быстро — задолго до того, как вы действительно нарушите SLO и пользователи это заметят.

```text
SLO 99.9% → 0.1% error budget/month (~43 min of downtime)
burn rate rising fast → you'll exhaust it in 2 days → alert NOW, while it's fixable
```

## Активное тестирование, а не только пассивные метрики

```text
SYNTHETIC MONITORING  scripted checks hit critical paths on a schedule
                      (login, checkout) → fails even at 3am with zero real traffic
HEALTH CHECKS         /healthz endpoints + dependency checks → load balancer
                      pulls bad instances before users hit them
RUM (real-user mon.)  measure latency/errors from actual browsers/devices →
                      catches issues only some users/regions see
```

Synthetic monitoring мощна, потому что она не ждёт пользователя — она непрерывно нагружает систему, поэтому неработающий checkout обнаруживается в 3 часа ночи, а не когда утром начнут жаловаться.

## Ведущие индикаторы и тренды

Ранние признаки появляются в ресурсах, а не в ошибках, видимых пользователю. Создавайте оповещения по **тренду**, а не просто по статической линии.

```text
LEADING INDICATORS   saturation (CPU/mem climbing), queue depth growing,
                     connection-pool nearing limit, latency CREEPING up
ANOMALY DETECTION    flag deviation from the normal baseline / seasonality
TREND ALERTS         "disk will fill in 4h at this rate" → act before it's full
```

Медленно растущий p99 или увеличивающаяся очередь — это предупредительный выстрел: действуя на ползучесть, вы предотвращаете отказ, к которому она приводила.

## Почему это важно

Реактивный мониторинг означает, что пользователи — ваша система оповещения — к тому времени, когда они жалуются, инцидент уже в production, и ваш бюджет ошибок потрачен. Проактивное обнаружение (скорость расхода SLO, synthetics, health checks, RUM, ведущие индикаторы, оповещения по трендам/аномалиям) даёт вам время: вы исправляете насыщающуюся очередь или ползущую задержку до того, как это станет пейджингом в 2 часа ночи и разгневанным клиентом. Это время — разница между спокойным исправлением и отказом в production.