Отчёт об инциденте сайта: русский шаблон для клиента

4 августа 2026 · 11 мин чтения

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

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

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

Коротко

В отчёте нужны:

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

Если причина ещё не подтверждена, выпустите предварительный отчёт. Не заполняйте пробел правдоподобной догадкой.

Когда нужен отчёт

Полный клиентский отчёт стоит готовить, если событие:

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

Для небольшого P3 достаточно короткой карточки. Каждое событие всё равно должно оставить запись: без неё невозможно увидеть повторяемость.

Отчёт и postmortem — разные документы

Документ	Аудитория	Основная задача
Оперативное сообщение	Клиент и команда во время сбоя	Дать текущий статус и время следующего обновления
Клиентский incident report	Заказчик, аккаунт, руководство	Объяснить влияние, восстановление и дальнейшие действия
Внутренний postmortem	Техническая и операционная команда	Глубоко разобрать условия, решения, сигналы и системные причины
Security-отчёт	Ограниченный круг специалистов	Зафиксировать чувствительные факты, доказательства и обязательные действия

Один документ может быть источником для другого, но не обязан содержать одинаковую детализацию. В клиентский отчёт не вставляют секреты, персональные данные, внутренний чат, уязвимые endpoints и непроверенные предположения.

Когда отправлять

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

Практичная схема:

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

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

Готовый шаблон

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

Клиент: [название]
Сайт или сервис: [домен / функция]
Уровень: [P1/P2/P3]
Статус: [решён / наблюдение / расследование продолжается]
Версия отчёта: [предварительная / финальная]
Период влияния: [начало — конец, часовой пояс]
Дата отчёта: [дата]
Владелец: [роль и имя]

## Резюме

[2–4 предложения: какая функция нарушилась, кто был затронут,
сколько длилось подтверждённое влияние, как функция восстановлена
и каков текущий статус.]

## Влияние

- Затронутая функция: [что не мог сделать пользователь]
- Масштаб: [все / часть / известный сегмент / не установлено]
- Период: [время]
- Подтверждённые последствия: [факты]
- Возможные последствия: [что ещё проверяется]
- Данные и безопасность: [подтверждено / признаков не выявлено
  в объёме выполненной проверки / расследуется]
- Обходной путь: [был / не был / описание]

## Обнаружение

- Первый подтверждённый симптом: [время]
- Обнаружено: [Pingvera / клиент / сотрудник / провайдер]
- Инцидент зарегистрирован: [время]
- Реакция специалиста: [время]
- Почему сигнал сработал или не сработал: [факт]

## Хронология

| Время | Событие | Источник факта |
|---|---|---|
| | | |

## Что произошло

[Фактическое объяснение на понятном клиенту уровне. Отделите
непосредственную техническую причину, триггер и системные факторы.]

## Локализация и восстановление

- [Что уменьшило влияние]
- [Что вернуло функцию]
- [Какие альтернативы рассматривались]
- [Почему выбран этот способ]

## Проверка результата

- [Какие пользовательские операции прошли]
- [Из каких точек проверено]
- [Как долго продолжалось наблюдение]
- [Что остаётся под усиленным контролем]

## Что сработало хорошо

- [Процесс, сигнал или решение]

## Что потребовало улучшения

- [Пробел без обвинения человека]

## Корректирующие действия

| Действие | Тип | Владелец | Срок | Критерий готовности | Статус |
|---|---|---|---|---|---|
| | Предотвратить / обнаружить / смягчить / восстановить | | | | |

## Открытые вопросы

- [Вопрос, владелец и дата ответа]

## Источники

- Карточка инцидента: [ссылка]
- Графики и проверки: [ссылка]
- Связанный релиз: [ссылка]
- Обращение провайдеру: [номер / ссылка]

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

[Дата и время / «Отчёт финальный»]

Как написать резюме

Пишите его последним, когда остальные разделы заполнены.

Формула:

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

Пример:

