---
title: Регламент действий веб-студии при падении сайта — первые 60 минут
description: Пошаговый регламент веб-студии на первые 60 минут падения сайта — подтверждение, роли, эскалация, сообщения клиенту, восстановление и postmortem для клиента.
source: https://pingvera.ru/blog/reglament-incidenta-dlya-veb-studii.html
---
# Регламент действий веб-студии при падении сайта: первые 60 минут

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

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

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

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

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

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

### 0–5 минут

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

### 5–15 минут

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

### 15–30 минут

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

### 30–60 минут

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

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

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

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

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

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

Сначала полезно оформить [приём сайта на поддержку](https://pingvera.ru/blog/priem-sayta-na-tehnicheskuyu-podderzhku.html) и [регламент мониторинга](https://pingvera.ru/blog/reglament-monitoringa-saytov-klientov.html). Иначе первые минуты уйдут на поиск фактов, которых нет.

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

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

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

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

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

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

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

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

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

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

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

Во время активного падения чаще всего речь идёт о 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. когда будет следующее обновление.

> В 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 [«Статус-страница — это про доверие»](https://pingvera.ru/blog/status-stranica-eto-doverie.html).

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

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

- посетителей направляет на чужой домен;
- появился посторонний 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](https://app.pingvera.ru/).

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

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

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

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

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

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

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

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

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

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

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

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

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

## Главное

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

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

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

- [Atlassian Incident Management Handbook](https://www.atlassian.com/incident-management/handbook)
- [Atlassian: как команда реагирует на инцидент](https://www.atlassian.com/incident-management/handbook/incident-response)
- [Atlassian: коммуникация во время инцидента](https://www.atlassian.com/incident-management/incident-communication)
- [Atlassian: blameless postmortem](https://www.atlassian.com/incident-management/handbook/postmortems)
- [Google SRE: Managing Incidents](https://sre.google/sre-book/managing-incidents/)
- [Pingvera: статус-страница и доверие](https://pingvera.ru/blog/status-stranica-eto-doverie.html)
- [Pingvera: мониторинг без доступа к серверу](https://pingvera.ru/blog/monitoring-bez-dostupa-k-serveru.html)

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