Запущений сайт продовжує змінюватися: оновлюються залежності, інтеграції, правила бізнесу та контент. Навіть якщо ніхто не додає нових сторінок, можуть змінитися API платіжного сервісу або параметри хостингу. Підтримка — це узгоджений порядок спостереження, змін і відновлення, який допомагає команді діяти при проблемі. Він має бути зрозумілим власнику сайту й виконавцю.
Розділіть регулярні роботи та інциденти
Регулярні роботи включають перевірку оновлень, сертифікатів, журналів і резервних копій. Інцидент — це ситуація, у якій погоджена функція вже не працює: сайт недоступний, форма не надсилає звернення або платіж не оновлює статус. Новий дизайн чи додатковий модуль можуть бути окремим розвитком продукту. Таке розділення допомагає не підміняти аварійний канал потоком побажань.
У SLA важливо розрізняти час реакції та відновлення
Реакція означає, що звернення прийняли та почали діяти за регламентом. Відновлення означає повернення погодженої функції. Між ними може бути діагностика, очікування зовнішнього провайдера або тимчасове рішення. Тому напис «відповідаємо швидко» не пояснює власнику сайту, що саме відбудеться при аварії.
| Умова підтримки |
Що потрібно визначити |
|
Години підтримки |
Коли канал обслуговується й як діють поза графіком |
|
Рівень інциденту |
Вплив на бізнес і порядок пріоритетів |
|
Реакція |
Початок опрацювання й контакт відповідального |
|
Відновлення |
Погоджений результат, залежності та спосіб підтвердження |
Резервна копія корисна після перевірки відновлення
Потрібно знати, що саме копіюється: код, завантажені файли, база даних і необхідна конфігурація. Окремо визначають місце зберігання, доступи та строк утримання копій. Копіювання в той самий обліковий запис, який може бути втрачений разом із сайтом, не покриває всі сценарії. Готовність підтверджують відновленням в ізольованому середовищі та перевіркою важливих функцій.
У роботі над поточним сайтом ALL IT Agency ми зберігали окремі локальні копії та звіряли файли за SHA-256 перед змінами. Це перевіряє цілісність скопійованих файлів. Водночас сам збіг контрольних сум не замінює перевірки запуску всього застосунку та, за наявності бази даних, її відновлення.
Навчальний сценарій: сайт відкривається, заявок немає
Зовнішня перевірка головної бачить успішну відповідь, але канал надсилання звернень зламався. Моніторинг доступності не обов’язково помітить таку ситуацію. Для критичних функцій потрібні окремі контрольні сценарії та журнал результатів. Тестове звернення має бути позначене й погоджене, щоб не створювати зайві заявки реальній команді.
Після виправлення перевіряють не лише нове надсилання, а й наявність збережених звернень за час інциденту. Відповідальний має розуміти, чи є втрачені дані та чи потрібно вручну опрацювати чергу. Саме вплив на процес визначає завершення інциденту.
Як організувати зміни без зайвого ризику
Оновлення спочатку перевіряють у відповідному тестовому середовищі. До зміни погоджують резервну копію, спосіб перевірки й умови повернення. Після неї проходять основні маршрути, форми та інтеграції. Звіт підтримки має пояснювати, що змінилося, чим підтверджено результат і які залежності залишилися. Це корисніше за перелік технічних дій без їхнього впливу на сайт.
Джерела та подальше читання
