Сайт запущен, поздравления розданы, команда выдохнула. А через три дня клиент пишет, что не может оплатить заказ, — и выясняется, что платёжный шлюз отвалился ещё вчера вечером, обмен с 1С встал, а вы узнали об этом последними. Запуск — это не финиш, а старт самого рискованного периода, когда всплывает всё, что не проявилось на тесте.
Эта статья — о том, как настроить мониторинг доступности и алерты после запуска магазина на 1С-Битрикс, чтобы узнавать о проблемах первыми, а не от рассерженных клиентов. Разберём, что и как проверять, как обмен с 1С и оплата попадают под наблюдение и как выстроить реакцию на инцидент. Материал опирается на нашу практику автоматизации на 1С и сопровождения проектов после запуска.
Коротко
- Запуск открывает самый рискованный период — мониторинг нужно включать сразу, а не «когда-нибудь потом».
- Следите на двух уровнях: доступность (сайт открывается) и здоровье (заказы, оплата и обмен работают).
- Обмен с 1С и оплата — самые уязвимые точки: они ломаются тихо, поэтому нужны отдельные проверки.
- Алерт должен означать «нужно действовать»: убирайте ложные срабатывания, иначе на уведомления перестанут реагировать.
Почему запуск — это только начало
На тестовом окружении магазин ведёт себя иначе, чем в бою. Реальная нагрузка, живые платежи, настоящий обмен с 1С, поведение тысяч посетителей — всё это проявляется только после запуска. Первые недели вскрывают то, что невозможно было увидеть заранее: пиковые нагрузки, редкие сценарии, хрупкие интеграции.
Без мониторинга магазин работает вслепую. Проблема существует ровно столько, сколько нужно клиенту, чтобы её заметить и пожаловаться, — а это часы потерянных заказов и подорванного доверия. Мониторинг меняет уравнение: вы узнаёте о сбое первыми и чините его до того, как он превратится в поток обращений в поддержку.
Два уровня: доступность и здоровье
Мониторинг магазина работает на двух разных уровнях, и путать их нельзя.
| Уровень | На какой вопрос отвечает | Что проверяет |
|---|---|---|
| Доступность (uptime) | Сайт вообще открывается? | Ответ сервера, код ответа, время загрузки |
| Здоровье приложения | Ключевые сценарии работают? | Заказ, оплата, обмен, цены, поиск |
| Инфраструктура | Хватает ли ресурсов? | CPU, память, диск, база, очереди |
Ключевая ловушка — считать, что «сайт пингуется, значит, всё хорошо». Магазин может отдавать HTML и при этом не принимать заказы: оплата отвалилась, обмен встал, цены устарели. Поэтому одного uptime мало — нужен мониторинг именно бизнес-сценариев.
Что проверять на магазине 1С-Битрикс
Минимальный полезный набор проверок для интернет-магазина на 1С-Битрикс выглядит так:
- Доступность ключевых страниц. Главная, каталог, карточка товара, корзина — открываются и отдают контент.
- Сквозной заказ. Тестовое оформление проходит все шаги до подтверждения.
- Оплата. Платёжный шлюз доступен и обрабатывает транзакции.
- Обмен с 1С. Последний успешный обмен был недавно, очередь заказов не растёт.
- Свежесть данных. Цены и остатки соответствуют учётной системе.
- Поиск и фильтр. Каталог отвечает, умный фильтр работает.
- Время ответа. Страницы открываются в пределах нормы, нет деградации.
Важно проверять сценарии целиком, а не по кусочкам. «Каталог отдаётся» ещё не значит «в нём правильные цены», а «форма заказа открылась» — не значит «заказ создаётся». Синтетические проверки, имитирующие действия покупателя, надёжнее простого пинга.
Мониторинг обмена с 1С
Обмен с 1С — одна из самых коварных точек. Он ломается тихо: сайт работает, посетители ходят, но цены и остатки застывают на позавчерашних значениях, а новые заказы не уходят в учётную систему. Клиент оформляет товар, которого уже нет, менеджер не видит заказ — и всё это без единой явной ошибки на сайте.
Поэтому обмен CommerceML держат под отдельным наблюдением:
- Время последнего успешного обмена. Если он не проходил дольше нормы — тревога.
- Размер очереди заказов. Заказы, не выгруженные в 1С, не должны копиться.
- Ошибки обмена. Сбои сессии обмена логируются и попадают в алерты.
- Расхождение данных. Контрольные сверки остатков и цен между сайтом и учётом.
Молчаливо остановившийся обмен — классическая причина проблем, которые замечают слишком поздно. Про безопасную и надёжную организацию интеграционных вызовов мы писали в статье про REST, вебхуки и безопасность в Битрикс.
Оплата и заказы под наблюдением
Оплата — то, ради чего магазин существует, и её сбой бьёт по выручке напрямую. Здесь важно следить не только за доступностью шлюза, но и за успешностью транзакций.
- Доступность платёжного провайдера. Шлюз отвечает и принимает запросы.
- Доля успешных оплат. Резкое падение конверсии в оплату — сигнал проблемы.
- Обработка колбэков. Уведомления от провайдера доходят и корректно меняют статус заказа.
- Зависшие заказы. Заказы, застрявшие в промежуточном статусе, выявляются автоматически.
Отдельно стоит следить за темпом заказов. Если магазин обычно принимает определённый поток заказов, а он внезапно упал до нуля в рабочее время, это сильный косвенный сигнал: что-то сломалось, даже если формально все страницы отдаются.
Логи, ошибки и очереди
Многие проблемы видны в логах раньше, чем их замечают пользователи. Систематический сбор и анализ ошибок — важная часть мониторинга здоровья:
- Ошибки приложения. Рост числа фатальных ошибок PHP или исключений — ранний признак деградации.
- Ошибки веб-сервера. Всплеск ответов 5xx означает, что часть запросов не обслуживается.
- Медленные запросы. Тяжёлые обращения к базе, которые начинают тормозить витрину.
- Размер очередей. Агенты Битрикс, отложенные задачи, очереди на обмен не должны накапливаться.
Отдельно стоит следить за агентами и cron-задачами: если фоновая обработка встала, это часто не видно на витрине, но постепенно ломает данные. Про надёжную выкатку изменений, чтобы релизы сами не становились источником инцидентов, мы писали в статье про CI/CD и деплой в Битрикс.
Алерты, которые не хочется отключить
Плохой мониторинг мертвеет от собственного шума. Если система шлёт десятки уведомлений в день, из которых важны единицы, их перестают читать — и пропускают настоящий инцидент. Хороший алерт означает «нужно действовать». Чтобы этого добиться:
- Перепроверяйте перед тревогой. Несколько неудачных проверок подряд, а не разовый сетевой всплеск.
- Задавайте разумные пороги. Тревога на реальное отклонение, а не на нормальные колебания.
- Группируйте события. Один инцидент — одно уведомление, а не сто писем о связанных симптомах.
- Разделяйте по важности. Критичное — в срочный канал, информационное — в фоновый.
Цель — доверие к алертам. Когда команда знает, что уведомление приходит только по делу, на него реагируют мгновенно. Как только появляется шум, скорость реакции падает до нуля.
Каналы уведомлений и дежурство
Алерт бесполезен, если приходит туда, где его не видят. Уведомления должны попадать к тем, кто может действовать, по каналам, которые реально читают:
- Срочные каналы. Мессенджер или звонок дежурному для критичных сбоев — оплата, недоступность.
- Рабочие каналы. Чат команды поддержки для важного, но не аварийного.
- Информационные сводки. Ежедневные отчёты о состоянии без немедленной реакции.
- Дежурство. Понятно, кто отвечает за инциденты в конкретный момент, включая вечера и выходные.
Отдельный вопрос — вечера, ночи и выходные, когда магазин продолжает продавать, а команда отдыхает. Для критичных проектов настраивают дежурство или сопровождение, чтобы реакция была не «утром разберёмся», а сразу.
Регламент реакции на инцидент
Когда алерт сработал, важна не паника, а порядок. Заранее описанный регламент реакции экономит драгоценные минуты и не даёт совершать хаотичные действия под стрессом. Полезный минимум:
- Классификация. Что сломалось и насколько это критично — оплата, обмен, доступность.
- Первые проверки. Короткий чек-лист «что смотреть в первую очередь» под каждый тип инцидента.
- Действия. Кто реагирует, что предпринимает, как временно снять остроту проблемы.
- Эскалация. Кого подключать, если проблема не решается в отведённое время.
- Разбор после. Что стало причиной и как не допустить повтора.
Разбор инцидентов после их устранения — недооценённая практика. Каждый сбой — это данные о слабых местах, и системный анализ причин постепенно делает магазин надёжнее.
Частые ошибки мониторинга
- Мониторят только uptime. Сайт «пингуется», но оплата или обмен сломаны — этого не видно.
- Не следят за обменом с 1С. Обмен встал тихо, данные устарели, заметили по жалобам.
- Шум из ложных алертов. Уведомлений так много, что их перестают читать.
- Алерты уходят «в никуда». В общий чат, который никто не мониторит в реальном времени.
- Нет регламента реакции. При инциденте команда действует хаотично и теряет время.
- Мониторинг настроили и забыли. Проверки устарели, новые сценарии не покрыты.
- Нет ночного дежурства. Магазин продаёт круглосуточно, а реакция только в рабочее время.
Чек-лист после запуска
- Uptime настроен. Доступность ключевых страниц проверяется с внешней точки.
- Сценарии под контролем. Заказ, оплата и поиск проверяются синтетически.
- Обмен под наблюдением. Время обмена, очередь заказов и ошибки отслеживаются.
- Оплата мониторится. Доступность шлюза и доля успешных транзакций под контролем.
- Логи собираются. Ошибки, 5xx, медленные запросы и очереди агрегируются.
- Алерты без шума. Пороги настроены, события сгруппированы, ложных срабатываний нет.
- Каналы и дежурство. Уведомления идут тем, кто действует; дежурство покрывает нерабочее время.
- Регламент готов. Порядок реакции и эскалации описан, разбор инцидентов ведётся.
Вывод
Мониторинг после запуска — это разница между «узнали первыми и починили» и «узнали от клиента, когда деньги уже потеряны». Магазин на 1С-Битрикс нужно наблюдать на двух уровнях: доступность отвечает на вопрос «открывается ли сайт», а здоровье приложения — на вопрос «может ли клиент купить». Второе важнее, и именно его чаще всего забывают.
Отдельного внимания требуют обмен с 1С и оплата — они ломаются тихо и бьют по выручке напрямую. Настройте осмысленные проверки бизнес-сценариев, уберите шум из алертов, доведите уведомления до тех, кто действует, и опишите порядок реакции. Тогда неизбежные сбои будут стоить минут, а не дней, и не превратятся в поток разочарованных клиентов.
