Аварийная поддержка4 мин чтения

Аварийный регламент для сайта, API и сервера

Кто принимает сигнал, как назначается критичность, что восстанавливать первым и какие данные сохранить, чтобы инцидент не превратился в хаотичную переписку.

Иван Седунов · Технический эксперт по веб-поддержке19 июля 2026 г.

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

Определите, что является инцидентом

Не каждая ошибка требует аварийного режима. Заранее перечислите события:

сайт полностью недоступен;
не принимаются заявки;
невозможно оформить или оплатить заказ;
не работает авторизация;
API возвращает массовые ошибки;
обмен данными остановлен;
повреждены или раскрыты данные;
сервер теряет ресурсы;
истекает критичный сертификат;
отдельная некритичная страница отображается неправильно.

У каждого класса должен быть уровень приоритета и допустимое время реакции.

Приоритет строится по влиянию

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

Оценивайте:

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

Приоритет пересматривают по мере появления фактов.

Роли во время инцидента

Минимально нужны:

координатор — принимает приоритет и фиксирует решения;
технический исполнитель — диагностирует и восстанавливает;
владелец бизнеса — определяет критичный сценарий и допустимые компромиссы;
ответственный за коммуникацию — сообщает статус сотрудникам или клиентам.

В небольшой команде роли совмещаются, но ответственность должна оставаться явной. Несколько людей не должны одновременно менять сервер без общей картины.

Что должно быть готово заранее

карта доменов, серверов и сервисов;
отдельные технические доступы;
контакты провайдеров;
расположение журналов;
рабочий мониторинг;
резервные копии;
инструкция развертывания;
список критичных сценариев;
канал аварийной связи;
шаблон короткого статуса.

Копии проверяются по процедуре из материала о резервном копировании сайта и сервера.

Первый сигнал

Мониторинг или сотрудник создает запись с временем, симптомом и источником. Сначала подтверждают проблему независимой проверкой и определяют границу: один пользователь, одна функция, приложение, сервер или внешняя сеть.

Фиксируют:

точный URL или endpoint;
время обнаружения;
код и текст ошибки;
последние изменения;
затронутые функции;
состояние мониторинга;
кто принял инцидент.

Порядок технической диагностики недоступного ресурса описан в статье «Сайт перестал работать».

Сначала стабилизация, потом исправление

Цель первого этапа — вернуть критичный сценарий безопасным способом. Это может быть откат релиза, переключение на резерв, временное отключение проблемной функции или увеличение ресурсов.

Временное решение должно быть явным и иметь срок удаления. Нельзя оставить отключенную проверку безопасности или ручной обход как постоянную архитектуру.

Правила изменений

Во время аварии особенно опасны одновременные несвязанные правки. Для каждого действия записывают исполнителя, время, ожидаемый эффект и результат.

Перед потенциально разрушительной операцией сохраняют журналы и актуальные данные. Нельзя очищать диск удалением логов до их копирования или восстанавливать старую базу поверх новых заказов без сверки.

Если действие не изменило симптом, его не повторяют бесконечно. Возвращаются к гипотезе и собирают новую информацию.

Коммуникация

Короткий статус отвечает на четыре вопроса:

Что затронуто.
Когда обнаружено.
Что делает команда.
Когда будет следующее обновление.

Не нужно публиковать непроверенную причину и технические детали, раскрывающие уязвимость. Фраза «работаем» без времени следующего статуса тоже не помогает.

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

HTTP 200 недостаточно. Выполняется критичный сценарий: форма создает обращение, заказ доходит до нужной системы, авторизация открывает кабинет, API обрабатывает тестовую операцию.

Проверяют журналы, очередь, уведомления и отложенные ошибки. После восстановления некоторое время сохраняется повышенное наблюдение.

Завершение инцидента

Инцидент закрывается, когда:

критичный сценарий работает;
данные сверены;
очередь обработана или контролируется;
мониторинг подтверждает стабильность;
временные меры зафиксированы;
заинтересованные получили итоговый статус.

Полное устранение первопричины может стать отдельной плановой задачей, но она получает ответственного и срок.

Разбор причины

Разбор нужен не для поиска виноватого. Он отвечает:

что произошло;
почему сигнал появился именно так;
что задержало обнаружение;
какие действия помогли или помешали;
почему защита не сработала;
какое изменение снизит вероятность повтора.

Результатом становятся конкретные меры: новая проверка мониторинга, ограничение ресурса, изменение релиза, документация, резервирование или тест.

Учебная проверка

Регламент полезно периодически проходить без реальной аварии. Выберите сценарий: недоступен сервер, истек сертификат или остановилась очередь. Проверьте, находятся ли доступы, доходят ли уведомления и понятно ли, кто принимает решение.

Страница технической веб-поддержки объединяет мониторинг, аварийную реакцию и последующее устранение причин в один контур.

Частые вопросы

Нужен ли регламент небольшому сайту?

Если сайт приносит заявки или выполняет обязательную функцию, достаточно короткого документа на одну страницу. Масштаб регламента должен соответствовать риску, но контакты, доступы и порядок восстановления нужны всегда.

Кто имеет право запускать откат?

Это определяется заранее. Технический исполнитель оценивает возможность, а владелец процесса подтверждает влияние на данные и бизнес. Для очевидного безопасного сценария полномочие можно делегировать.

Как часто обновлять регламент?

После изменения инфраструктуры, команды или критичной интеграции, а также после каждого значимого инцидента. Устаревший документ создает ложную уверенность.

Нужно ли уведомлять клиентов о каждом сбое?

Зависит от влияния и длительности. Внутреннюю краткую ошибку можно не публиковать, но при заметной недоступности честный статус снижает поток обращений и неопределенность.