CRM / Bitrix24 · наблюдаемость · безопасность

Фундамент коробки Bitrix24: логи, алерты, клиент 1С и аудит безопасности

Клиент: Автомобильный маркетплейс, NDA Категория: CRM / Bitrix24 Стек: PHP 8.3, Bitrix24 D7, JSONL-логи, Telegram Bot API, nginx, cron Срок: внедрялось поэтапно

Проблема

Кастомный слой портала рос годами: около 20 самописных логгеров в 8 разных каталогах, ни одного алерта, около 50 «сырых» curl-вызовов к 1С (главный — без таймаута), 21 захардкоженный токен и 7 несогласованных нормализаторов телефона. О сбоях узнавали от менеджеров.

Ограничения

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

Что сделал

Анализ 454 PHP-файлов: общие обёртки выбраны по реальному числу вызовов, а не по вкусу
Единый JSONL-логгер со сквозным request id и маскированием ПДн; critical-ошибка сразу уходит алертом в Telegram и чат портала с дедупликацией
Стандартный клиент 1С: таймауты и повторы только для идемпотентных запросов — повторный POST создал бы в 1С второй документ
Просмотрщик логов со сквозным поиском, health-эндпоинтом для мониторинга и ротацией: первый прогон сжал 1087 МБ до 30 МБ
Аудит безопасности: закрыт анонимный доступ к действиям по сделке, приём от 1С ограничен её адресами, файлы с токенами и ПДн убраны из публичного доступа
Больше 15 кронов и утилит переведены только в CLI, ротирован вебхук, в CSV-выгрузках закрыта formula injection

Архитектура

Модули портала → Core: логгер, клиент 1С, уведомления → JSONL-логи с request id → Алерты в Telegram и чат → Просмотрщик и health

Результат

Сбои стали видны в момент возникновения, а не по жалобе: critical-ошибка приходит алертом, любой запрос прослеживается по request id. Всё найденное аудитом закрыто точечными выкладками с бэкапом — после них 0 ответов 5xx.

Что можно переиспользовать

Единый логгер с маскированием ПДн и алертами Клиент 1С с безопасной политикой повторов Просмотрщик логов с health-эндпоинтом