Обслуговування сайту Бітрікс: що ламається без регламенту
Відсутність регламенту проявляється не поступово, а відразу: сайт падає після оновлення, яке ніхто не перевіряв на тестовому контурі.
Модулі місяцями накопичують незакриті оновлення, а потім встановлюються однією пачкою і конфліктують із доопрацьованими шаблонами й компонентами, куди правки вносили прямо в код. Відкат можливий лише з резервної копії, а її або немає, або вона знята до ручних змін.
Друге вузьке місце сайту — права. За роки в системі накопичуються групи користувачів, зайві адміністратори, відкритий запис у файли та папки, доступ до інфоблоків і модулів «про всяк випадок».
Один скомпрометований акаунт із такими правами перетворюється на правку контенту й упровадження стороннього коду, а за зовнішнім виглядом сторінок це не помітно.
Третя причина — ручні правки безпосередньо на бойовому сервері. Правки в шаблонах, службових файлах і правилах перенаправлення не потрапляють у репозиторій, тому немає історії змін і неможливо зрозуміти, що і коли змінювалося.
Кеш скидається не завжди, і частина сторінок ще віддає стару версію, а наступне оновлення затирає все, що правили руками.
Усе це закривається не героїчним відновленням, а плановим регламентом: тестовий контур, поетапне встановлення оновлень, перевірювана схема відкату, ревізія прав, винесення доопрацювань у репозиторій.
Розбираємо, як це влаштовано в обслуговуванні сайту на 1С-Бітрікс і що дає регулярна підтримка сайту на Бітрікс.
Що дає планове супроводження: стабільність і швидкість
Планове супроводження сайту — це регламент, а не чергування «аби відкривався».
Усередині: моніторинг доступності та помилок застосунку, резервні копії з регулярною перевіркою відновлення, оновлення ядра й модулів 1С-Бітрікс на тестовому контурі до викочування на робочий, контроль прав доступу та закриття відомих уразливостей.
Сенс у тому, щоб прибирати цілі класи відмов. Неперевірене оновлення модуля, переповнений диск під кеш і логи, задача за розкладом, що відвалилася, прострочений сертифікат — усе це ловиться регламентом, а не в момент візиту клієнта.
Час простою сайту падає не від героїзму в аварії, а від заздалегідь прописаного відкату: попередня версія коду й даних піднімається з копії передбачувано.
Швидкість завантаження сторінок тримається режимом, а не разовою оптимізацією. Композитний кеш налаштовується за розділами, важкі запити до бази закриваються індексами, статика віддається через мережу доставки, зображення переводяться в сучасні формати.
Після кожного релізу знімаються ті самі метрики, що й до нього, — деградація видна до скарг користувачів.
Відмовостійкість сайту — властивість конфігурації: кілька вузлів застосунку, винесена база даних, перевірка живучості вузла та автоматичне перемикання в разі відмови.
Підсумок регулярної роботи — відновлення після збою за хвилини замість годин і зрозуміла база порівняння: скільки було, скільки стало, що саме змінили.
Моделі робіт: разові правки, регламент, виділена команда
Модель співпраці вибирають не за кількістю правок, а за тим, який клас відмов вона закриває. Разові заявки вирішують точкову задачу, регламент знімає планові ризики, виділена команда відповідає за розвиток і навантаження.
Варіанти поєднуються: можна тримати регламент на основному контурі й підключати разові роботи під окремий запуск.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Разові роботи за заявками | Потрібна конкретна правка або розбір інциденту, своєї команди немає | Пріоритет залежить від поточного навантаження виконавця, знання про проєкт накопичуються повільно, профілактика не виконується |
| Планове супроводження за регламентом | Робочий сайт, потрібні оновлення, резервні копії, моніторинг і узгоджений час реакції | Роботи йдуть за затвердженим переліком, термінові задачі поза ним оформлюються окремо |
| Виділена команда підтримки | Кілька сайтів, інтеграції з обліковою системою, постійні доопрацювання та розвиток | Потребує занурення на старті й регулярної синхронізації щодо задач |
| Внутрішній фахівець | Є людина, яка знає продукт і процеси зсередини | Одна людина — єдина точка відмови: відпустка, хвороба або звільнення зупиняють роботи |
Аварійні роботи можливі в будь-якій моделі, але за разових заявок час відновлення залежить від навантаження виконавця, а в регламенті й виділеній команді він закріплений заздалегідь. Тому модель вибирають за допустимим простоєм і критичністю контуру, а не за обсягом правок.
Порядок упровадження: аудит, схема, налаштування, перевірка, передача
Роботи починаємо не з правок, а з інвентаризації: що реально працює на бойовому сайті, які модулі та зовнішні обміни задіяні, де лежать резервні копії й у кого є доступ.
Аудит сайту дає карту залежностей — за нею видно, яке оновлення ядра чи модуля ламає шаблон, форму або обмін з обліковою системою.
Порядок робіт
- Знімаємо поточний стан: склад компонентів, сторонні модулі, завдання планувальника, глибина копій, права облікових записів. На виході — перелік вузьких місць з оцінкою ризику.
- Розгортаємо стенд, що повторює бойовий контур за конфігурацією та даними. Оновлення й правки проходять спочатку там.
- Пишемо регламент оновлень: черговість, вікно робіт, критерії відкату, хто підтверджує випуск на бойовий сайт.
- Налаштовуємо резервне копіювання та відкат: повні й інкрементальні копії бази та файлів, вивантаження за межі сервера, зберігання кількох поколінь.
- Перевіряємо план відновлення на чистому середовищі — сценарій вважається робочим, лише якщо пройдений покроково й укладається в цільовий час простою.
- Підключаємо моніторинг: доступність, помилки, зростання бази, вільне місце, термін дії сертифікатів. Налаштовуємо чергування та порядок ескалації.
- Передаємо документацію, доступи й регламенти вашій команді або залишаємо чергування на себе.
Після передачі залишається не набір разових налаштувань, а робочий контур: оновлення виходять за регламентом, копії знімаються автоматично, а відновлення перевірено на практиці, а не описано в теорії.
Передані артефакти: доступи, регламенти, документація, схеми
Обслуговування сайту на 1С-Бітрікс закінчується не звітом про роботи, а комплектом документів, за якими ваша команда може працювати самостійно або передати проєкт іншому підряднику без розкопок по серверу й читання коду.
Цей комплект ми підтримуємо в актуальному стані — за кожної зміни конфігурації правимо схему й регламенти, а не складаємо їх «на полицю» після запуску.
- Схема інфраструктури: контури — бойовий, тестовий, контур вивантажень; що за балансувальником, де база, де черги, звідки беруться резервні копії, які зовнішні сервіси задіяні та за якими адресами.
- Регламент доступу: ролі та їхні права, де зберігаються ключі, порядок видачі й відкликання доступів, включно зі сценарієм звільнення співробітника з адміністративними правами.
- Документація по сайту: карта шаблонів і компонентів, які модулі використовуються і за що відповідає кожен, де правиться типова логіка і що перевизначено в користувацькому коді.
- Регламент оновлень: вікно оновлень ядра й модулів, обов’язковий прогін на тестовому контурі, критерії «відкочуємося» та порядок повернення до попередньої збірки.
- Інструкції для редакторів: як додати сторінку, товар, банер, налаштувати меню; що заборонено змінювати в розмітці й куди йти, якщо контент не зберігається.
- Політика резервних копій: що копіюється, з якою періодичністю, скільки зберігається, як і з якою регулярністю перевіряється відновлення та хто його проводить.
- Журнал змін і обмежень: історія правок конфігурації, відомі вузькі місця коду та список задач, які свідомо відкладені з обґрунтуванням.
Такий набір знімає головний ризик обслуговування — залежність від конкретного інженера. Будь-який новий фахівець розгортає контур за схемою, а редактор не ламає верстку через відсутність інструкції.
Кейс: як усунули простої інтернет-магазину після міграції
Магазин працював на 1С-Бітрікс і переїхав на нове середовище: базу, файли й налаштування перенесли, вітрина відкрилася.
Через кілька тижнів з’ясувалося, що міграція закрила лише переїзд — під навантаженням сайт почав падати в пікові години, а відновлення щоразу займало половину робочого дня.
Що показав розбір
Планувальник задач запускався з помилками, частина обробників залишилася від старого середовища, а оновлення модулів не встановлювали місяцями: кожне ламало доопрацьований шаблон.
У резервних копіях лежали архіви, які жодного разу не перевіряли на відновлення, тому відкат робили вручну з файлів і логів.
Що змінили
Кастомні доопрацювання винесли в окремий шар, щоб оновлення ядра й модулів не зачіпали шаблон і логіку оформлення замовлення.
Налаштували моніторинг доступності, черг і помилок застосунку з оповіщенням чергового, а резервні копії почали перевіряти повним відновленням на тестовому стенді — раз на тиждень, за регламентом.
Що стало
Час відновлення скоротився з кількох годин до 20–25 хвилин: спрацьовує оповіщення, черговий піднімає сервіс за інструкцією, а не шукає причину з нуля. Аварійні виїзди — з трьох-чотирьох на місяць до нуля-одного.
Незакритих оновлень — нуль: вони йдуть планово в нічне вікно, з попередньою перевіркою на стенді та можливістю відкотити.
Такий режим тримається не на героїзмі адміністратора, а на регламенті: зрозуміло, хто і що робить під час збою, що саме оновлюється і як повернутися до попереднього стану.
Часті технічні питання щодо підтримки та оновлень
Перед передачею сайту на супроводження замовники ставлять ті самі інженерні питання: що станеться з доопрацюваннями після оновлення модулів, кому і на яких правах видавати доступ в адмінку, чи реально підняти сайт після збою. Нижче — короткі технічні відповіді без загальних слів про «прозорість» і «турботу».
Що буде з доопрацюваннями після оновлення модулів?
Оновлюємо на копії — тестовому контурі з тими самими налаштуваннями й даними. Якщо правлений вручну модуль або шаблон ламається, це видно до викладки, а не на бойовому сайті. Перед релізом знімаємо повний зліпок бази та файлів, тому відкат займає хвилини.
Як ви працюєте з правами доступу?
Ролі розділяємо: адміністратор, контент-менеджер, розробник — кожному мінімум прав під його задачі. Доступи персональні, входи в адмінку фіксуються в журналі, під час виходу співробітника доступ закривається точково, без зміни паролів у всієї команди.
Що робите для безпеки сайту?
Критичні патчі ставимо поза чергою, решту — пакетом із перевіркою сумісності. Типові точки входу — форми, завантаження файлів, публічні скрипти — закриваємо або обмежуємо. Резервні копії зберігаємо окремо від бойового сервера: сайт піднімається, навіть якщо хостинг недоступний.
Як швидко ви реагуєте на збій?
В інцидентів є пріоритет: спочатку недоступність сайту й підміна домену, потім помилки в замовленнях і оплаті, далі косметика. Причину кожного випадку фіксуємо в журналі — повторний збій не шукає рішення заново. Так працює регулярне обслуговування сайту, а не разові правки за дзвінком.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Оцінка робіт по сайту має спиратися на факти, а не на припущення. Тому починаємо з розбору поточного стану: конфігурація сервера, версія ядра 1С-Бітрікс і модулів, журнали помилок, схема резервного копіювання, стан бази та сторонніх інтеграцій.
За підсумками повертаємося з планом робіт — що закриваємо в першу чергу, що може зачекати, які ризики знімаємо в перший місяць супроводження.
Передача проєкту й старт супроводження йдуть за одним сценарієм: інвентаризація, доступи, регламент, закріплений інженер. На виході ви отримуєте:
- план робіт за етапами з пріоритетами та зрозумілими критеріями готовності;
- карту інфраструктури: сервери, домени, DNS, сертифікати, пошта, зовнішні сервіси;
- матрицю доступів і порядок їх видачі та відкликання, зокрема для підрядників;
- регламент оновлень ядра й модулів із вікнами робіт і точками відкату;
- схему резервного копіювання з перевіркою відновлення, а не лише створення копій;
- порядок роботи з інцидентами: канал зв’язку, час реакції, відповідальний інженер.
Опишіть задачу й те, як сайт живе зараз, — повернемося з оцінкою, складом робіт і строками. Якщо під час розбору побачимо термінове, скажемо про це прямо, до початку робіт.
Чим планове обслуговування відрізняється від роботи за заявками
Різниця між моделями видна в точці старту робіт: за роботи за заявками ми включаємося лише після звернення, за планового обслуговування — за регламентом і до того, як збій помітить клієнт.
Відрізняється не швидкість відповіді, а режим реагування: хто першим виявляє проблему і скільки часу вона встигає працювати непоміченою.
Регламент обслуговування сайту на Бітрікс фіксує періодичність і обсяг: щоденна перевірка доступності та журналів помилок, щотижневий контроль цілісності резервних копій, оновлення ядра й модулів спочатку на тестовому контурі, контроль строків продовження домену й сертифіката.
Кожна процедура залишає слід — звіт з результатом, тому стан сайту відомий з історії, а не з пам’яті.
Реактивна модель переносить ціну збою на замовника: час простою складається з часу до виявлення, діагностики та відновлення. Якщо сайт приймає замовлення або заявки, втрачені звернення накопичуються, поки триває розбір.
Окремий ризик — пропущені оновлення: перехід відразу через кілька мажорних версій ядра й модулів складніший і ризикованіший, ніж послідовне встановлення.
Робота за заявками доречна там, де сайт стабільний: контент, що рідко змінюється, немає інтеграцій з обліковою системою та приймання платежів. Тут постійний регламент надлишковий, а доопрацювання закриваються разовими задачами без постійного супроводження.
На практиці частіше працює гібрид: попереджувальне обслуговування за регламентом плюс разові заявки на доопрацювання та нові розділи. Вибір визначається тим, скільки коштує година недоступності й наскільки критичні дані, які збирає сайт.
