В мире DevOps и SRE логи давно перестали быть «просто текстом». Это сигнальная система, нервная сеть продакшна. И именно поэтому мысль, сформулированная Chris Siebenmann, звучит почти как аксиома, которую почему-то регулярно игнорируют:
если событие не требует обязательного исправления — это не ERROR.
На первый взгляд — занудство. На практике — разница между управляемой системой и хаосом.
🔊 Когда ERROR превращается в шум
Многие сервисы сегодня логируют как ERROR всё подряд:
⚙️ временно недоступный внешний сервис
🌐 неответивший удалённый хост
📨 не доставленное письмо
⏱️ таймаут операции, которая будет повторена
Формально — «ошибка операции».
Фактически — система работает ровно так, как задумано.
И вот здесь начинается беда:
когда ERROR перестаёт означать «сломалось», он перестаёт что-либо означать вообще.
🧠 Два типа ошибок, которые постоянно путают
Один из самых важных тезисов статьи — различие уровней ответственности:
🧩 ошибка операции — конкретное действие не удалось
🏗️ ошибка программы — система в целом работает неправильно
Если SMTP-клиент не смог достучаться до чужого сервера — это проблема операции.
Если SMTP-клиент не стартует из-за битого конфига — это проблема программы.
Логировать оба случая как ERROR — значит обманывать оператора.
🔥 Почему админы начинают игнорировать логи
Системные администраторы — не роботы. У них формируется рефлекс:
📛 ERROR не требует действий
📛 ERROR — это «так всегда»
📛 ERROR можно не смотреть
И в момент, когда появляется настоящая авария, она тонет в потоке фальшивых тревог.
Мой личный опыт полностью подтверждает это:
если сервис кричит постоянно — его перестают слышать.
🛠️ Каким ERROR должен быть на самом деле
Настоящий ERROR — это всегда:
🧯 «я сломан»
🧯 «без вмешательства не починюсь»
🧯 «человек может что-то сделать»
Примеры корректных ERROR-событий:
💥 не удалось прочитать конфигурацию
💥 закончилась память
💥 повреждён файл данных
💥 нарушена внутренняя инварианта
Если оператор не может исправить ситуацию — это либо не ERROR, либо повод выкинуть программу.
📊 WARNING — недооценённый уровень
WARNING — это не «младший ERROR». Это диагностический сигнал:
⚠️ что-то пошло не идеально
⚠️ возможна деградация
⚠️ стоит обратить внимание
Именно сюда должны попадать:
🌐 проблемы с внешними зависимостями
🔁 повторяемые сбои с ретраями
📉 временные аномалии
WARNING — это информация для анализа, а не сирена.
🧩 Логи — это интерфейс, а не отладка
Очень точное замечание Siebenmann:
если логи нужны только разработчику, дайте возможность их отключить.
Продакшн-логи — это API между программой и человеком.
И как любой API, он должен быть:
📐 предсказуемым
📐 семантически точным
📐 устойчивым к злоупотреблению
ERROR — самый дорогой сигнал в этом интерфейсе. Его нельзя разбрасывать.
🔚 Итог
Правильное логирование — это не про уровни, а про уважение к тем, кто будет эти логи читать.
Если ERROR не требует немедленного исправления — это ложь.
А ложь в логах всегда заканчивается одинаково:
настоящую проблему замечают слишком поздно.
Иногда лучший способ повысить надёжность системы —
не переписать код, а переименовать сообщения в логах.
🔗 Ссылки
- Оригинальная статья Криса Зибенманна:
https://utcc.utoronto.ca/~cks/space/blog/programming/ErrorsShouldRequireFixing