Если сайт перестал открываться, часть пользователей видит ошибки или заявки не доходят, цель первых действий — не любой ценой найти окончательную причину. Сначала нужно ограничить влияние на бизнес, назначить одного координатора, зафиксировать факты и безопасно восстановить критичный сценарий. Разбор первопричины и постоянное исправление идут следом.
Не начинайте с перезапуска всех сервисов, смены DNS или восстановления резервной копии «на всякий случай». Такие действия могут увеличить простой, скрыть исходную ошибку и усложнить возврат к рабочему состоянию.
Что делать в первые минуты
Удобно заранее согласовать контрольные точки: первые 15 минут, следующий час и период после восстановления. Это не обещание срока ремонта и не универсальный SLA, а ориентир для действий; реальные сроки зависят от архитектуры, доступа к инфраструктуре и тяжести сбоя.
В начале инцидента:
- Зафиксируйте время, адрес страницы, текст ошибки и условия воспроизведения.
- Проверьте симптом с другого устройства или сети. Это помогает отличить локальную проблему от массовой, но не доказывает конкретную причину.
- Пройдите главный путь клиента: открытие страницы, каталог, корзина, вход, форма, оплата или обмен с CRM — только безопасными проверками, согласованными для рабочего сайта.
- Остановите несогласованные релизы и параллельные правки. Во время аварии изменения должен контролировать один ответственный.
- Назначьте координатора, технического исполнителя и человека для обновлений бизнесу. В небольшой команде роли может совмещать один специалист, но ответственность всё равно должна быть явной.
- Сообщите, что известно, что пока является гипотезой и когда будет следующее обновление.
Такой порядок поддерживает три вещи: координацию, понятную коммуникацию и контроль изменений. Сходный принцип описан в руководстве Google SRE по управлению инцидентами, где разделяются координация, техническая работа и коммуникация.
Как оценить серьёзность сбоя
Приоритет задают не громкость сообщения об ошибке и не должность того, кто первым написал в чат, а влияние на рабочий сценарий.
Критичным обычно считают случай, когда недоступен весь сайт, нарушена безопасность, нельзя оформить заказ, оплатить его или отправить заявку. Высокий приоритет нужен и при частичном сбое, если он затрагивает заметную долю пользователей или ключевой источник продаж. Косметическая ошибка без влияния на действие пользователя может подождать плановой очереди.
Для быстрой оценки ответьте на вопросы:
- кто столкнулся с проблемой: все посетители, один регион, мобильные пользователи или только сотрудники;
- какой сценарий нарушен и есть ли безопасный обходной путь;
- когда впервые увидели симптом и что менялось перед этим;
- затронуты ли данные, платежи, доступы или персональная информация;
- растёт ли масштаб ошибки по мониторингу и журналам событий.
Обозначения вроде P1, P2 и P3 полезны только вместе с письменными критериями. Их значения и время реакции нужно закрепить в договорённостях по поддержке, а не придумывать во время аварии.
Кому это актуально
План нужен владельцу сайта, руководителю продукта, маркетингу и службе продаж, если веб-проект принимает заявки, заказы или платежи, связан с CRM, 1С и внешними API либо обслуживает личные кабинеты. Особенно важен он для проекта, где несколько подрядчиков отвечают за разные части системы: без единого координатора каждый видит только свой участок.
Небольшому информационному сайту тоже полезен короткий регламент: контакт ответственного, список критичных страниц, доступ к мониторингу и понятный канал аварийного обращения. Сложная многостраничная инструкция не обязательна, если риски и роли невелики.
Безопасная диагностика и границы самостоятельных действий
Наблюдаемый симптом редко указывает на одну причину. Ошибка после релиза может быть связана с кодом, конфигурацией или миграцией базы; медленная страница — с запросами к базе, внешним API, очередью или нехваткой ресурсов; недоступность у части аудитории — с DNS, сертификатом, сетью, CDN или правилами защиты.
Владелец проекта без доступа к инфраструктуре может безопасно:
- записать точный URL, время и последовательность действий;
- сохранить снимок экрана и идентификатор ошибки без персональных данных;
- сравнить работу на Wi‑Fi и мобильной сети, в обычном и приватном окне;
- проверить публичную страницу статуса зависимого сервиса;
- перечислить последние релизы, настройки и подключения, не меняя их повторно.
Граница самостоятельной проверки проходит там, где действие меняет рабочую систему: перезапуск процессов, откат базы, восстановление копии, смена DNS, правил CDN/WAF или прав доступа. Без актуальной копии, плана возврата и понимания зависимостей это уже работа технического специалиста. При признаках компрометации нельзя удалять журналы и «чистить» сервер до сохранения данных для расследования.
Рекомендации NIST SP 800-61 Rev. 3 рассматривают реагирование не как разовую починку, а как часть постоянного управления рисками: подготовка, обнаружение, ответ, восстановление и улучшение процесса связаны между собой.
Какие риски закрывает регламент
Регламент не гарантирует, что сайт никогда не сломается. Он снижает ущерб от несогласованных действий: два специалиста не меняют одну конфигурацию одновременно, бизнес не получает противоречивые версии, а команда не объявляет проблему закрытой после единственной удачной загрузки страницы.
Ещё один риск — восстановить внешний симптом, но оставить нерабочей заявку, оплату, фоновую очередь или обмен с CRM. Поэтому технический статус сервера нужно связывать с проверкой пользовательского пути. Отдельно фиксируют временную меру и постоянное исправление: аварийный обход может вернуть продажи, но не заменяет устранение причины.
Как подтвердить восстановление
Инцидент можно переводить в закрытый статус, когда выполнены заранее определённые критерии:
- критичные страницы и API отвечают штатно;
- основной пользовательский сценарий пройден в согласованной тестовой среде или безопасным тестовым способом;
- уровень ошибок и время ответа вернулись к обычному диапазону проекта;
- исправление проверено с нужных устройств, сетей или регионов, если сбой был выборочным;
- в течение согласованного окна наблюдения проблема не повторилась;
- временные изменения записаны, назначены ответственные за постоянный фикс и разбор причины.
После восстановления нужен короткий разбор без поиска виноватого: хронология, влияние, подтверждённая причина, что помогло, что задержало реакцию и какое изменение предотвратит повтор. Если причина пока не доказана, так и фиксируют — рабочий сервис ещё не означает завершённое расследование.
Что запросить у подрядчика
До следующего инцидента попросите подрядчика показать:
- критерии критичности и время первичной реакции;
- единый канал для аварийных обращений и резервный контакт;
- список доступов и порядок их безопасного хранения;
- схему ключевых зависимостей: хостинг, DNS, CDN, база, CRM, оплата, почта;
- правила релиза, отката и проверки резервных копий;
- шаблон обновления статуса и итогового разбора;
- критерии, по которым восстановление считается подтверждённым.
Это позволяет оценивать не обещание «быстро починим», а проверяемый процесс.
Как это решает OpenStart
OpenStart подключается, когда простая пользовательская проверка не локализует сбой, проблема затрагивает несколько слоёв или у проекта нет ответственного за весь путь от браузера до CRM. Команда может начать с диагностики, отделить гипотезы от подтверждённых причин, согласовать безопасный план восстановления и зафиксировать последующие задачи.
Если нужен разовый разбор недоступности, подходит диагностика и восстановление сайта. Когда важны постоянный мониторинг, регламент реакции и очередь профилактических работ, полезнее регулярная поддержка сайта.
FAQ
Нужно ли сразу менять хостинг, если сайт упал?
Нет. Хостинг — только одна из возможных зон сбоя. Сначала зафиксируйте масштаб и проверьте код ответа, последние изменения, зависимости и данные мониторинга. Переезд во время неразобранного инцидента может добавить новые переменные.
Можно ли считать проблему решённой, если главная страница открылась?
Нет. Нужно проверить именно затронутый сценарий: форму, корзину, оплату, вход или обмен данными. Затем стоит наблюдать систему в согласованное время, потому что кратковременное улучшение ещё не подтверждает устойчивость.
Нужен ли отдельный координатор небольшой команде?
Отдельная должность не обязательна. Но один человек должен принимать решения о приоритете, изменениях и обновлениях статуса, чтобы остальные не действовали вразнобой.
Когда можно справиться без подрядчика?
Если проблема локальна, не требует изменения рабочей системы и устраняется штатной операцией с понятным возвратом, может хватить внутреннего специалиста. При риске для данных, платежей, инфраструктуры или нескольких интеграций нужна техническая диагностика с доступом к журналам и планом отката.