Послуги з впровадження коробкової версії Бітрікс24

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

Коробка — це коли код на вашому сервері, дані у вашій базі, а оновлення ставите коли хочете, а не коли 1С-Бітрікс вирішив. Повний контроль, повна відповідальність.

П'ять причин обрати On-Premise (і одна — не обирати)

Безпека та compliance. Банки, держструктури, медицина, оборонка — всі, кому регулятор забороняє зберігати дані в чужій хмарі. Закони про захист персональних даних, стандарти безпеки для фінтеху, вимоги регуляторів — коробка дозволяє розмістити портал у сертифікованому ЦОД або взагалі в закритому контурі без інтернету.

Глибока кастомізація. Хмара обмежена маркетплейсом та REST API. Коробка — повний доступ до PHP-коду. Хочете переписати логіку картки угоди? Додати вкладку з даними з ERP через прямий SQL? Вбудувати свій віджет у канбан задач? У хмарі — не можна. У коробці — bitrix/modules/crm/lib/ відкритий для читання та модифікації (через свої модулі, не патчами ядра).

Високі навантаження. 500+ користувачів, активний документообіг, CRM із тисячами угод на день, телефонія — хмара впирається в ліміти. Коробка масштабується: додали RAM, винесли MySQL на окремий сервер, налаштували Redis для кешу b_cache — і портал дихає.

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

Автономність. Портал працює без інтернету — в локальній мережі. Для виробничих підприємств та режимних об'єктів — вимога, а не примха.

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

Що ми робимо з коробкою

Встановлення та налаштування стеку. Не «поставили з коробки й пішли», а вивірена конфігурація:

• Підбір серверної конфігурації під реальне навантаження — не за маркетинговими таблицями, а за профілюванням
• nginx + PHP-FPM + MySQL/MariaDB. pm.max_children розраховуємо за формулою: доступна RAM / споживання на воркер. Ставимо 256M на воркер — при 16GB RAM отримуємо ~50 воркерів, мінус ОС та MySQL
• .settings.php — Redis для сесій та кешу (cache → redis, session → redis). Без цього Push & Pull модуль буде гальмувати
• SSL, DNS, поштовий сервер. Push-сервер push-server на Node.js — без нього немає real-time сповіщень
• LDAP/Active Directory — єдина точка авторизації. Звільнили співробітника в AD — він автоматично втрачає доступ до порталу

Міграція з хмари. Переносимо все:

• CRM: ліди, угоди, контакти, компанії, історія активності
• Структура компанії, відділи, користувачі з правами
• Задачі, проєкти, канбан-дошки, коментарі
• Чати, файли з диску
• Бізнес-процеси та роботи CRM
• Телефонія та відкриті лінії

Головна пастка міграції — ID сутностей не збігаються. Угода #1234 у хмарі стане #5678 у коробці. Всі автоматизації, які зав'язані на конкретні ID (а вони завжди зав'язані), потрібно переналаштовувати.

Кастомна розробка:

• Свої модулі через \Bitrix\Main\ModuleManager — не патчі ядра, а повноцінні модулі зі встановленням/видаленням
• REST-додатки та вебхуки
• Модифікація CRM: кастомні поля, вкладки, дії в картках
• Бізнес-процеси з розгалуженнями, умовами та інтеграціями — штатний дизайнер БП покриває 70%, решту дописуємо через CBPActivity
• Чат-боти для внутрішніх процесів — через Bitrix\ImBot

Інтеграції:

• 1С — синхронізація довідників, документів, взаєморозрахунків. Через штатний модуль або кастомний обмін через REST
• Active Directory — автостворення та блокування облікових записів через LDAP-конектор
• IP-телефонія — SIP-транки, маршрутизація через voximplant або власний Asterisk
• Пошта — Exchange, Postfix. IMAP-конектор для вхідної, SMTP для вихідної
• ЕДО — Діадок, СБІС через API

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

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

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

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

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

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

Ліцензії

• CRM — до 12 користувачів
• Компанія — до 50
• Підприємство — до 500
• Холдинг — без ліміту

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

Терміни

Повний цикл — від вибору редакції до постійного супроводу. Не йдемо після впровадження.