Почему ошибки в 1С не чинятся - и что меняет наблюдаемость

Спросите у команды, поддерживающей нагруженную 1С, сколько ошибок сейчас в проде. В большинстве случаев точного ответа не будет: “ну, что-то падает, пользователи иногда жалуются”. Ошибки есть, но их никто не считает. И это не разгильдяйство, а следствие того, что посчитать их технически неоткуда.

Разберём, почему так выходит, и что меняется, когда ошибки становятся видимыми. У этого эффекта есть цифра с нашего внедрения: число ошибок в проде за полгода снизилось в 23 раза. Не потому, что мы их чинили руками, а потому, что их стало видно.

Почему ошибки в 1С невидимы

Штатный журнал регистрации вроде бы фиксирует всё: ошибки, предупреждения, действия пользователей. Но на нагруженной базе он превращается в стог сена. Десятки миллионов событий в сутки в последовательном файле, который для отбора “покажи ошибки за вчера” приходится читать насквозь. Просмотр виснет, история глубже пары недель недоступна.

В итоге журнал формально есть, а инструмента нет. Когда случается инцидент, в журнал лезут разово, находят конкретную ошибку и закрывают вопрос. Но общей картины - сколько всего ошибок, какие повторяются, растёт их число или падает - не видит никто. А то, чего не видно, не управляется. Ошибки живут в проде годами не потому, что их сложно починить, а потому, что про большинство из них просто не знают.

Что меняется, когда ошибки видно

Мы столкнулись с этим на проекте, где выливали журнал регистрации трёх продуктивных баз в реальном времени во внешнее аналитическое хранилище (нагрузка - около 170 млн событий в сутки). Технику этого конвейера разбираем в отдельной статье про журнал регистрации; здесь важен другой, поведенческий эффект.

Как только ошибки стало видно - поиск за доли секунды, полная история, тренды по типам, - произошло то, чего никто специально не планировал. Ошибки начали чинить. Не по авралу после инцидента, а планомерно: вот топ повторяющихся, вот тренд, вот эта группа выросла после релиза. Число ошибок в проде за полгода упало с 1,4 млн в январе до 60 тысяч в июле - в 23 раза.

Ключевое тут: мы не запускали отдельный проект “чиним все ошибки”. Мы сделали их видимыми и измеримыми, а дальше сработала обычная человеческая механика. Когда проблема превращается из смутного “что-то падает” в конкретное число на графике, которое неприятно видеть большим, его начинают уменьшать.

Это называется наблюдаемость

У этого свойства есть имя - наблюдаемость (observability): способность по внешним сигналам системы понимать, что внутри неё происходит, без того чтобы лезть внутрь при каждом вопросе. Для 1С это значит: ошибки, длительные операции, таймауты, блокировки собираются туда, где их можно посчитать, построить тренд и получить сигнал, вместо того чтобы тонуть в нечитаемых логах.

Наблюдаемость меняет режим работы с системой. Без неё команда живёт реактивно: сломалось - побежали чинить, разобрались - забыли до следующего раза. С ней появляется управление: видно, что деградирует, до того как это станет аварией, видно эффект от релиза, видно, какие ошибки массовые, а какие единичные. Работа с качеством системы перестаёт быть героизмом дежурного и становится обычным процессом по цифрам.

С чего это начинается

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

Технически это не требует лицензионных вложений: стек открытый, из железа - один сервер под хранилище. Основные трудозатраты - первичная настройка конвейера и того, что вы хотите видеть на дашбордах и в алертах.

Один класс ошибок в такой конвейер не попадёт вообще, и его стоит вычистить отдельно. Это молчаливые Попытка...Исключение в прикладном коде: исключение поймано, в журнал ничего не записано, наружу уходит бессмысленный текст про уже происходившие в транзакции ошибки. Считать нечего, потому что события нет. Как их расшить и почему повтор внутри транзакции только стирает причину - разобрали в отдельной статье, там же три способа, которыми уже настроенный мониторинг отдаёт пустоту вместо событий. Ещё одна тихая пустота - загрузка, которая привезла ноль строк: как поймать её в первую ночь.

Итог

Ошибки в проде 1С копятся не потому, что их некому чинить, а потому, что их никто не видит. Сделайте их наблюдаемыми - посчитайте, постройте тренд, покажите команде, - и они начнут уменьшаться, часто без отдельного проекта “по борьбе с ошибками”. Цифра в 23 раза за полгода - это не про наш героизм, а про то, что видимая проблема притягивает решение.

Мы разворачиваем наблюдаемость нагруженных баз 1С в рамках услуги мониторинга 1С: от журнала в читаемом хранилище до Telegram-алертов и дашбордов с трендами. Оценить, что у вас сейчас видно, а что нет, можно с бесплатного экспресс-аудита.

И обратная сторона наблюдаемости, о которой говорят реже: метрика сама может врать. У нас боевой алерт месяцами питался числом, которое оказалось номером inode файла лога. Разбор этого и ещё двух таких случаев - в статье “1С:Шина в продуктиве”.