Відмовостійкість Бітрікс24 On-Premise: налаштування під ключ

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Відмовостійкість Бітрікс24 On-Premise: налаштування під ключ
Простий
~1 день
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    943
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1074

Відмовостійкість Бітрікс24 On-Premise: налаштування під ключ

Уявіть: у вашому Бітрікс24 On-Premise падає сервер бази даних посеред робочого дня. Без репліки та автоматичного фейловера — 30 хвилин простою, втрачені заявки, зрив SLA клієнтам. Або раптово відмовляє NFS — усі файли недоступні, співробітники не можуть завантажити документи, робота паралізована. Типовий простій у 30 хвилин коштує бізнесу від 200 000 гривень. Ми вирішуємо ці сценарії на етапі проектування відмовостійкості. Наш досвід — 10+ років з Бітрікс24, понад 50 проектів з навантаженням до 5000 користувачів. Кожен проект починається з аудиту поточної інфраструктури — виявляємо всі SPOF і пропонуємо архітектуру, яка мінімізує RTO та RPO. Типові рішення: Keepalived для балансування VIP, GlusterFS для розподіленого сховища, Orchestrator для автоматичного фейловера MySQL. У результаті ви отримуєте SLA 99.99% і впевненість у роботі системи.

Чому відмовостійкість Бітрікс24 On-Premise критична?

Без відмовостійкості кожен компонент — SPOF. Падіння одного сервера призводить до повного простою. Наприклад, втрата майстер-ноди MySQL без репліки означає втрату даних за останні хвилини та ручне відновлення. З автоматичним фейловером RTO знижується з 30 хвилин до 2 хвилин. Це різниця між втратою замовлень і штатною роботою. Відмовостійкість окупається при першому серйозному збої.

Аналіз точок відмови (Single Point of Failure)

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

Компонент Ризик Рішення
Веб-сервер (один) Повний простій при падінні Active-Active кластер
MySQL без репліки Втрата даних + простій Master-Slave + автофейловер
NFS (один) Втрата файлів + простій GlusterFS або S3
Redis (один) Втрата сесій (logout всіх) Redis Sentinel
Балансувальник Повний простій Keepalived + VIP
DNS Недоступність за іменем Два DNS-сервери або Anycast

Чому Keepalived — стандарт для балансування?

Це рішення перевірено роками: Keepalived перемикає VIP за 2–3 секунди при падінні майстра. Ручне перемикання DNS зайняло б хвилини. Налаштування просте — наведемо конфіг для MASTER-ноди:

# /etc/keepalived/keepalived.conf — MASTER-нода
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass your_secret
    }

    virtual_ipaddress {
        192.168.1.100/24  # VIP — цей IP прописаний в DNS
    }

    track_script {
        chk_nginx
    }
}

vrrp_script chk_nginx {
    script "killall -0 nginx"
    interval 2
    weight -20
}

При падінні MASTER Keepalived автоматично переносить VIP на BACKUP-ноду. Перемикання займає 2–3 секунди. Згідно з документацією Keepalived, такий механізм забезпечує високу доступність без участі адміністратора.

Як працює автофейловер бази даних?

Ручне перемикання Master → Slave при аварії — це 15–30 хвилин downtime. Автоматичний фейловер через Orchestrator у 10 разів швидше — RTO знижується з 30 хвилин до 2 хвилин. Orchestrator — найбільш зріле рішення для MySQL/MariaDB.

# Встановлення та налаштування Orchestrator
orchestrator-client -c topology -i db-master:3306
# При падінні майстра автоматично промоутує кращу репліку

Після зміни майстра Бітрікс24 має отримати нову адресу БД. Реалізується через ProxySQL — проксі перед MySQL, який прозоро перемикає з'єднання при зміні топології. Це усуває необхідність ручної зміни конфігів.

GlusterFS для відмовостійкого сховища

NFS — простий і дешевий варіант, але при його падінні весь кластер втрачає доступ до файлів. GlusterFS — розподілена файлова система з реплікацією, яка продовжує роботу при відмові одного вузла.

# На обох вузлах сховища
gluster volume create bitrix-files replica 2 \
    storage1:/data/bitrix storage2:/data/bitrix

gluster volume start bitrix-files

# Монтування на веб-вузлах
mount -t glusterfs storage1:/bitrix-files /home/bitrix/www/upload

При падінні одного вузла GlusterFS продовжує роботу на другому. Записи синхронізуються автоматично при відновленні.

Health checks і автовідновлення

Моніторинг без автодій — половина роботи. Налаштуйте автоматичні реакції:

  • nginx health_check з виключенням хворого backend з пулу
  • systemd автоперезапуск для nginx, php-fpm, redis при краші
  • Cron-перевірка реплікаційного лагу з алертом у Telegram при lag > 60 сек