4 августа с 10:42 до 11:18 мск форма заявки показывала посетителям успешную отправку, но письма не поступали в отдел продаж. Pingvera обнаружила отсутствие тестового письма в 10:44, после чего студия зарегистрировала P1. Доставка восстановлена переключением почтового маршрута и подтверждена тремя контрольными заявками. Непосредственной причиной стала недействующая авторизация SMTP; отсутствие предварительного предупреждения о сроке секрета и проверки резервного маршрута рассматривается как системный фактор. Назначены автоматический контроль доставки и ежеквартальный тест переключения.

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

Как описать влияние без выдуманных цифр

Самый важный раздел — не причина, а то, что испытал пользователь.

Пишите:

• «покупатели не могли завершить оформление»;
• «часть пользователей из региона получала ошибку соединения»;
• «форма принимала данные, но письмо не доставлялось»;
• «цены и остатки не обновлялись с 03:00»;
• «новые заказы задерживались перед передачей в 1С».

Не пишите без доказательств:

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

Если точного масштаба нет:

Подтверждённый период нарушения — 36 минут. Количество недоставленных заявок устанавливается по журналам формы, почты и CRM. До завершения сверки мы не считаем влияние равным нулю.

Разделяйте:

• подтверждённое;
• оценку с методикой;
• возможное влияние;
• неизвестное.

Как построить хронологию

Источники:

• мониторинг;
• журналы приложения и веб-сервера;
• история релизов;
• Helpdesk;
• сообщения в командном канале;
• статус внешнего провайдера;
• журнал 1С или CRM;
• подтверждение пользователя.

Нормализуйте время в один часовой пояс и укажите его в заголовке.

Разделяйте события:

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

Пример:

Время, мск	Событие	Источник
10:42	Первая тестовая заявка не доставлена	Pingvera, ID проверки
10:44	Повторная проверка подтвердила сбой	История мониторинга
10:47	Инцидент P1 принят специалистом	Helpdesk INC-214
10:51	Клиенту отправлено первое сообщение	Карточка коммуникации
11:07	Включён резервный SMTP-маршрут	Журнал изменения CHG-88
11:10	Первая контрольная заявка доставлена	Тестовый маркер
11:18	Три проверки подряд успешны	Pingvera
11:45	Период усиленного наблюдения завершён	Карточка инцидента

Если точное начало неизвестно, напишите «не позднее 10:42» или диапазон. Не превращайте время обнаружения в время начала только потому, что это первая запись.

Метрики времени

Определения должны совпадать с SLA.

Время обнаружения = обнаружено − начало влияния

Время реакции = содержательная реакция специалиста − регистрация

Время локализации = ограничение ущерба − начало влияния

Время восстановления = подтверждение пользовательской функции − начало влияния

Не смешивайте:

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

Причина, триггер и системные факторы

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

Разделите:

Триггер

Событие, которое активировало скрытую проблему.

В production опубликована новая конфигурация почтового транспорта.

Непосредственная причина

Технический механизм нарушения.

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

Системные факторы

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

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

Такая структура ведёт к действиям. Обвинение человека ведёт к совету «быть внимательнее».

Как описать восстановление

Отделите три понятия.

Локализация уменьшила ущерб:

На странице временно показан резервный телефон, рекламная кампания приостановлена.

Восстановление вернуло функцию:

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

Постоянное исправление устранило системную причину:

Секреты перенесены в управляемое хранилище, добавлен срок действия, тест переключения включён в квартальный регламент.

Если постоянного исправления ещё нет, не закрывайте его словами «исправлено полностью». Создайте задачу и укажите временную меру.

Корректирующие действия

Каждое действие должно иметь:

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

Полезные типы:

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

Слабое действие:

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

Проверяемое действие:

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

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

Что не включать в клиентскую версию

Без необходимости и отдельного согласования не публикуйте:

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

Прозрачность — это ясные факты, влияние и действия. Она не требует создавать новый риск безопасности.

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

Заполненный короткий пример

