Техподдержка сайта без простоев: SLA, мониторинг, регламенты

Сайт редко падает «в рабочее время и по расписанию». Чаще — ночью, в пик рекламной кампании или в момент, когда никто не знает, у кого доступы и кто принимает решения. В итоге простой превращается не в «техническую проблему», а в потери денег, репутации и времени команды: хаотичный чат, попытки вспомнить пароли, отсутствие логов и бэкапов, зависимость от одного человека.

Нормальная техподдержка — это не «чинить баги», а процесс эксплуатации: мониторинг → инциденты → изменения → профилактика. Ниже — модель процесса, которая делает работу предсказуемой и снижает вероятность простоев.

Чтобы у сайта не было простоев, должны быть:

• мониторинг (uptime, ошибки, задержки, интеграции) и алерты 24/7;
• понятная приоритизация инцидентов (P1-P4) и SLA по реакции/восстановлению;
• единый канал обращений (тикеты) и регламент инцидент-менеджмента;
• роли и ответственность (кто что делает, кто принимает решения);
• резервное копирование + проверка восстановления (RTO/RPO);
• релизный процесс (staging, окно релиза, откат);
• регулярная отчётность (инциденты, MTTR, риски, план работ).

Что входит в техподдержку сайта: 4 контура

A) Инциденты (аварии/простои)

• обработка падений, 5xx, недоступности страниц/форм/оплаты;
• восстановление сервиса (rollback, hotfix, переключение на резерв);
• коммуникации и статус-апдейты до полного восстановления;
• постмортем: причина, меры, чтобы не повторилось.

B) Плановые работы (обновления и стабильность)

• обновления CMS/фреймворка/зависимостей, патчи безопасности;
• настройка и контроль кешей/CDN, оптимизация производительности;
• обслуживание инфраструктуры: сертификаты, домены, ресурсы (диски/CPU/RAM);
• поддержание документации (как разворачивать, как откатывать).

C) Изменения/доработки (change management)

• мелкие доработки функционала и контента, которые требуют разработки;
• регламент изменений: оценка, согласование, релиз, контроль;
• технический долг: регулярные «малые ремонты», чтобы не копить аварии.

D) Профилактика (чтобы «не случалось»)

• мониторинг uptime/ошибок/латентности/интеграций и алертинг;
• резервное копирование + регулярные тесты восстановления;
• аудит безопасности: права доступов, секреты, базовые проверки;
• контроль «третьих сторон» (виджеты/интеграции), которые часто ломают сайт.

Модель процесса: как устроить поддержку

1) Каналы обращений и «единый источник правды»

Нельзя: «пишите в чат, кто увидит — ответит».

Нужно: тикет-система как единый журнал (даже если вход — почта/чат, тикет создаётся автоматически).

Минимальный стандарт:

• все обращения фиксируются тикетами (инцидент/запрос/изменение);
• у каждого тикета есть владелец, приоритет, срок, статус, комментарии;
• решения и причины фиксируются (чтобы не повторять расследование).

2) Приоритизация P1-P4

Важно: приоритет определяется влиянием на бизнес, а не «громкостью» сообщения.

3) SLA: реакция, восстановление, статус-апдейты

SLA — это не магическое «99.99%», а понятные обещания: когда вы начнёте работать, как часто будете сообщать статус, когда планируется восстановление.

*RTO зависит от архитектуры, доступов и наличия плана отката/резерва. SLA нужно настраивать под ваш сайт и риски.

4) RACI: роли и ответственность

R = Responsible (делает), A = Accountable (отвечает), C = Consulted (консультирует), I = Informed (в курсе).

5) Эскалация и постмортемы

Процесс должен отвечать на два вопроса:

1. Что делаем, если не укладываемся? (эскалация на тимлида/архитектора/поставщика/хостинг, подключение 2-й линии)
2. Как не повторить? (постмортем по P1/P2: причина, что сработало/не сработало, меры и сроки)

Кейс, как мы разработали и оптимизировали сайт для привлечения туристов на Урал за счёт улучшения визуальной привлекательности, удобства навигации и адаптации под мобильные устройства

Минимальный набор мониторинга

Если мониторинга нет — поддержка всегда «реагирует постфактум».

1. Uptime (HTTP/HTTPS) для главных страниц и критических эндпоинтов.
2. SSL-сертификат: срок действия и корректность цепочки.
3. Домен: срок регистрации и DNS-ошибки.
4. Ошибки 5xx/4xx spikes (по логам/метрикам).
5. Latency (время ответа) по ключевым страницам/эндпоинтам.
6. Доступность БД (коннекты, slow queries — хотя бы базово).
7. Ресурсы сервера: CPU/RAM, диск, inode (типовая причина падений).
8. Очереди/фоновые задачи (если есть): зависания, ретраи.
9. Интеграции: CRM, платежи, почта, СМС — синтетические проверки.
10. Бэкапы: успешность выполнения + контроль размера/времени.
11. Алерты: маршрутизация (дежурный, резерв, эскалация).
12. Логи/ошибки фронта (если сайт сложный): чтобы ловить деградации до жалоб.

Бэкапы, RTO/RPO и план восстановления

RTO — сколько времени вы можете «быть в простое» до восстановления.
RTO — сколько данных вы готовы потерять (насколько «старым» может быть бэкап).

Минимум, который должен быть:

• регулярные бэкапы файлов + базы данных;
• хранение копий вне основного сервера (иначе падение сервера = падение бэкапов);
• периодическая проверка восстановления (иначе «бэкап» — иллюзия).

Практический подход:

• для сайтов, где важны заявки/заказы: RPO стремится к часам/минутам, RTO — к часам (в зависимости от бюджета и архитектуры);
• для контентных проектов без транзакций: допустим RPO больше, но всё равно нужна проверка восстановления.

Релизный процесс без простоев

Бóльшая часть аварий случается «после маленькой правки». Поэтому поддержка = ещё и управление релизами.

Базовые элементы:

• staging (тестовое окружение) максимально близкое к production;
• окно релиза (когда выкатываем) и правило «не релизим в пик»;
• rollback (план отката) — до начала релиза;
• опционально: feature flags для рискованных изменений.

Отчётность и прозрачность

Если поддержка работает «в тени», она кажется дорогой. Если есть цифры и план — это управляемая эксплуатация.

Что должно быть в ежемесячном отчёте:

• список инцидентов P1-P4 (дата/время, влияние, причина, решение);
• метрики: MTTA (время до реакции), MTTR (время восстановления), количество повторов;
• выполненные плановые работы (обновления, оптимизация, безопасность);
• риски и «горячие точки» (что может упасть следующим);
• план работ на следующий месяц + приоритеты;
• список требуемых действий от заказчика (доступы, согласования, контент).

Пример структуры отчёта:

• Сводка месяца (1 страница)
• Инциденты и постмортемы
• Плановые работы и обновления
• Показатели доступности и производительности
• Риски и рекомендации
• План следующего месяца

Когда нужна поддержка по SLA

Поддержка по SLA нужна, если:

• сайт приносит деньги/лиды и простой напрямую стоит выручки;
• есть интеграции (CRM, платежи, телефония, рассылки);
• вы запускаете рекламные кампании и «пики» нагрузки;
• есть требования по ИБ/конфиденциальности;
• сайт развивается и регулярно релизится;
• команда распределённая, и «на кого свалится» не работает.

Техподдержка без простоев строится не героизмом, а системой: мониторинг → приоритизация → SLA → роли → релизы → бэкапы → отчётность. Это снижает вероятность аварий и делает инциденты управляемыми (время реакции и восстановления — предсказуемое, а не случайное).

FAQ