Регламент действий веб-студии при падении сайта: первые 60 минут

3 августа 2026 · 14 мин чтения

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

1. понять реальное влияние;
2. восстановить пользовательскую функцию;
3. сообщать клиенту проверенные факты.

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

Рабочий регламент не требует отдельного отдела SRE. Даже студия из трёх человек может заранее определить роли, первые действия, тексты сообщений и критерии восстановления.

Ниже — playbook первых 60 минут для подтверждённого сбоя клиентского сайта.

Коротко: порядок действий

0–5 минут

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

5–15 минут

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

15–30 минут

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

30–60 минут

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

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

Что должно существовать до аварии

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

До первого инцидента у студии должны быть:

• паспорт сайта;
• владелец со стороны клиента;
• дежурный и резервный специалист;
• шкала критичности;
• каналы P1/P2/P3;
• доступы или процедура их получения;
• инструкция резервного восстановления;
• список критических функций;
• технические окна;
• шаблоны сообщений;
• адрес статус-страницы, если она используется;
• правило, кто может согласовать аварийное изменение.

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

Шаг 1. Подтвердите пользовательское влияние

Алерт — сигнал для проверки, а не готовый диагноз.

За первые минуты ответьте:

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

Минимальное подтверждение

1. Повторить проверку свежим запросом.
2. Проверить из второй сети или региона.
3. Открыть критический путь без административной сессии.
4. Сравнить внешний сигнал с состоянием CMS и сервера, если оно доступно.
5. Зафиксировать точное время и скриншот или ответ.

Не начинайте разговор с клиентом фразой «сервер упал», если подтверждено только то, что страница не открылась. Сервер может быть исправен, а причиной окажется DNS, CDN, приложение или региональная маршрутизация.

Безопасная внутренняя формулировка:

В 14:02 подтверждена недоступность оформления заказа из двух точек. Главная и каталог доступны. Причина устанавливается.

Шаг 2. Назначьте уровень серьёзности

Для небольшой студии достаточно трёх уровней.

Уровень	Критерий	Пример
P1	Критическая функция недоступна, воздействие массовое или есть активный риск безопасности	Магазин не принимает заказы, сайт перенаправляет на чужой домен, весь проект недоступен
P2	Нарушена часть функций, влияние ограничено или есть обходной путь	Одна форма сломана, недоступен важный регион, обмен с 1С задержан
P3	Пользовательского ущерба пока нет, но требуется плановое действие	SSL истекает, диск приближается к порогу, модуль устарел

Во время активного падения чаще всего речь идёт о P1 или P2.

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

Шаг 3. Откройте один инцидент

Не создавайте отдельные задачи «сайт не открывается», «форма упала», «ошибка 500» и «клиент написал», если это одно событие.

У карточки инцидента должны быть:

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

Пример названия:

P1 · «Северный магазин» · оформление заказа недоступно

Плохо:

Срочно! Всё сломалось!

Шаг 4. Разделите роли

Для большого инцидента полезны четыре роли.

Руководитель инцидента

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

Технический специалист

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

Ответственный за коммуникацию

• пишет клиенту и на статус-страницу;
• переводит техническое состояние на язык влияния;
• выдерживает обещанный ритм обновлений;
• не публикует неподтверждённые причины.

Хронолог

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

Если в студии три человека

• Мира — руководитель и коммуникация;
• Коди — техническая работа;
• третий специалист — хронология и резервная диагностика.

Если специалист один

Используйте строгий цикл:

1. пять-десять минут технической работы без сообщений;
2. одна минута на фиксацию результата;
3. обновление клиенту по заранее установленному времени;
4. возвращение к расследованию.

Клиент должен понимать этот ритм. Постоянный звонок «ну что там?» замедляет восстановление.

Первые 5 минут: подтвердить и собрать

Действия

1. Повторить проверку из второй точки.
2. Определить затронутый путь.
3. Открыть инцидент и временную шкалу.
4. Назначить P1 или P2.
5. Уведомить дежурного и резервного специалиста.
6. Проверить последние релизы, изменения DNS, хостинг и общие зависимости.

Чего не делать

• не перезапускать всё подряд;
• не очищать журналы;
• не обновлять CMS «вдруг поможет»;
• не обвинять хостинг до подтверждения;
• не обещать время восстановления;
• не писать «данные не пострадали», если это не проверено.

5–15 минут: ограничить ущерб и открыть коммуникацию

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

Возможные меры локализации

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

Выбирайте обратимое действие с минимальным дополнительным риском.

Первое сообщение клиенту

Сообщение должно содержать четыре элемента:

