Техническая поддержка сайта: обновления, мониторинг, 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) — конкретные обязательства по времени реакции и восстановления:

SLA имеет смысл только при наличии мониторинга — иначе о проблемах узнают от пользователей, а не от систем. На какой-то нерабочей кнопке в форме можно потерять конверсию неделями незаметно.

Процесс обновления контента

Разработчик не должен быть в цепочке для правки текста на странице. CMS с удобным редактором, разграничение прав (редактор правит контент, не трогает код), история изменений. Для Laravel-проектов — Nova, Filament, или headless CMS (Strapi, Contentful) в зависимости от сложности.

Preview перед публикацией, staged rollout для важных изменений. Если редакторы работают напрямую с prod — это риск.

Типичные ситуации, которые решаем

Взлом сайта: анализ вектора атаки, очистка, усиление безопасности (WAF, fail2ban, ограничение прав файловой системы). Восстановление из бэкапа занимает часы, а не дни — если бэкапы настроены правильно.

Падение производительности после обновления: feature flag + возможность быстрого rollback. Canary деплой — обновляем 5% трафика, смотрим метрики, потом 100%.

Процесс работы

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

Сроки

Настройка мониторинга и бэкапов: 3–5 дней. Регулярная поддержка — ongoing контракт с фиксированным объёмом часов в месяц или абонемент.