Мониторинг ошибок и интеграций для сайта на 1С-Битрикс

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

Почему сбои остаются незамеченными

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

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

Что меняет полноценный мониторинг

Контур наблюдаемости смотрит на проект с нескольких сторон одновременно. Со стороны кода ошибки PHP и JS собираются в трекер и группируются: вы видите не строки логов, а список проблем с частотой, числом затронутых пользователей и привязкой к релизу. Со стороны интеграций каждая сессия обмена с 1С и каждый вызов внешнего API оборачиваются метриками, поэтому сбой выгрузки, рост таймаутов или всплеск отказов оплаты сразу заметны. Со стороны инфраструктуры под контролем очереди и агенты, где копятся фоновые задачи. А алерты по аномалиям и дашборды состояния сводят всё это в реальном времени.

Главное отличие от пинга — мониторинг отвечает не на вопрос «жив ли сайт», а на вопрос «здоров ли бизнес-процесс». Проходят ли заказы в 1С, доходят ли оплаты, отправляются ли письма, не выросло ли число ошибок после вчерашнего релиза. Это смещает фокус с формального доступа сайта на то, что реально приносит деньги, и позволяет ловить деградацию задолго до того, как она превратится в массовый сбой.

Почему мониторинг — часть зрелой поддержки

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

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

Чем мониторинг интеграций отличается от мониторинга кода

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

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

Как мы боремся с шумом алертов

У плохого мониторинга есть характерная болезнь: он шлёт столько уведомлений, что их перестают читать, и в потоке тонет реальный сбой. Мы строим алерты по аномалиям и порогам, а не по каждому событию. Единичная ошибка не повод будить дежурного, а вот всплеск числа фаталов в десять раз за пять минут — повод. Один таймаут платёжки не алерт, а рост доли отказов с одного процента до пятнадцати — алерт. Сессия обмена чуть дольше обычного — норма, а обмен, который не стартовал по расписанию или завис, — повод для уведомления.

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

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

Мы не навязываем всем максимальный пакет. Если у сайта немного интеграций и невысокий трафик, разумно начать с базового контура: трекер ошибок PHP и JS плюс алерт на всплеск пятисотых. Это уже радикально сокращает время до обнаружения и стоит недорого. По мере роста числа интеграций и нагрузки добавляются контроль обмена с 1С и внешних API, мониторинг очередей и агентов, отслеживание сбоев оплат и доставки. На самых ответственных проектах подключаем полную трассировку запросов, аномалии по метрикам и дежурство с разбором инцидентов. На бесплатном аудите мы честно говорим, какой контур нужен именно вам, исходя из числа интеграций, объёма заказов и цены простоя, а не из того, что выгоднее продать.

Как мы ведём подключение

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

Особое внимание уделяем тому, чтобы мониторинг не нагружал сам сайт. Сбор ошибок и метрик работает асинхронно, тяжёлые данные уходят в трекер в фоне и семплируются под высокий трафик. Доступы к трекеру, дашбордам и алертам мы передаём вам, описываем регламент реакции на инциденты и при необходимости обучаем вашу команду читать панели и реагировать. Если у вас нет своего дежурного, берём разбор инцидентов на себя в рамках тарифа.

Возражения, которые мы слышим чаще всего

«У нас и так есть логи, зачем ещё трекер». Логи — это сырьё, а трекер — инструмент работы с ним. Без группировки и приоритизации логи не помогают принять решение в момент инцидента. Трекер показывает, что массово, что ново, что выросло после релиза, и привязывает ошибку к конкретному запросу и пользователю. Разбор, который по логам занимает часы, по трекеру занимает минуты.

«Мониторинг замедлит сайт». На практике нет: сбор работает асинхронно и под нагрузкой семплируется, влияние на скорость фронта пренебрежимо мало. Зато мониторинг как раз помогает ловить замедления, а не создавать их. «Это дорого». Мы запускаем поэтапно и от базового контура, который стоит недорого и уже снимает большую часть риска. А умный расчёт на этой странице помогает прикинуть, во что вам обходятся незамеченные сбои сейчас — обычно эта цифра делает мониторинг очевидно выгодным.

Сценарии, в которых мониторинг окупается сразу

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

Третья ситуация — выкатка релиза, которая ломает один из сценариев оформления заказа. Без трекера такой баг живёт до первой жалобы, и всё это время часть пользователей не может купить. С привязкой ошибок к релизу всплеск фаталов виден сразу после деплоя, и команда чинит или откатывает за минуты. Четвёртая — застрявшая очередь уведомлений: клиенты перестают получать письма о статусе заказа, доверие падает, а формально всё работает. Мониторинг очередей подсвечивает накопление задач заранее. Во всех этих сценариях речь идёт не о теоретическом удобстве, а о прямых деньгах и репутации, которые мониторинг сохраняет.

Что вы получаете в итоге

По итогу подключения у вас появляется единая картина здоровья проекта: ошибки кода, обмен с 1С, внешние API, очереди, оплаты и доставка — на одном дашборде и под алертами. Сбои становятся видимыми раньше клиентов, инциденты разбираются по трассировке за минуты, релизы выкатываются без страха, потому что новые ошибки сразу заметны. Команда перестаёт тушить пожары вслепую и переключается на развитие. А все доступы, панели и регламенты остаются у вас, без привязки к подрядчику: развивать контур наблюдаемости сможет как наша команда, так и любая другая. Если ваш проект растёт и связей становится больше, контур расширяется вместе с ним: новые интеграции добавляются как отдельные слои наблюдения, а накопленная история ошибок и метрик помогает видеть тренды и предупреждать проблемы заранее, а не реагировать постфактум.