Цели по качеству обслуживания

Что обещано

Показатель	Цель	Как считается
Доступность	99,5 % за 30 дней	доля запросов без ответа с кодом 5xx
Время ответа	99 % быстрее 300 мс	доля запросов в корзине гистограммы le=0.3
Обращения в срок	95 % за сутки	доля обращений, закрытых до истечения 20 минут

Цель 99,5 % выбрана не «для солидности». Она означает бюджет ошибок в 0,5 %: за тридцать дней это 3 часа 39 минут полной недоступности. Такой бюджет реалистичен для одного узла без резервирования и оставляет право на плановые работы. Обещать 99,99 % на стенде с одним узлом было бы неправдой.

Бюджет ошибок и скорость его прожигания

Оповещать по одиночному всплеску ошибок бессмысленно: дежурный получит письмо на каждую сетевую заминку и через неделю перестанет их читать. Поэтому правила смотрят не на факт ошибок, а на скорость расхода бюджета — во сколько раз она превышает допустимую.

flowchart LR
    A["Доля ошибок<br/>за 5 минут"] --> C{"> 14,4 × 0,5 %<br/>в обоих окнах?"}
    B["Доля ошибок<br/>за 1 час"] --> C
    C -->|да, дольше 2 минут| D["Критическое<br/>оповещение"]
    E["Доля ошибок<br/>за 30 минут"] --> G{"> 6 × 0,5 %<br/>в обоих окнах?"}
    F["Доля ошибок<br/>за 6 часов"] --> G
    G -->|да, дольше 15 минут| H["Предупреждение"]

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

Пара окон в каждом условии нужна, чтобы оповещение и появлялось быстро, и само исчезало после того, как проблема прошла. Короткое окно даёт скорость, длинное отсекает шум.

Правила расчёта показателей

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

- record: metroskop:errors:ratio_rate5m
  expr: |
    (sum(rate(http_server_requests_seconds_count{namespace="metroskop",outcome="SERVER_ERROR"}[5m])) or vector(0))
    /
    clamp_min(sum(rate(http_server_requests_seconds_count{namespace="metroskop"}[5m])), 0.001)

В этом выражении две защиты, и обе появились после того, как дашборд показал «нет данных» на исправном сервисе:

• or vector(0) — когда ошибок нет вовсе, числитель пуст, а пустота в делении даёт пустоту. Правильный ответ здесь — ноль, а не отсутствие данных;
• clamp_min(..., 0.001) — знаменатель не может стать нулём при полном отсутствии трафика, иначе получилось бы деление на ноль.

Оповещения помимо бюджета ошибок

Бюджет ошибок ловит то, что видит посетитель. Остальные правила ловят то, что он ещё не заметил, но заметит через несколько минут.

Правило	Условие	Почему важно
MetroskopTickLagHigh	95-й перцентиль опоздания такта > 350 мс	поезда начинают двигаться рывками
MetroskopStreamStalled	такт выполняется реже двух раз в секунду	карта замерла, хотя сервис отвечает
MetroskopHeapNearLimit	куча заполнена больше 90 % пять минут	впереди перезапуск по лимиту памяти
MetroskopGcTimeHigh	сборка мусора занимает больше 15 % времени	полезной работы остаётся меньше
MetroskopNoTrainsDuringService	нет составов в часы работы метро	сервис отвечает, но не выполняет работу
MetroskopIncidentsOverdue	больше 25 просроченных обращений	очередь разбирается медленнее, чем растёт
MetroskopNodeMemoryLow	доступно меньше 8 % памяти узла	начнётся вытеснение подов
MetroskopSwapHeavilyUsed	подкачка занята больше 60 % четверть часа	памяти не хватает по-настоящему
MetroskopCertificateExpiringSoon	сертификат истекает раньше недели	автоматическое обновление не сработало

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

Куда уходят оповещения

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