# Отчёт INC-214: заявки не доставлялись в отдел продаж

Клиент: ООО «Пример»
Сайт: example.ru
Уровень: P1
Статус: решён, корректирующие действия в работе
Период влияния: 4 августа, 10:42–11:18 мск

## Резюме

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

## Влияние

- Затронута основная форма рекламной страницы.
- Подтверждённый период — 36 минут.
- Число реальных обращений за этот период сверяется отдельно.
- Признаков раскрытия данных в выполненной проверке не выявлено;
  этот вывод относится только к доступным журналам доставки.

## Причины и факторы

Непосредственная причина: приложение не прошло SMTP-аутентификацию.
Факторы: срок секрета не контролировался, а post-release проверка
останавливалась на сообщении формы и не подтверждала доставку письма.

## Корректирующие действия

| Действие | Владелец | Срок | Критерий |
|---|---|---|---|
| Контроль доставки каждые 5 минут | Студия | 05.08 | Искусственный сбой открывает алерт |
| Контроль срока SMTP-секрета | Клиент + студия | 08.08 | Предупреждение за 14 дней |
| Тест резервного маршрута | Студия | Ежеквартально | Заявка доставлена через резерв |

Процесс подготовки

1. Назначить владельца

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

2. Сначала заполнить хронологию и влияние

Они меньше зависят от интерпретации и помогают увидеть пробелы.

3. Провести технический review

Исполнитель подтверждает причины, действия и ограничения выводов.

4. Провести клиентский review

Аккаунт-менеджер проверяет понятность и отсутствие внутреннего жаргона. Он не должен смягчать факты до бессмысленности.

5. Проверить чувствительные данные

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

6. Назначить действия до отправки

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

7. Хранить версию

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

Формат доставки

Markdown удобен как редактируемый источник. Клиенту можно дать:

• ссылку на закрытую страницу;
• PDF;
• запись в Helpdesk;
• email с кратким резюме и ссылкой;
• публичный postmortem на статус-странице для массового события.

Не отправляйте тяжёлый PDF без короткого письма. В теле укажите статус, период влияния, главное действие и требуемое решение клиента.

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

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

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

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

Собирайте отчёт из фактов, а не памяти: зафиксируйте критические проверки, единый часовой пояс и карточку инцидента заранее. Создать мониторинг в Pingvera.

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

Нужно ли писать отчёт после каждого короткого падения?

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

Можно ли отправить отчёт без установленной причины?

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

Следует ли признавать ошибку студии?

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

Нужно ли указывать потерянную выручку?

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

Чем «причина» отличается от «фактора»?

Непосредственная причина объясняет технический механизм сбоя. Факторы объясняют, почему он прошёл до production, долго не обнаруживался или тяжело восстанавливался.

Кто согласует отчёт?

Минимально — технический владелец и человек, отвечающий за клиентскую коммуникацию. Для security, данных и публичной публикации добавляются уполномоченные специалисты.

Нужно ли публиковать отчёт на статус-странице?

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

Главное

Хороший incident report не доказывает, что студия никогда не ошибается. Он доказывает, что команда знает факты, понимает влияние, умеет восстановить функцию и превращает выводы в назначенные действия.

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

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

• Google SRE: пример postmortem
• Google SRE Workbook: Postmortem Culture
• Atlassian: incident postmortems
• Atlassian: шаблон postmortem
• NIST SP 800-61 Rev. 3: Incident Response
• Pingvera: регламент действий при падении сайта
• Pingvera: сообщения клиенту при сбое

Следующий материал курса: «Blameless postmortem для небольшой веб-студии: как разбирать сбои без поиска виноватого».

Читайте также: Отчёт клиенту за поддержку сайта: что показать за месяц (+шаблон) · Что делать, если сайт клиента упал: регламент · Регламент мониторинга сайтов клиентов: шаблон · Сайт клиента упал: как узнать об этом раньше клиента · Бесплатно проверить сайт.