1. что подтверждено;
2. что затронуто;
3. что команда делает;
4. когда будет следующее обновление.

Шаблон P1

В 14:02 мы подтвердили недоступность оформления заказа. Главная и каталог работают, но завершить покупку сейчас нельзя. Команда занимается восстановлением, рекламный трафик временно приостановлен. Следующее обновление отправим не позднее 14:30.

Если причина неизвестна

Мы видим ошибки при открытии сайта из нескольких сетей. Причина пока не подтверждена. Проверяем хостинг, DNS и последние изменения. Следующее обновление — до 11:20.

Если клиент сообщил первым

Спасибо за сигнал. Мы подтвердили проблему с [функция] и открыли инцидент. Сейчас проверяем влияние и последние изменения. Следующее обновление дадим до [время].

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

15–30 минут: восстанавливать функцию, а не искать идеальную причину

Во время активного P1 приоритет — прекратить пользовательский ущерб. Полное расследование причины можно продолжить после восстановления.

Рассмотрите по порядку:

1. безопасный откат последнего изменения;
2. переключение на известную рабочую конфигурацию;
3. отключение некритичного проблемного модуля;
4. восстановление отдельной функции;
5. временный обходной путь;
6. развёртывание доверенной копии;
7. эскалацию провайдеру или профильному специалисту.

Для каждого изменения запишите:

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

Промежуточное сообщение

Даже если нового результата нет, обновление должно выйти в обещанное время.

Причину локализовали в модуле оформления заказа. Восстанавливаем предыдущую рабочую версию. Сайт и каталог доступны, оформление пока ограничено. Следующее обновление — до 15:00.

Если причина не установлена:

Работа продолжается. Мы исключили проблему DNS и проверяем приложение и базу данных. Пользовательское влияние не изменилось. Следующее обновление — до 15:00.

Фраза «новостей нет» лучше молчания, если она подтверждает, что команда продолжает управлять ситуацией.

30–60 минут: подтвердить восстановление

Технический специалист сообщает «починил». Руководитель инцидента отвечает: «Как мы это доказали?»

Проверка после изменения

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

Восстановление — это не зелёная главная страница, а успешный пользовательский результат.

Итоговое оперативное сообщение

Оформление заказов восстановлено в 14:46. Мы проверили создание служебного заказа и получение его менеджером. Продолжаем усиленное наблюдение до 16:00. Предварительная причина — конфликт изменения платёжного модуля; окончательный разбор и корректирующие действия отправим отдельно.

Если причина ещё не подтверждена, так и напишите. Восстановить сервис можно раньше, чем закончить расследование.

Как использовать статус-страницу

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

Она должна находиться отдельно от основного сайта и показывать:

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

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

Статус-страница не заменяет персональное сообщение владельцу бизнеса. Она создаёт единый публичный источник правды, а личный канал используется для решений, которые требуют клиента.

Практика подробно разобрана в статье Pingvera «Статус-страница — это про доверие».

Отдельная ветка: признаки взлома или утечки

Обычный план восстановления нельзя механически применять, если:

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

В таком случае:

1. защитите посетителей и ограничьте опасную функцию;
2. сохраните журналы, снимки и доказательства;
3. не удаляйте первый найденный файл до фиксации;
4. отзовите доступы по согласованной процедуре;
5. привлеките специалиста по информационной безопасности;
6. отдельно определите обязанности по уведомлению с юристом или специалистом по комплаенсу;
7. не заявляйте «данные не пострадали» без расследования.

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

После восстановления: короткий разбор

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

Минимальный разбор отвечает на вопросы:

1. Что произошло?
2. Какое было пользовательское и бизнес-влияние?
3. Когда проблема началась, обнаружилась и завершилась?
4. Что помогло восстановить функцию?
5. Что замедлило реакцию?
6. Где команде повезло?
7. Какое конкретное действие уменьшит вероятность или влияние повтора?

Хорошее корректирующее действие

Добавить проверку доставки формы каждые пять минут. Владелец — руководитель поддержки. Срок — 8 августа. Критерий завершения — тестовая заявка создаётся и доставляется в отдельный ящик, а сбой открывает P1.

Плохое действие

Улучшить мониторинг.

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

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

Копируемый incident playbook

# Инцидент [ID]: [краткое фактическое название]

Клиент: [название]
Сайт: [URL]
Уровень: [P1 / P2]
Статус: [исследуем / локализовали / наблюдаем / восстановлено]
Начало влияния: [время и пояс]
Обнаружено: [время и источник]

## Подтверждённое влияние

