Технічна підтримка сайту: оновлення, моніторинг, SLA
Сайт на Laravel 8 з PHP 7.4. PHP 7.4 вийшов з підтримки у листопаді 2022. Laravel 8 — у лютому 2023. Уразливості закриваються тільки для підтримуваних версій, для старих — нема. Хостинг-провайдер попередив про обов'язкове оновлення PHP до 8.1 — і після оновлення два плагіни та одна бібліотека сломалися, сайт упав. Це стандартний сценарій для проектів без регулярного технічного обслуговування.
Що реально входить у підтримку
Підтримка — не «відповісти на дзвінок коли щось сломалось». Це систематичне попередження поломок.
Оновлення залежностей. Composer packages, npm packages, сама CMS або фреймворк. composer audit та npm audit показують відомі уразливості у залежностях. Dependabot або Renovate створюють автоматичні PR з оновленнями — задача підтримки перевірити, що оновлення не сломало щось у staging-окруженні, та змержити.
Оновлення бувають: patch (1.2.3 → 1.2.4, тільки bugfix, безпечно), minor (1.2.0 → 1.3.0, нові фічі з назадною сумісністю, зазвичай безпечно), major (1.x → 2.x, ломаючі зміни, потребують тестування). Ігнорування оновлень 6+ місяців означає накопити технічний борг: коли доведеться оновлюватися — розрив більший, роботи більше.
WordPress — окремий розговір. Популярність платформи робить її головною ціллю атак. Застарілі плагіни — вектор №1 взломів. Регулярні оновлення ядра, плагінів, тем + правильні дозволи файлової системи + WAF — необхідний мінімум.
Моніторинг: що потрібно відслідковувати
Uptime моніторинг. Базовий HTTP-чек раз на хвилину. Betteruptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Алерт у Telegram або Slack при падінні — і сповіщення при відновленні. Якщо сайт недоступний 10 хвилин у робочий час — це вже збиток.
Продуктивність. TTFB, LCP, INP — відслідковуємо через Google Search Console (реальні дані користувачів, CrUX) та синтетичний моніторинг (Lighthouse CI, SpeedCurve). Деградація продуктивності часто поступова — без моніторингу замічають через місяць коли LCP вже 5s.
Помилки застосунку. Sentry — стандарт для відслідковування JavaScript та PHP/Python помилок у реальному часі. Кожна необроблена виключення з трасуванням стеку, контекстом запиту, версією браузера. Особливо важливо для помилок, які користувачі не повідомляють — вони просто йдуть.
База даних. Ріст обсягу, повільні запити (MySQL slow query log, pg_stat_statements для PostgreSQL), розмір індексів. Таблиця без VACUUM у PostgreSQL розростається до гігабайта через dead tuples. Рутинне обслуговування БД — частина підтримки.
Дискове місце та логи. logrotate налаштований? /var/log/nginx зростає без обмежень та заповнює диск — класика. Автоматична ротація + алерт при disk > 80%.
Резервне копіювання
Бекап без перевірки відновлення — не бекап, а ілюзія безпеки. Бачили випадки, коли mysqldump створював файл 0 байт через помилку прав, а ніхто не перевіряв вміст місяцями.
Схема бекапів:
- Щоденний інкрементальний бекап бази даних + медіафайли
- Щотижневий повний бекап
- Зберігання: мінімум 3 копії, 2 різних медіа, 1 offsite (S3, Backblaze B2)
- Автоматична перевірка цілісності бекапу (pg_restore --list, mysqldump verify)
- Тестове відновлення раз на квартал у ізольоване окруження
Retention політика: 7 щоденних, 4 щотижневих, 3 щомісячних. S3 Lifecycle rules автоматизують видалення.
SLA: що це означає на практиці
SLA (Service Level Agreement) — конкретні зобов'язання з часу реакції та відновлення:
| Пріоритет | Ситуація | Час реакції | Час рішення |
|---|---|---|---|
| Критичний | Сайт недоступний | 30 хв | 4 години |
| Високий | Ключова функція не працює | 2 години | 8 годин |
| Середній | Помилки окремих сторінок | 4 години | 24 години |
| Низький | Косметичні правки | 24 години | 72 години |
SLA має сенс тільки при наявності моніторингу — інакше про проблеми дізнаються від користувачів, а не від систем. На якійсь нерабочій кнопці у формі можна втратити конверсію тижнями непомітно.
Процес оновлення контенту
Розробник не повинен бути в ланцюжку для правки тексту на сторінці. CMS з зручним редактором, розмежування прав (редактор править контент, не трогає код), історія змін. Для Laravel-проектів — Nova, Filament, або headless CMS (Strapi, Contentful) залежно від складності.
Preview перед публікацією, staged rollout для важливих змін. Якщо редактори працюють напрямку з prod — це ризик.
Типові ситуації, які вирішуємо
Взлом сайту: аналіз вектора атаки, очистка, посилення безпеки (WAF, fail2ban, обмеження прав файлової системи). Відновлення з бекапу займає години, а не дні — якщо бекапи налаштовані правильно.
Падіння продуктивності після оновлення: feature flag + можливість швидкого rollback. Canary деплой — оновлюємо 5% трафіку, дивимось метрики, потім 100%.
Процес роботи
Онбординг: аудит поточного стану, налаштування моніторингу та бекапів, документування інфраструктури. Потім регулярний ритм: щотижневий звіт по метриках, щомісячний огляд оновлень, квартальний технічний аудит.
Строки
Налаштування моніторингу та бекапів: 3–5 днів. Регулярна підтримка — ongoing контракт з фіксованим обсягом годин на місяць або абонемент.