Моніторинг інтеграцій Бітрікс24: система раннього попередження збоїв

Інтеграції — найвразливіше місце будь-якої екосистеми на базі Бітрікс24. Зламався REST-вебхук із 1С, перестав працювати конектор телефонії, помер імпорт лідів із рекламних кабінетів — бізнес не помічає це миттєво. Минає кілька годин або днів, перш ніж хтось натикається на симптом: «куди поділися заявки?», «чому оплати не відображаються в CRM?».

Ми стикалися з ситуацією, коли інтеграція з Facebook Leads працювала формально — код не падав, але токен доступу закінчився, і нові ліди не імпортувалися дві доби. Клієнт втратив 37 заявок, що при середньому чеку 15 000 рублів обернулося втраченим виторгом близько 555 000 рублів. Після цього ми впровадили моніторинг із перевіркою токена кожні 30 хвилин та алертом у Telegram. Відтоді простій жодного разу не перевищив однієї години.

Як визначити критичні інтеграції?

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

Усі інтеграції поділяються на три рівні перевірок:

• Рівень доступності: чи працює канал передачі даних? (REST endpoint відповідає, вебхук приймає запити, черга повідомлень не переповнена)
• Рівень коректності: чи передаються дані без помилок? (немає failed-записів у логах, значення полів відповідають очікуваним типам)
• Рівень актуальності: чи передаються дані вчасно? (остання синхронізація була не більше X хвилин тому, лічильник нових записів зростає)

Третій рівень часто ігнорують, і даремно. Інтеграція може «працювати» технічно, але дані надходити з 6-годинним запізненням через зависле cron-завдання.

Як налаштувати моніторинг вбудованими засобами Бітрікс24?

• Лог подій: Налаштування → Журнал подій — тут фіксуються помилки REST API, збої вебхуків, проблеми з модулями. Не найзручніший інтерфейс, але інформативний.
• Статус черги вебхуків: в On-Premise можна подивитися через таблицю b_event_message_exec — накопичення необроблених подій свідчить про проблему.
• REST API лог: за наявності додатків на marketplace логи запитів доступні через Додатки → [додаток] → Логи.

Для базового моніторингу цього достатньо, але якщо інтеграцій більше трьох, краще перейти до зовнішніх систем.

Чому зовнішній моніторинг надійніший?

Найнадійніший моніторинг — коли сама інтеграція періодично «пінгує» систему моніторингу та каже «я живий». Схема через Healthchecks.io (або аналог):

// У скрипті інтеграції (наприклад, імпорт лідів із реклами)
function syncLeadsFromAds() {
    try {
        $leads = fetchLeadsFromFacebook();
        foreach ($leads as $lead) {
            CRest::call('crm.lead.add', $lead);
        }
        // Сигнал "все добре" в систему моніторингу
        file_get_contents('https://hc-ping.com/your-uuid');
    } catch (Exception $e) {
        // Сигнал про помилку
        file_get_contents('https://hc-ping.com/your-uuid/fail');
        logError($e->getMessage());
    }
}

Healthchecks.io надсилає сповіщення, якщо сигнал не надійшов в очікуваний час. Це ловить «тихі» відмови — коли скрипт просто перестає запускатися.

Покрокове налаштування:

1. Виберіть систему моніторингу (Healthchecks.io або UptimeRobot).
2. Для кожної інтеграції створіть унікальний ping-URL.
3. Додайте в код інтеграції виклик file_get_contents(ping_url) після успішної синхронізації.
4. Налаштуйте інтервал перевірки (зазвичай 10-30 хвилин).
5. Налаштуйте алерти: Telegram, Slack або email.
6. Перевірте: зупиніть інтеграцію вручну — має прийти алерт.

Як моніторити REST API ліміти?

Бітрікс24 має ліміти REST API (згідно з REST API documentation): у хмарі — 2 запити/секунду, ліміт батч-запитів. При перевищенні повертається QUERY_LIMIT_EXCEEDED. Моніторте:

// Перевірка поточного ліміту через REST
$response = CRest::call('app.info');
// Відповідь містить REQUESTS_LEFT та TIME_RESET
$requestsLeft = $response['result']['REQUESTS_LEFT'];