# Автоматична перевірка реплікації з алертом
mysql -u monitor -e "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master" | \
    awk '{if($2>60) system("curl -s -X POST https://api.telegram.org/bot$TOKEN/sendMessage -d chat_id=$CHAT -d text=REPLICA_LAG_ALERT")}'

RTO/RPO для різних сценаріїв

Сценарій RPO (втрата даних) RTO (час відновлення)
Падіння веб-вузла 0 < 5 сек (keepalived)
Падіння майстра БД < 5 сек 1–2 хв (Orchestrator)
Падіння NFS/GlusterFS 0 (реплікація) < 30 сек
Повна втрата датацентру По RPO бекапу (1 год) 2–4 год
Збій диска на одному вузлі 0 < 1 хв (перемикання на репліку)

Що входить у роботу

  • Аудит поточної інфраструктури та виявлення SPOF
  • Проектування відмовостійкої архітектури з урахуванням ваших SLA
  • Налаштування Keepalived, GlusterFS, Orchestrator, Redis Sentinel, ProxySQL
  • Інтеграція з моніторингом (Zabbix/Prometheus) та алертингом
  • План відновлення (DRP) та документація з експлуатації
  • Навчання ваших адміністраторів

Замовте проектування відмовостійкого кластера та отримайте консультацію. Зв'яжіться з нами для аудиту вашої інфраструктури — оцінимо проект за один день.

Коробкова версія Бітрікс24: коли хмара не варіант

Хмарний Бітрікс24 зручний для старту, але коли бізнес переростає 50 користувачів або з’являються вимоги 152‑ФЗ, 54‑ФЗ, compliance — коробка стає єдиним робочим варіантом. Ми — сертифіковані партнери 1С-Бітрікс з 10-річним досвідом та понад 50 впровадженнями On‑Premise в банках, на виробничих підприємствах та в держорганізаціях. Скрізь, де дані не можна передавати третім особам. Зв’яжіться з нами для оцінки вашого проєкту — відповімо за 1 день.

Як забезпечити безпеку коробкової версії Бітрікс24?

Безпека та compliance

Регулятори — ЦБ, ФСТЕК — вимагають локалізації персональних даних на території РФ. Коробка дозволяє розмістити портал у сертифікованому ЦОД або в закритому контурі без доступу до інтернету. Гарантуємо відповідність вимогам 152‑ФЗ та рекомендаціям ФСТЕК. Ви контролюєте, хто і коли заходить до бази — жодних сторонніх підключень.

Глибока кастомізація

У хмарі обмежені REST API та маркетплейсом. Коробка надає повний доступ до PHP-коду: можна додати свою вкладку в картку угоди, переписати логіку бізнес-процесу через CBPActivity, підключити прямий SQL до ERP. Головне — не патити ядро, а писати власні модулі через \Bitrix\Main\ModuleManager. Ми так робимо в кожному проєкті. Використовуємо ORM \Bitrix\Main\ORM\Data\DataManager для кастомних сутностей, епілог $component->setTemplateEpilog() для гнучкого виведення та тримаємо всю доробку в local/php_interface.

Високі навантаження

500+ активних користувачів, документообіг із тисячами угод на день, постійна телефонія — хмара впирається в ліміти. Коробка масштабується: винесли MySQL на окремий сервер, налаштували Redis для кешу b_cache — і портал літає. При 200+ користувачах продуктивність власного сервера в 3‑4 рази вища за хмарний тариф, а економія на ліцензіях сягає 60% на рік.

Інтеграція з внутрішніми системами

Active Directory, 1С:Підприємство по SOAP, legacy-ERP через пряме підключення до Oracle — все це простіше, коли портал у локальній мережі. Не потрібно мучитися з VPN-тунелями та таймаутами. Для обміну з 1С використовуємо CommerceML або прямий REST-вебхук.

Автономність

Портал працює без інтернету — для виробничих цехів та режимних об’єктів це обов’язкова вимога.

Хмару варто залишити, якщо у вас менше 50 користувачів, немає особливих вимог до безпеки та немає штатного адміністратора — вона дешевша, простіша і оновлюється сама.

Чому коробкова версія Бітрікс24 вигідніша за хмару для середнього бізнесу?

Порівняємо за ключовими метриками на основі наших проєктів:

Критерій Хмара Коробка
Контроль над даними Сервери 1С‑Бітрікс Ваш сервер, ваша БД
Вартість при 100+ користувачах Висока щорічна плата Окупається за 2‑3 роки, далі дешевше на 60%
Кастомізація Тільки REST API та додатки Повний код, будь-які доробки
Продуктивність при 200+ користувачах Спільні ресурси, ліміти Власний сервер — вище в 3‑4 рази
Оновлення Автоматичні (можуть зламати інтеграції) Ви вирішуєте коли і як

