Відмовостійкість Бітрікс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/год. Бекапи — щоденні, з перевіркою відновлення раз на місяць. Бекап, який не можна відновити, — не бекап.
Оновлення: контрольований процес
У хмарі оновлення прилітають самі — і ламають кастомні інтеграції. У коробці ви вирішуєте, коли оновлюватися.
- Тестуємо на staging — точна копія прода з анонімізованою базою.
- Перевіряємо сумісність кастомних модулів —
partner_modules можуть конфліктувати з новим ядром.
- Робимо повний бекап (файли + БД) перед накатуванням.
- Оновлюємо у вікно мінімального навантаження (неділя вночі).
- Моніторимо 24 години після оновлення.
Гарантуємо, що жодна інтеграція не зламається без вашого відома.
Як довго триває впровадження коробкової версії Бітрікс24?
| Етап |
Термін |
| Встановлення та налаштування стеку |
2‑5 днів |
| CRM + бізнес-процеси |
1‑3 тижні |
| Інтеграція з 1С та AD |
1‑2 тижні |
| Міграція з хмари |
3‑7 днів |
| Навчання |
2‑5 днів |
| Кастомна розробка |
від 2 тижнів |
Отримайте консультацію з впровадження — зв’яжіться з нами, і ми надішлемо план робіт із точними термінами під ваш кейс. Не йдемо після запуску — супроводжуємо за SLA. Замовте консультацію з впровадження коробкової версії Бітрікс24 — і ми підготуємо індивідуальний план із точними термінами під ваш кейс.