if ($requestsLeft < 100) {
    sendAlert("Критично мало REST запитів: $requestsLeft");
}

Для On-Premise ліміти налаштовуються в /bitrix/admin/settings.php і значно вищі, але при інтенсивних інтеграціях все одно варто моніторити чергу.

Як створити дашборд стану інтеграцій?

Створіть внутрішню сторінку-дашборд зі статусом усіх інтеграцій. Мінімальний набір:

Будується на базі таблиці b_option (де зберігаються часові мітки останньої синхронізації) або окремої БД моніторингу.

Порівняння методів моніторингу:

Налаштуйте алерти в месенджер (Telegram-бот, Slack) — email читають рідко, у месенджер реагують одразу. Для критичних інтеграцій (платежі, ліди з реклами) SLA реакції на алерт — не більше 15 хвилин у робочий час.

Що входить у налаштування моніторингу інтеграцій

Наша команда має понад 8 років досвіду в Бітрікс24 і реалізувала більше 50 проектів з моніторингу інтеграцій. У рамках послуги ми:

• Аналізуємо поточні інтеграції та визначаємо критичні.
• Розробляємо скрипти перевірки (ping, валідація даних, вимірювання часу).
• Налаштовуємо дашборд та алерти в Telegram/Slack.
• Документуємо процедуру додавання нової інтеграції в моніторинг.
• Передаємо доступи та інструкції вашій команді.

Гарантуємо, що жоден збій не залишиться непоміченим довше 15 хвилин.

Отримайте консультацію: напишіть нам, і ми оцінимо вашу систему інтеграцій за один день. Замовте аудит інтеграцій — ми покажемо, які проблеми приховані зараз.

Техпідтримка 1С-Бітрікс: з чого починається реальна допомога

Обмін з 1С через \Bitrix\Sale\Exchange зупинився в п'ятницю ввечері. Залишки на сайті — вчорашні, клієнти замовляють товар, якого немає. Менеджер пише в чат «1С не завантажується», але проблема — в PHP-процесі, який впав через memory_limit при імпорті 40 000 SKU. На діагностику та виправлення потрібно 20 хвилин, якщо знаєш, куди дивитися. Без підтримки — до понеділка сайт торгує повітрям. Ми — команда з 7-річним досвідом обслуговування проектів на 1С-Бітрікс. За цей час провели понад 50 успішних впроваджень і врятували не один сайт від простоїв.

Чому техпідтримка 1С-Бітрікс критична?

Бітрікс — живий продукт. Виходять патчі безпеки, змінюються версії модулів, кастомізовані рішення потребують сумісності. Чим довше сайт живе без обслуговування, тим вищий ризик:

• Вразливості. Бітрікс випустив патч для модуля vote (CVE-2022-XXXX). Без підтримки його ставлять «коли руки дійдуть» — через 3 місяці. За цей час сайт можуть зламати. Ми накочуємо критичні патчі протягом 48 годин — але тільки після перевірки на staging, тому що оновлення main до 24.x ламало CIBlockElement::GetList з кастомними властивостями.
• Ліцензія. Закінчилася — втрата доступу до оновлень та маркетплейсу. Відстежуємо терміни, повідомляємо за 60/30/14 днів.
• Моніторинг. Не просто «сайт пінгується». Перевіряємо ключові сценарії: додавання в кошик (sale.basket.add), оформлення замовлення, обмін з 1С, робота пошуку. Якщо API 1С повернув 500, а сторінка віддає 200 — пінг-моніторинг цього не побачить.
• Бекапи. Створюються автоматично, але хто перевіряє відновлення? Раз на квартал розгортаємо на тестовому сервері та прогоняємо smoke-тести.

Оновлення ядра раз на місяць знижує кількість вразливостей у 3 рази порівняно з щоквартальним підходом. Це не маркетинг — це статистика з нашої практики.

Що входить в техпідтримку 1С-Бітрікс?

Регулярні роботи (включені в абонент):

