Сайт запустили. А що далі?

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

Насправді все навпаки.

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

Сайт, який залишили без технічної уваги після запуску, поступово накопичує проблеми. Іноді вони непомітні місяцями — аж поки одного дня щось перестає працювати.

Чому сайт не можна просто залишити після запуску

Будь-який сучасний сайт складається не лише з HTML і CSS.

У Drupal-проєкті це може бути сам Drupal Core, contributed modules, теми, бібліотеки Composer, PHP, база даних, вебсервер, cron, кешування та інші компоненти.

Кожен із них змінюється з часом.

Виходять нові версії програмного забезпечення, виправляються помилки, закриваються вразливості, змінюються залежності. При цьому нове оновлення не завжди означає, що достатньо натиснути одну кнопку.

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

Тому технічне обслуговування — це не просто «періодично оновлювати сайт».

1. Оновлення Drupal та його компонентів

Drupal і модулі отримують як звичайні функціональні оновлення, так і security-релізи.

Особливо важливі саме оновлення безпеки.

Вразливість у модулі може стосуватися навіть функціоналу, яким користувач сайту безпосередньо не бачить. Якщо проблема вже відома публічно, залишати вразливу версію на production-сайті — погана практика.

Але оновлення потрібно виконувати контрольовано.

Перед оновленням варто мати актуальну резервну копію та розуміти, які зміни відбудуться із залежностями. Після оновлення потрібно перевірити сайт.

У Drupal-проєктах Composer є важливою частиною цього процесу. Він керує PHP-залежностями проєкту та дозволяє відтворювати контрольований набір пакетів.

2. Перевірка безпеки

Безпека сайту — це не одноразове налаштування під час розробки.

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

• вразливостями Drupal Core;
• security advisory для модулів;
• залежностями Composer;
• версією PHP;
• конфігурацією вебсервера;
• доступами до адміністративної частини;
• резервними копіями.

І тут є важливий момент.

Відсутність повідомлень про проблему не означає відсутність проблеми.

Без регулярного контролю можна просто не знати, що на сайті вже використовується застаріла або вразлива залежність.

3. Резервні копії

Резервна копія потрібна не для того, щоб вона просто лежала десь на сервері.

Вона потрібна для моменту, коли щось пішло не так.

Злам, помилка під час оновлення, неправильні зміни в базі даних, проблема із сервером або випадкове видалення файлів можуть перетворитися на серйозну проблему, якщо відновити сайт неможливо.

Нормальний backup-процес повинен враховувати як мінімум файли сайту та базу даних.

Ще важливіше — резервні копії потрібно перевіряти.

Копія, яку жодного разу не пробували відновити, не дає повної впевненості, що у критичний момент вона справді допоможе.

4. Логи та контроль помилок

Користувач може нічого не помічати, а сайт уже може працювати з проблемами.

Наприклад, у логах можуть регулярно з'являтися:

• PHP errors;
• помилки Drupal;
• HTTP 500;
• проблеми з cron;
• помилки підключення до бази даних;
• зламані URL;
• проблеми окремих модулів або інтеграцій.

Не кожна помилка є критичною.

Але регулярний аналіз логів допомагає побачити тенденції ще до того, як проблема стане помітною користувачу.

Саме тому логування — це не просто архів повідомлень. Це один із способів зрозуміти, що відбувається із сайтом.

5. Cron і фонові процеси

Частина завдань сайту виконується не тоді, коли користувач відкриває сторінку.

Drupal може використовувати cron для різних службових операцій: обробки черг, очищення, оновлення та інших фонових завдань.

Якщо cron перестає працювати, сайт зовні може залишатися доступним.

Але окремі функції поступово почнуть працювати неправильно.

Тому після запуску важливо контролювати не тільки доступність головної сторінки, а й роботу фонових процесів.

6. Сервер теж потребує уваги

Сайт живе не у вакуумі.

Навіть якщо Drupal налаштований правильно, сервер потребує контролю.

Це стосується, зокрема:

• дискового простору;
• PHP та PHP-FPM;
• NGINX;
• бази даних;
• системних ресурсів;
• SSL-сертифіката;
• журналів сервера;
• резервного копіювання.

Наприклад, закінчення дискового простору може спричинити проблеми, які спочатку взагалі не очевидні.

Тому технічне обслуговування сайту — це не лише робота з CMS.

7. Продуктивність змінюється з часом

Сайт, який працював швидко після запуску, не обов'язково буде таким самим через рік.

З'являється більше контенту.

Збільшується база даних.

Додаються модулі.

Змінюються запити.

Зростає кількість відвідувачів.

Змінюється конфігурація сервера.

У результаті навантаження на систему поступово збільшується.

Тому продуктивність також потрібно періодично перевіряти, а не згадувати про неї лише тоді, коли користувачі почали скаржитися на повільний сайт.

8. Зміни після запуску теж потрібно контролювати

Після запуску сайт рідко залишається незмінним.

Додаються нові сторінки, поля, функції, інтеграції, користувачі та сторонні сервіси.

Проблема не в самих змінах.

Проблема виникає тоді, коли вони виконуються без контролю.

Навіть невелика зміна може вплинути на іншу частину системи. Саме тому важливо розуміти, що було змінено, навіщо це було зроблено і як перевірити результат.

9. Що входить у нормальне технічне обслуговування

Технічна підтримка сайту — це значно ширше, ніж виправлення проблем після того, як вони вже виникли.

Залежно від проєкту вона може включати:

Оновлення: Drupal Core, модулів, тем і залежностей.

Безпеку: контроль security advisory та своєчасне усунення відомих вразливостей.

Резервування: створення та контроль backup.

Моніторинг: доступність сайту, помилки, ресурси сервера та інші показники.

Сервер: контроль PHP, NGINX, бази даних і дискового простору.

Тестування після оновлень: перевірка сайту після технічних змін.

Виправлення проблем: пошук причин помилок і відновлення працездатності.

Планові зміни: встановлення нових модулів, додавання функціоналу та технічні покращення.

Точний набір робіт залежить від самого проєкту.

А що буде, якщо нічого не робити?

Може не статися нічого.

За день.

За місяць.

І навіть за кілька місяців.

Але поступово накопичується технічний борг.

Старі версії компонентів залишаються без оновлень. Резервні копії можуть виявитися непридатними. Логи наповнюються помилками. Сервер втрачає запас продуктивності. Документація застаріває.

А коли нарешті виникає серйозна проблема, її доводиться вирішувати вже в аварійному режимі.

І часто це дорожче, ніж регулярне технічне обслуговування.

Сайт — це не одноразовий продукт

У веброзробці легко мислити категорією:

розробили → запустили → завершили.

Для сучасного сайту ця модель не зовсім працює.

Правильніше:

розробили → протестували → запустили → підтримуємо → оновлюємо → контролюємо → розвиваємо.

Сайт — це жива система.

Його програмне забезпечення змінюється. Змінюється сервер. Змінюється бізнес. З'являється новий контент і нові вимоги.

Тому після запуску сайту робота не закінчується.

Вона просто переходить із розробки в експлуатацію.

І чим краще ця експлуатація організована, тим менше шансів, що про технічний стан сайту доведеться згадати лише в той день, коли він перестане працювати.