Коли в компанії кілька сайтів, технічна підтримка швидко перетворюється на окремий управлінський процес. Потрібно контролювати домени, хостинг, облікові записи, резервні копії, оновлення CMS, сертифікати, пошту та безпеку. Якщо ці дані зберігаються в різних чатах, таблицях і поштових скриньках, зростає ризик втратити доступ, пропустити критичне оновлення або не встигнути відреагувати на збій.
Для стабільної роботи важливо побудувати зрозумілу систему: описати всі ресурси, обмежити доступи, визначити відповідальних, регулярно перевіряти працездатність сайтів і заздалегідь погодити порядок дій у разі аварії. Окремі практичні підходи до цього описані у матеріалі Технічна підтримка кількох сайтів WordPress: Як не збожеволіти?.
Єдиний реєстр сайтів
Перший крок — створити актуальний реєстр усіх сайтів і пов’язаних із ними сервісів. Це не просто список доменів, а робоча карта інфраструктури, за якою спеціаліст може швидко зрозуміти, де розміщений сайт, хто має доступ і що потрібно перевірити.
Для кожного ресурсу варто зафіксувати:
- доменне ім’я та дату завершення його реєстрації;
- хостинг або сервер, на якому розміщено сайт;
- CMS, тему, ключові плагіни та версії програмного забезпечення;
- контактних осіб і відповідальних за погодження змін;
- дані про SSL-сертифікат, корпоративну пошту та зовнішні інтеграції;
- розташування резервних копій і дату останньої перевірки їх створення;
- особливі налаштування: платіжні системи, CRM, API, аналітику та рекламні сервіси.
Паролі не слід зберігати в такому реєстрі у відкритому вигляді. Він має показувати, де шукати потрібний доступ, але не створювати єдину точку компрометації. Документ також потрібно регулярно оновлювати після зміни хостингу, підрядника, доменних налаштувань або структури команди.
Безпечне зберігання доступів
Використання одного спільного пароля для всіх сайтів — небезпечна практика. Якщо його буде викрадено, зловмисник може отримати доступ одразу до всієї інфраструктури. Для кожного сервісу потрібен окремий складний пароль, а де це можливо — двофакторна автентифікація.
Найкраще зберігати облікові дані в спеціалізованому менеджері паролів із розподілом доступів за ролями. Працівнику або підряднику варто надавати лише ті права, які необхідні для виконання конкретних завдань. Адміністративний доступ не повинен бути повсякденним інструментом для всіх користувачів.
Окремо слід контролювати такі облікові записи:
- реєстратор домену;
- хостинг або сервер;
- адміністратор WordPress;
- FTP, SFTP або SSH;
- панель керування базою даних;
- поштові та хмарні сервіси;
- системи аналітики, реклами та інтеграцій.
Після завершення співпраці з працівником чи підрядником доступ потрібно відкликати, змінити пов’язані паролі та перевірити активні сесії. Перед будь-якими змінами в облікових записах бажано переконатися, що є актуальна резервна копія конфігурацій і даних. Неправильне видалення користувача або зміна доступів іноді ускладнює відновлення керування сайтом.
Графік оновлень
Оновлення WordPress, тем і плагінів не варто виконувати хаотично або лише після появи помилки. Водночас автоматичне встановлення всіх оновлень без перевірки також може спричинити конфлікт, зламати верстку, форми, оплату чи інтеграцію з іншими системами.
Для кожного сайту потрібно визначити періодичність перевірок і порядок оновлення:
- Перевірити, чи створюється актуальна резервна копія файлів і бази даних.
- Оцінити сумісність оновлень із версією PHP, темою та іншими плагінами.
- За можливості спочатку виконати зміни на тестовій копії сайту.
- Оновити компоненти у погоджений час, коли зниження доступності не завдасть критичної шкоди.
- Перевірити головну сторінку, форми, авторизацію, кошик, оплату, пошту та інтеграції.
- Зафіксувати результат і помилки, якщо вони виникли.
Критичні оновлення безпеки не слід відкладати на невизначений термін. Якщо сайт має нестандартну тему, застарілий код або велику кількість залежностей, перед оновленням потрібна технічна оцінка. У разі помилки не варто бездумно перевстановлювати компоненти: спочатку потрібно зберегти поточний стан, журнали та резервну копію, оскільки повторні зміни можуть ускладнити діагностику.
Централізований моніторинг
Власник може дізнатися про проблему із сайтом від клієнта, хоча технічні ознаки збою з’являються раніше. Централізований моніторинг допомагає автоматично перевіряти доступність ресурсів і швидше реагувати на несправності.
Для кожного сайту доцільно контролювати:
- доступність сторінок і HTTP-коди відповіді;
- термін дії домену та SSL-сертифіката;
- вільне місце на сервері;
- навантаження на CPU, оперативну пам’ять і базу даних;
- помилки PHP, веб-сервера та WordPress;
- результат створення резервних копій;
- ознаки шкідливих змін у файлах;
- працездатність ключових форм та інтеграцій.
Сповіщення мають надходити не лише одній людині. Якщо повідомлення отримує працівник у відпустці або вже не працює в компанії, реакція може затриматися. Варто мати основного й резервного відповідального, а також описати, що вважається критичним інцидентом.
Моніторинг не замінює регулярну ручну перевірку. Сайт може відкриватися, але при цьому не приймати заявки, не надсилати листи або показувати помилку лише на окремій сторінці. Тому автоматичні сигнали потрібно доповнювати контрольними сценаріями та періодичним тестуванням функцій.
Пріоритети при збоях
Коли одночасно виникають проблеми на кількох сайтах, важливо не намагатися виправляти їх навмання. Спочатку потрібно визначити масштаб і вплив збою: чи недоступний один сайт, чи проблема пов’язана з хостингом, DNS, сервером або спільним сервісом.
Зазвичай пріоритет мають такі ситуації:
- підозра на злам, вірус або несанкціонований доступ;
- недоступність сайту, через яку зупинилися продажі або приймання заявок;
- помилки бази даних, втрата записів або пошкодження файлів;
- проблеми з оплатою, авторизацією, поштою чи іншими критичними інтеграціями;
- помилки після оновлення, які впливають на основні функції;
- візуальні недоліки та некритичні помилки окремих сторінок.
До початку відновлювальних робіт потрібно зафіксувати симптоми, час появи проблеми, останні зміни та повідомлення про помилки. Якщо є підозра на вірус або злам, не слід одразу видаляти невідомі файли чи перевстановлювати WordPress: це може знищити важливі сліди та ускладнити визначення причини. Спершу бажано зробити копію поточного стану, обмежити доступ і зібрати журнали.
Спеціаліст потрібен тоді, коли сайт залишається недоступним після базової перевірки, зникли дані, не працює база, є ознаки зараження, втрачено адміністративний доступ або помилка повторюється після оновлень. Без діагностики неможливо відповідально визначити спосіб і строки відновлення: однаковий симптом може бути наслідком проблем із DNS, сервером, кодом, базою даних або стороннім сервісом.
Системний реєстр, контроль доступів, планові оновлення, моніторинг і зрозумілі пріоритети зменшують кількість аварій та скорочують час реагування. А регулярні резервні копії, які не лише створюються, а й перевіряються, залишаються основою безпечної підтримки кількох сайтів.