• Моніторинг: uptime + сценарії (кошик, замовлення, обмін 1С)
• Бекапи: pg_dump / mysqldump + rsync файлів → ізольоване сховище. Перевірка відновлюваності
• Оновлення ядра Бітрікс та модулів: \Bitrix\Main\ModuleManager::isModuleInstalled() — перевірка залежностей, накат на staging, тестування, деплой
• PHP та серверне ПЗ — оновлення на виділеному сервері. Перехід між мажорними версіями PHP — з перевіркою deprecated-викликів у кастомному коді
• Аналіз /bitrix/admin/event_log.php та серверних логів — превентивне усунення помилок
• SSL, домен — перевипуск та продовження
• Щомісячний звіт: що зробили, що знайшли, що рекомендуємо

Роботи за запитом (з годинного банку):

• Баги: «картка товару не відкривається на Safari» — діагностика, фікс, деплой
• Контент: банери, сторінки, категорії, товари
• Інтеграції: нова платіжка, нова доставка, новий маркетплейс (Wildberries API, Ozon Seller API)
• Оптимізація: CIBlockElement::GetList з 20 JOIN гальмує → рефакторинг на D7 ORM з фасетним індексом
• SEO-доробки: мета-теги, Schema.org, sitemap
• Консультації: «Який модуль Бітрікса обрати для розстрочки?»

Як ми оновлюємо ядро Бітрікс?

Оновлення — процес, що не терпить шаблонів. Спочатку перевіряємо сумісність кастомних модулів з новою версією \Bitrix\Main\Application. Якщо в коді використовуються deprecated-методи — фіксимо їх до деплою. Staging-оточення точна копія прода, включаючи налаштування кешування та черги агентів. Після тестів викочуємо, моніторимо логи error_log та подій. При найменшому відхиленні — відкат за 5 хвилин. — Інструкція з оновлення ядра на dev.1c-bitrix.ru

Які типові завдання вирішуємо в рамках техпідтримки?

Контент. Банери до «Чорної п'ятниці» — за день, тому що маркетолог згадав у четвер. Нова категорія з фільтрами через catalog.smart.filter. Лендінг під рекламну кампанію — з готових компонентів, без дизайнера, за 4-6 годин.

Функціонал. Поле «прикріпити файл» в form.result.new — 2 години. Форма запису на консультацію з інтеграцією в AmoCRM через webhook — 4-6 годин. Підключення JivoSite / Carrot Quest — 1-2 години.

Верстка. «Поїхав» блок на iPhone з Dynamic Island — Safari рендерить env(safe-area-inset-top) по-своєму. Оновили ядро Бітрікс — зламався CSS картки товару, тому що компонент catalog.element оновив HTML-структуру. Чинимо.

Інтеграції. Обмін з 1С: агент CAgent по catalog.import.1c впав по таймауту при 50 000 товарів — розбиваємо імпорт на пакети через STEP. API СДЕК оновився з v1.1 на v2 — переписуємо обробник sale.delivery.handler. Новий еквайринг — налаштовуємо sale.paysystem.handler.

Серверні. Перехід між мажорними версіями PHP: grep по deprecated (each(), create_function(), {$var} строковий доступ), фікс, тестування. SSL: certbot не продовжив — cron-задача не відпрацьовувала через зміну шляху до Python. DKIM/SPF/DMARC для поштового домену — щоб сповіщення про замовлення не потрапляли в спам.

Терміни та вартість

Вартість розраховується індивідуально під обсяг завдань. Додаткові години за ставкою з договору. Можлива зміна пакету: підвищення — в будь-який момент, пониження — з початку наступного місяця. Нестандартні вимоги обговорюємо окремо. Зв'яжіться з нами — підберемо оптимальний варіант.

Екстрена підтримка — коли горить

Сайт ліг, оплата не проходить, виявлено злам.

• Гаряча лінія — Telegram + телефон. Для преміум-клієнтів — виділений номер чергового інженера
• Реакція від 15 хвилин на критичні інциденти
• Поза чергою — критичні інциденти обробляються раніше поточних завдань, незалежно від залишку годин
• Постмортем — після усунення фіксуємо, що зламалося, чому і як запобігти. Документуємо в базі знань проекту

Замовте техпідтримку зараз — отримайте первинний аудит в подарунок та гарантію безперебійної роботи вашого проекту на 1С-Бітрікс.