1С-Битрикс Малий бізнес: де ламається типовий проєкт
Редакція «Малий бізнес» у 1С-Битрикс закриває вітрину, кошик і оформлення замовлення — цього чесно вистачає на старті. Вузькі місця починаються не на порожньому каталозі, а на зростанні: коли номенклатура переходить у тисячі позицій, а трафік — у сотні одночасних відвідувачів. Розбираємо, де саме ламається типовий проєкт і що дає налаштування модулів.
Перше — каталог. Розділи тримають плоскою структурою, фільтр будується за властивостями без індексів, а вибірка тягне довідник цілком замість сторінки видачі.
Час відповіді зростає з кожною новою позицією, і першими це відчувають відвідувачі з пошуку: повільна відповідь сайту з’їдає замовлення раніше, ніж їх устигає принести трафік.
Друге — поведінка під навантаженням. Кешування увімкнено формально, статика не віддається окремо, агенти крутяться на користувацьких запитах. Пік — розпродаж або розсилка — перетворює це на чергу, і сайт починає віддавати сторінки частинами.
Третє — ручні операції в адмінці. Перерахунок знижок, оновлення цін, статуси замовлень, вивантаження в облікову систему робляться руками, бо обмін налаштовано частково. Ліміти модулів видно тут чітко: частина перевірок, інтеграцій і сценаріїв до редакції просто не входить.
Усі три вузькі місця редакції пов’язані: каталог задає швидкість, швидкість задає навантаження, навантаження повертається ручною роботою співробітників. Розбираємо, як це закривається налаштуванням модулів і регламентами.
Що дає правильне налаштування модулів редакції
Налаштування модулів редакції «1С-Битрикс Малий бізнес» — це не разова правка конфігурації, а набір режимів, які визначають, як сайт поводиться під реальним навантаженням.
Поки активні значення за замовчуванням, швидкість відповіді каталогу просідає вже на кількох сотнях одночасних відвідувачів: кожен запит до картки товару йде напряму в базу, а обмін з обліковою системою виконується синхронно й блокує відображення сторінки.
Правильно вибудувані модулі кешування, композитний режим і окремі індекси для вибірок змінюють картину. Каталог віддає підготовлені сторінки з кешу, обмін з 1С іде у фонову чергу й не гальмує вітрину, важкі операції переносяться на години низького трафіку.
Навантаження на каталог перестає бути вузьким місцем: час відповіді залишається передбачуваним і в пік, і під час переіндексації.
Другий шар — автоматизація рутинних операцій. Регламентні завдання самі оновлюють наявність і ціни, чистять застарілі кеші, збирають звіти й розсилають повідомлення відповідальним.
Частка операцій, які раніше виконувалися руками, падає, а разом із нею знижується й кількість звернень до підтримки: типові збої закриваються до того, як їх помітить користувач.
Чек-ліст за підсумками доналаштування короткий. Швидкість відповіді ключових сторінок укладається в цільовий поріг. Частка автоматичних операцій перевищує ручні. Зростання трафіку не збільшує чергу до підтримки. Журнал помилок не містить повторюваних інцидентів.
Кожен пункт підтверджується вимірюваннями до й після — інакше налаштування модулів редакції залишається набором здогадок.
Порівняння варіантів доналаштування та їхніх обмежень
Межі доналаштування задає редакція, а не набір налаштувань: у «Малому бізнесі» частина модулів і сценаріїв просто не постачається, і увімкнути їх адмініструванням не можна.
Тому ми спочатку розводимо задачу за трьома категоріями — закривається штатними засобами, швидше закривається готовим розширенням або упирається в необхідність переходу на старшу редакцію.
Помилка на цьому кроці коштує найдорожче: добудований стороннім рішенням відсутній модуль працює сьогодні й конфліктує під час оновлення ядра завтра.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Штатні модулі редакції | Задача вирішується налаштуванням прав, шаблонів, бізнес-процесів, каталогу та вже активних модулів | Межі задані редакцією: частина функцій недоступна, нестандартна логіка налаштуваннями не збирається |
| Сторонні розширення | Потрібна вузька функція: інтеграція, звіт, додаткове поле в картці | Залежність від автора й сумісності з оновленнями; накопичення розширень дає конфлікти |
| Власне доопрацювання | Логіка унікальна й не зустрічається ні в штатних модулях, ні на ринку | Зростає трудомісткість супроводу: рішення тестується під час кожного оновлення ядра |
| Перехід на старшу редакцію | Потрібні модулі й ліміти, яких у поточній редакції немає за визначенням | Перенесення даних і налаштувань не повністю автоматичне, сценарії перевіряються на копії |
Практика показує: приблизно половину запитів на «доналаштування» закривають штатні засоби, і ми чесно говоримо про це до початку робіт. Розширення беремо лише під вузькі місця, а до зміни редакції йдемо, коли обмеження заважають розвитку, а не одиничній задачі. Опишіть, що має працювати, — повернемося з оцінкою та планом за кожним із варіантів.
Порядок робіт: аудит налаштувань, схема, впровадження
Редакція «Малий бізнес» дає готовий набір модулів, але увімкнений модуль не дорівнює налаштованому під задачу.
Аудит налаштувань сайту показує, які можливості редакції реально використовуються, де дублюються властивості й розділи, які агенти й завдання за розкладом залишилися від попередніх підрядників. Без цієї карти будь-яка зміна б’є по сусідньому вузлу.
- Аудит поточної конфігурації: знімаємо склад модулів, права груп користувачів, налаштування кешування, схему інформаційних блоків.
- Схема інтеграцій: фіксуємо потоки між сайтом, 1С і зовнішніми сервісами — що і куди передається, з якою періодичністю, за якою ознакою звіряється розходження.
- План впровадження: порядок змін із точкою відкату на кожному кроці; налаштування, що впливають на вітрину й оформлення замовлення, виносимо в окреме вікно.
- Складання на копії: переносимо зміни на копію бойового сайту, проганяємо обмін, знижки, кошик і оплату.
- Перевірка на бойових даних: звіряємо залишки, ціни та замовлення після обміну, дивимося журнал помилок і час відповіді каталогу.
- Передача проєкту: адміністратор отримує регламент оновлень, опис схеми інтеграцій та інструкцію щодо типових збоїв.
Кожен етап закривається коротким звітом: що знайшли, що змінили, як перевірили. Так налаштування не перетворюється на череду правок «наживо».
Комплект: конфігурації, ролі доступу, регламенти
Комплект збирається по ходу робіт, а не після здачі: кожен артефакт прив’язаний до реального середовища й перевірений на ньому. Інакше документація розходиться з налаштуваннями вже за місяць, і наступна зміна знову починається з розбору навмання.
- Опис конфігурації: які модулі редакції увімкнено, які вимкнено й чому, які компоненти й шаблони перевизначено, що винесено з панелі керування в конфігураційні файли.
- Схема ролей і політик доступу: матриця «роль — рівень прав — розділи», окремі групи для редакторів контенту, операторів замовлень і адміністраторів, обов’язкова двофакторна автентифікація для привілейованих облікових записів.
- Регламент обслуговування: періодичність оновлень ядра й модулів, порядок перевірки оновлення на тестовому контурі, вікна робіт і умови відкату до попереднього стану.
- Інструкція адміністратора: де дивитися журнали подій і помилок, як читати звіт щодо навантаження, що робити в разі відмови сторінки, листа або обміну з 1С.
- Резервне копіювання: склад копії (файли, база, користувацькі налаштування), розклад, глибина зберігання, місце розміщення та порядок перевірки відновлення на окремому контурі.
- Регламент обміну з 1С: які сутності синхронізуються, з якою частотою, як розбирати розходження цін, залишків і статусів замовлень.
- Карта зовнішніх сервісів: платежі, доставка, розсилки, аналітика — де зберігаються ключі доступу, хто власник і що робити в разі зміни реквізитів.
- Журнал змін: що і коли правилося в налаштуваннях, коді та правах — із зазначенням автора й причини.
Усі документи лежать поруч із кодом у системі контролю версій і оновлюються разом із ним. Далі команда замовника веде їх самостійно — або передає нам, а зміни потрапляють до загального журналу.
Кейс: як проєкт перестав упиратися в ліміти редакції
До: каталог зростав, редакція — ні
Проєкт — оптова торгівля, магазин на редакції «Малий бізнес» платформи 1С-Битрикс.
Каталог виріс із 3 000 до 18 000 позицій, і стеля редакції стала видимою: довідники характеристик тримали в саморобних таблицях, фільтр збирав один запит із п’яти джерел, обмін з 1С ішов повним вивантаженням за розкладом. Каталог відповідав 4–6 секунд, а в години пік частина кошиків відвалювалася за таймаутом.
Що змінювали
Дані розклали за призначенням: товарне ядро залишилося в інфоблоках, довідники переїхали в Highload-блоки, зв’язки фільтра — в окрему таблицю з індексами.
Сторінки каталогу й карток перевели на композитний кеш, важкі вибірки — на керований кеш із прогрівом за розкладом, обмін з 1С зробили інкрементальним. Редакцію не змінювали — знімали ліміти доналаштуванням, зберігши поточну ліцензію та структуру розділів.
Після: метрики
- Час відповіді каталогу: 4–6 с → 0,7–1,1 с на непрогрітому кеші.
- Частка сторінок, відданих із кешу в пік: 0 → 93%.
- Відмови за таймаутом під час приймання заявок: поодинокі → нуль за сезон розпродажів.
- Обсяг каталогу: 18 000 → 40 000 позицій без зміни редакції.
- Обмін з 1С: хвилини → десятки секунд, повне вивантаження більше не блокує вітрину.
Через пів року асортимент зріс ще на третину — схема даних і прогрів кешу витримали без перезбирання.
Що робити, якщо проєкт уже розгорнуто на 1С-Битрикс?
Проєкт на 1С-Битрикс рідко потрібно перезбирати з нуля: редакція й модулі стоять, дані накопичено, інтеграції працюють. Тому починаємо не з переїзду, а з інвентаризації — які модулі активні, що дописано в ядрі, де живуть бізнес-процеси. Уже тут видно, що можна змінювати безпечно, а що тягне ланцюжок залежностей.
Перевірка сумісності йде на стенді. Копіюємо базу й файли, піднімаємо копію на тій самій редакції і тільки там вмикаємо потрібний модуль: дивимося журнал помилок, конфлікти агентів, перехоплення на подіях, поведінку кешу. Якщо дані й логіка сходяться — зміну допускають у робочий контур.
Доналаштування без зупинки будується на поетапних змінах. Модулі підключаємо по одному, налаштування виносимо в адміністративну частину, а логіку — у власний модуль або обробники подій замість правки ядра.
Тоді оновлення платформи не затирають доопрацювання, а будь-яку зміну вимикають одним налаштуванням.
Перенесення даних іде окремими проходами: спочатку структура — інфоблоки, властивості, розділи, потім користувачі, групи й права, далі контент і прив’язки. Перенесення повторюване: його можна прогнати знову й звірити кількість записів, щоб розходження випливло до перемикання.
Перед кожним етапом — резервна копія й точка відкату, повернення займає хвилини. Роботи ставимо на мінімальне навантаження, важкі операції розносимо по вікнах, після перемикання добу тримаємо посилений контроль помилок і швидкості відповіді.
Технічні питання перед початком робіт
Перед налаштуванням модулів редакції 1С-Битрикс Малий бізнес замовники ставлять ті самі запитання: чи не відваляться доопрацювання під час оновлення платформи, чи збережуться дані, який обсяг робіт залишиться на їхньому боці та що буде з правами адміністратора. Розбираємо кожне — коротко й по суті.
Оновлення платформи зламають наші налаштування?
Ми не правимо ядро й штатні модулі — зміни живуть в окремому шарі та у власних модулях. Оновлення редакції проходить на тестовому стенді: збираємо копію бойового сайту, проганяємо оновлення, перевіряємо ключові сценарії й тільки потім переносимо на робочий контур. Якщо щось конфліктує, відкат займає хвилини.
Дані під час доопрацювань не втратяться?
Перед будь-якими роботами знімаємо повну резервну копію — файли й базу, з перевіркою відновлення на стенді. Міграції схеми виконуємо скриптами зі зворотною операцією, а не вручну через панель адміністратора. Будь-яку правку можна відкотити, не втрачаючи замовлення й облікові записи користувачів.
Який обсяг робіт залишиться на нашому боці?
Налаштування модулів, права доступу та інтеграції закриваємо ми. На адміністраторі сайту залишається погодження змін, робота з контентом і запуск регламентних копій за чек-лістом. Доступи видаємо за ролями: зайвих прав у підрядника немає, у вас — повний журнал дій.
Обговоримо задачу: що надіслати для оцінки
Оцінка за такою задачею складається з двох частин: що вже розгорнуто на проєкті та що потрібно змінити. Чим точніше описано контур — редакція, склад модулів, інтеграції, навантаження, — тим менше припущень залишається в плані робіт і тим реалістичніше виглядають терміни етапів. Нижче — що додати до опису задачі.
- Тип і редакцію: сайт на «1С-Битрикс: Управління сайтом» у редакції «Малий бізнес» або портал на 1С-Битрикс24, стан ліцензії.
- Склад модулів: що увімкнено, які правки вносили раніше, що саме перестало працювати.
- Інтеграції: обмін з 1С (каталог, ціни, залишки, замовлення), платіжні системи, доставка, повідомлення.
- Інфраструктуру: де розміщено проєкт, параметри сервера, доступ до репозиторію та резервних копій.
- Обсяг даних: кількість товарів і розділів каталогу, кількість користувачів, пікове навантаження на замовлення.
- Доступи й матеріали: адміністратор у панелі керування, хостинг, база даних, обліковий запис для обміну з 1С.
- Обмеження: що змінювати не можна, зовнішні терміни, регламент на зупинку робіт.
Цього достатньо, щоб повернутися з оцінкою обсягу, розбивкою робіт за етапами та планом із контрольними точками. Якщо частину даних закрито, фіксуємо припущення окремо й знімаємо їх на першому дзвінку.
