Техническая поддержка сайта

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

Уровни инцидентов

• P1 — сайт недоступен или не принимаются оплаты/заявки
• P2 — работает частично: сломан важный раздел, ошибки на мобильном checkout
• P3 — неудобство без прямой потери денег: битая ссылка в подвале, опечатка
• P4 — запрос на улучшение, ошибочно помеченный как «срочно»

Первые 15 минут диагностики

1. Проверить доступность снаружи и изнутри (не только «у меня открывается»)
2. Посмотреть статус хостинга, DNS, SSL, недавние деплои
3. Открыть логи веб-сервера и приложения за интервал инцидента
4. Проверить форму/оплату тестовым действием, если основной сайт жив
5. Зафиксировать время начала и симптомы для отчёта

Откат релиза vs точечный фикс

Если сбой совпал с выкладкой, быстрый откат часто дешевле, чем искать баг в проде под давлением. Для этого нужны заранее: тег в git, бэкап БД, понимание, совместима ли откатная версия со схемой данных. Точечный фикс оправдан, когда откат дороже (например, уже прошла миграция данных) или причина явно внешняя — упал CDN, истёк сертификат, заблокировал IP провайдер почты.

Коммуникация во время инцидента

• Один канал статуса для бизнеса: что знаем, что делаем, когда следующее обновление
• Не обещать «через 10 минут», пока нет гипотезы
• Если заявки не доходят — временный резервный способ связи на сайте
• После восстановления — краткий отчёт и профилактика, не только «починили»

Типичные корневые причины на практике

Чаще всего всплывают не «загадочные баги», а предсказуемые вещи: закончился диск, истёк SSL, обновился плагин с несовместимостью, изменился API CRM, сработал лимит запросов, DDoS или брутфорс админки. Регулярная профилактика снимает большую часть P1, но техподдержка должна быть готова и к редким кейсам — с чек-листом, а не с нуля.

Постмортем без поиска виноватых

1. Хронология: когда заметили, когда началось, что предприняли
2. Корневая причина, а не «ошибся Вася»
3. Действия: мониторинг, алерт, автоматический тест, смена процесса деплоя
4. Срок внедрения профилактики и ответственный

Runbook для повторяющихся сценариев

После второго одинакового инцидента имеет смысл оформить короткий runbook: «сайт отдаёт 502», «закончился диск», «CRM не принимает вебхук». В нём — проверки по порядку, ссылки на панели, команды для очистки кеша, контакты поддержки. Новый дежурный не должен каждый раз изобретать диагностику с нуля. Runbook живёт рядом с реестром доступов и обновляется после каждого постмортема одной новой строкой, а не переписыванием с нуля.

Сильная техподдержка измеряется не количеством ночных правок, а сокращением их числа квартал к кварталу за счёт профилактики и прозрачных релизов.

Взаимодействие с хостингом и внешними провайдерами

Часть инцидентов решается не кодом, а тикетом в поддержку хостинга: блокировка IP, лимиты на исходящую почту, DDoS-фильтрация, сбой дата-центра. Чтобы не терять часы на «докажите, что у вас не работает», заранее соберите пакет: точное время, traceroute, скриншот ошибки, лог HTTP-кода, номер заказа у провайдера. Для DNS и почты отдельно фиксируйте TTL записей — смена хостинга при низком TTL проходит быстрее, при высоком клиенты ещё сутки видят старый сервер.