Коробка вигідніша в 2‑3 рази при чисельності від 100 осіб — це підтверджують десятки виконаних проєктів. Ліцензія «Компанія» обходиться значно дешевше річної підписки на хмарний тариф для 100 користувачів. Отримайте точний розрахунок для вашого бізнесу — замовте консультацію.

Що входить в роботу з впровадження коробки?

  • Встановлення стеку — nginx + PHP 8.1+ (FPM) + MySQL/MariaDB + Redis. Розраховуємо pm.max_children: доступна RAM / споживання на воркер (зазвичай 256М). При 16GB RAM отримуємо ~50 воркерів.
  • Міграція з хмари — перенесення CRM, завдань, чатів, диска, бізнес-процесів. Враховуємо, що ID сутностей не збігаються — угода #1234 стане #5678. Переналаштовуємо всі автоматизації.
  • Інтеграції — 1С (синхронізація довідників та документів), AD (автостворення обліковок), телефонія (SIP-транки через voximplant або свій Asterisk), ЕДО (Діадок, СБІС).
  • Кастомна розробка — модулі, REST-вебхуки, бізнес-процеси з розгалуженнями, чат-боти. Використовуємо інфоблоки v2.0, HL-блоки, ORM для кастомних сутностей.
  • Навчання — 2‑5 днів для адміністраторів та ключових користувачів.
  • Документація — архітектурна схема, інструкція з бекапу, регламент оновлень.
  • Технічна підтримка — після запуску супроводжуємо за SLA: реагуємо на інциденти, встановлюємо оновлення, лагодимо інтеграції.

Оцінимо ваш проєкт за один робочий день — напишіть, надішлемо комерційну пропозицію.

Як обрати редакцію ліцензії

Ліцензії відрізняються за кількістю користувачів: CRM (до 12), Компанія (до 50), Підприємство (до 500), Холдинг (без ліміту). Допомагаємо підібрати редакцію без переплати та нагадуємо про продовження. Прострочена ліцензія = немає оновлень безпеки = потенційна діра. Скористайтесь нашим 10-річним досвідом, щоб отримати оптимальний набір.

Серверна інфраструктура: де реально лежать граблі

Стандартна рекомендація «4 CPU, 8GB RAM» — для демо-стенду. В проді з 200 користувачами, активною CRM та телефонією це не живе.

Масштаб Конфігурація Що врахувати
До 50 4 CPU, 8GB, SSD Мінімум. Push-сервер з’їсть 1‑2GB
50‑200 8 CPU, 16GB, NVMe innodb_buffer_pool_size = 10GB, innodb_flush_log_at_trx_commit = 2
200‑500 Web + DB на різних серверах MySQL на окремій машині, Redis shared
500+ Кластер: 2+ web, master‑slave DB, Redis Sentinel HAProxy, моніторинг обов’язковий

Моніторинг через Zabbix+Grafana — алерти на CPU >80% sustained, RAM <10% free, disk I/O wait >20%, MySQL slow queries >100/год. Бекапи — щоденні, з перевіркою відновлення раз на місяць. Бекап, який не можна відновити, — не бекап.

Оновлення: контрольований процес

У хмарі оновлення прилітають самі — і ламають кастомні інтеграції. У коробці ви вирішуєте, коли оновлюватися.

  1. Тестуємо на staging — точна копія прода з анонімізованою базою.
  2. Перевіряємо сумісність кастомних модулів — partner_modules можуть конфліктувати з новим ядром.
  3. Робимо повний бекап (файли + БД) перед накатуванням.
  4. Оновлюємо у вікно мінімального навантаження (неділя вночі).
  5. Моніторимо 24 години після оновлення.

Гарантуємо, що жодна інтеграція не зламається без вашого відома.

Як довго триває впровадження коробкової версії Бітрікс24?

Етап Термін
Встановлення та налаштування стеку 2‑5 днів
CRM + бізнес-процеси 1‑3 тижні
Інтеграція з 1С та AD 1‑2 тижні
Міграція з хмари 3‑7 днів
Навчання 2‑5 днів
Кастомна розробка від 2 тижнів

Отримайте консультацію з впровадження — зв’яжіться з нами, і ми надішлемо план робіт із точними термінами під ваш кейс. Не йдемо після запуску — супроводжуємо за SLA. Замовте консультацію з впровадження коробкової версії Бітрікс24 — і ми підготуємо індивідуальний план із точними термінами під ваш кейс.