devnoize справочник

Что такое шум

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

Сигнал и шум

В радиотехнике шум — это случайные колебания, которые мешают принять полезный сигнал. В инженерной практике смысл похожий, но единица измерения другая: не мощность, а внимание человека. Будем называть сигналом сообщение системы, которое приводит к полезному действию или меняет решение того, кто его прочитал. Шум — сообщение, которое прочитано (или должно было быть прочитано), но ни к какому действию не привело.

Определение намеренно привязано к действию, а не к содержанию. Одна и та же строка «диск заполнен на 85%» может быть сигналом для команды, которая через неделю упрётся в предел, и шумом для команды, у которой автоматическое расширение тома срабатывает на 90%. Поэтому невозможно составить универсальный список «шумных» сообщений: шум определяется только в контексте того, кто сообщение получает и что он может сделать.

Отсюда первое практическое правило: у каждого сообщения должен быть адресат и ожидаемое действие. Если для алерта, письма или строки лога невозможно ответить на вопрос «кто это прочитает и что сделает», сообщение почти наверняка является шумом.

Два вида ошибок

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

Интуитивная реакция на пропущенный инцидент — добавить ещё один алерт или понизить порог. Каждое такое решение по отдельности разумно, но их сумма даёт систему, которая срабатывает постоянно. Цена ложного срабатывания при этом кажется нулевой: ну пришло лишнее уведомление, ничего страшного. На деле цена есть, просто она отложена.

Усталость от алертов

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

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

Как измерить шум

Шум можно и нужно считать. Достаточно трёх показателей, которые собираются без специальных инструментов.

  1. Доля действий (actionability rate): какая часть сработавших алертов привела к действию человека — исправлению, откату, изменению конфигурации. Считается по журналу дежурств. Хороший ориентир — выше 70%; ниже 30% означает, что большая часть вызовов бесполезна.
  2. Доля перезапусков в CI: какая часть неуспешных сборок была перезапущена без изменений в коде и затем прошла. Каждый такой случай — признак нестабильного теста или окружения.
  3. Объём логов на запрос: сколько байт логов в среднем пишется на один обработанный запрос. Показатель сам по себе мало что значит, но его рост без роста функциональности почти всегда означает, что кто-то оставил отладочный вывод.

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

json
{
  "alert": "CheckoutErrorRateHigh",
  "fired_at": "2026-03-11T02:14:09Z",
  "acknowledged_at": "2026-03-11T02:19:40Z",
  "outcome": "action",
  "action": "rollback of release 4.18.2",
  "notes": "error rate returned to baseline in 6 minutes"
}

Если такие записи хранятся по одной на строку (формат JSON Lines), а outcome принимает значения action, no_action или duplicate, подсчёт делается несколькими строками кода:

python
import json
from collections import defaultdict

def actionability(path):
    total = defaultdict(int)
    acted = defaultdict(int)
    with open(path, encoding="utf-8") as f:
        for line in f:
            rec = json.loads(line)
            total[rec["alert"]] += 1
            if rec["outcome"] == "action":
                acted[rec["alert"]] += 1
    for name in sorted(total, key=lambda n: acted[n] / total[n]):
        rate = acted[name] / total[name]
        print(f"{name:40} {total[name]:4}  {rate:6.0%}")

actionability("oncall-2026-q1.jsonl")

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

Откуда берётся шум

Шум редко появляется из-за одного плохого решения. Обычно он накапливается по одним и тем же причинам.

  • Асимметрия ответственности. Добавить алерт или строку лога легко и никто за это не спрашивает; удалить страшно — вдруг именно он когда-нибудь понадобится.
  • Отсутствие владельца. Правило написал человек, который давно перешёл в другую команду. Никто не знает, зачем оно, поэтому его не трогают.
  • Причины вместо симптомов. Алерт на высокую загрузку процессора срабатывает, даже когда пользователи ничего не замечают. Подробнее — в главе «Алерты».
  • Копирование конфигурации. Набор правил переносится из проекта в проект вместе с порогами, подобранными под совершенно другую нагрузку.
  • Отладка, оставленная в коде. Подробный вывод, добавленный для расследования, остаётся навсегда. Подробнее — в главе «Логи».

Принципы, на которых построен справочник

Все последующие главы опираются на несколько идей, которые полезно держать в голове.

  • Удаление — нормальная операция. Правило, которое ни разу не сработало по делу за квартал, нужно удалить или переписать. Если оно всё же понадобится, его можно восстановить из истории конфигурации.
  • У каждого сообщения есть владелец. Для алерта — команда, для строки лога — модуль, для проверки в CI — тот, кто её добавил.
  • Ревизия по расписанию. Шум возвращается, если его не убирать регулярно. Для этого есть чек-листы.
  • Машина проверяет то, что может проверить машина. Всё, что формализуемо — стиль кода, формат конфигов, простые ошибки, — должно проверяться автоматически, до того как на это посмотрит человек.

Итог

  • Шум — это сообщение, не приводящее к действию. Он определяется контекстом получателя, а не содержанием сообщения.
  • Ложные срабатывания не бесплатны: они снижают внимание к настоящим сигналам, и система начинает вести себя так, будто пропускает проблемы.
  • Шум измеряется: доля действий по алертам, доля перезапусков в CI, объём логов на запрос.
  • У каждого алерта, лога и проверки должен быть владелец, а у каждого набора правил — регулярная ревизия.