- Затронуто: [функция и аудитория]
- Работает: [незатронутые функции]
- Пока неизвестно: [вопросы]

## Роли

- Руководитель инцидента: [имя]
- Технический специалист: [имя]
- Коммуникация: [имя]
- Хронология: [имя]

## Контрольные действия

- [ ] Повторить проверку из второй точки
- [ ] Пройти затронутый пользовательский путь
- [ ] Проверить последние изменения
- [ ] Проверить общие зависимости
- [ ] Определить безопасную локализацию
- [ ] Отправить первое сообщение клиенту
- [ ] Назвать время следующего обновления
- [ ] Зафиксировать каждое изменение и откат
- [ ] Подтвердить восстановление бизнес-функции
- [ ] Отправить итоговое сообщение
- [ ] Назначить усиленное наблюдение
- [ ] Создать корректирующие действия

## Временная шкала

- [14:02] [наблюдение или действие]
- [14:05] [наблюдение или действие]

## Следующее обновление

[время, канал, ответственный]

## Критерий закрытия

[какой пользовательский результат должен быть подтверждён]

Одностраничный регламент для стены студии

СИГНАЛ
↓
Подтвердить из второй точки и пройти пользовательский путь
↓
Назначить P1/P2 и открыть один инцидент
↓
Руководитель управляет · специалист чинит · ответственный сообщает
↓
Первое сообщение: влияние + действие + следующее обновление
↓
Сначала безопасно восстановить функцию, затем завершить расследование
↓
Проверить результат снаружи и по бизнес-пути
↓
Сообщить о восстановлении и продолжить наблюдение
↓
Разбор: факты, влияние, действия, владелец и срок улучшения

Проведите учебный инцидент

Регламент, который никогда не проверяли, может не сработать в реальной аварии.

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

• недоступность тестового контура;
• отказ контрольной формы;
• пропущенный heartbeat учебной cron-задачи;
• истекающий демонстрационный сертификат;
• сбой тестового checkout.

Проверьте:

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

Не устраивайте необъявленное падение production ради учений.

Как помогает Pingvera

Pingvera может создать фактическую основу инцидента:

• подтвердить недоступность из нескольких точек;
• зафиксировать время начала и восстановления;
• показать, какая проверка нарушена;
• отправить событие в Telegram, email, MAX или webhook;
• связать состояние со статус-страницей;
• перепроверить форму, домен, SSL, CMS или серверный сигнал;
• сохранить результат для клиентского отчёта.

Но распределение ролей, техническое исправление, публичная формулировка и решение об эскалации остаются ответственностью студии.

Подготовьте процесс до аварии: создайте критические проверки, два независимых канала и статус-страницу, а затем проведите учебный инцидент. Настроить мониторинг в Pingvera.

Часто задаваемые вопросы

Нужно ли сообщать клиенту до того, как найдена причина?

Для подтверждённого P1 — да, если это соответствует договору и роли студии. Сообщите наблюдаемое влияние и время следующего обновления. Причину можно честно обозначить как неизвестную.

Что важнее: найти причину или восстановить сайт?

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

Кто должен общаться с клиентом?

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

Как часто обновлять статус?

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

Когда закрывать инцидент?

После подтверждения пользовательского результата, а не после изменения конфигурации. Если клиенту сообщали об открытии, отправьте итог. Если риск повтора остаётся, переведите событие в этап наблюдения.

Нужен ли полный postmortem после каждого короткого сбоя?

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

Главное

Спокойная реакция — результат подготовки, а не характера конкретного сотрудника.

Хороший регламент заранее отделяет подтверждение от догадки, восстановление от расследования и техническую работу от коммуникации. Тогда студия не ждёт звонка клиента и не импровизирует под давлением: она действует по известному маршруту и сохраняет доверие даже во время неприятного сбоя.

Источники и дополнительное чтение

• Atlassian Incident Management Handbook
• Atlassian: как команда реагирует на инцидент
• Atlassian: коммуникация во время инцидента
• Atlassian: blameless postmortem
• Google SRE: Managing Incidents
• Pingvera: статус-страница и доверие
• Pingvera: мониторинг без доступа к серверу

Следующие материалы курса: «Шкала критичности инцидентов для небольшой студии» и «Что написать клиенту в первые десять минут сбоя».

Читайте также: Сайт клиента упал: как узнать об этом раньше клиента · Перехватывают клиентов с сайта: как узнать и что делать · Отчёт об инциденте сайта: шаблон для клиента · Регламент мониторинга сайтов клиентов: шаблон · Проверить доступность сайта из нескольких регионов.