Разбор массового сбоя: образец отчёта (постмортем)
Кратко
Разбор сбоя — документ, который пишут после того, как всё восстановлено, и единственная его цель — чтобы это не повторилось. Он не отчёт руководству и не способ найти виноватого: как только он становится тем или другим, люди начинают скрывать подробности, и документ теряет всякий смысл. Ниже — готовая форма.
Готовый образец
РАЗБОР СБОЯ <краткое название, например: недоступность портала 12.ММ>
Составил: <ФИО> · Дата разбора: <ДД.ММ.ГГГГ> · Участники: <перечень> · Состояние: <черновик / согласован>
1. Сводка в четыре строки
С <ЧЧ:ММ> до <ЧЧ:ММ> <ДД.ММ> <что именно было недоступно или работало неверно>.
Затронуто: <число пользователей / клиентов, каких именно>.
Причина: <одна фраза, без обвинений>.
Устранено: <что сделали, чтобы восстановить>.
2. Влияние
| Показатель | Значение |
|---|---|
| Длительность | <3 ч 20 мин> |
| Затронуто пользователей | <около 180> |
| Обращений получено | <47> |
| Невыполненных операций | <оценка: 210 неоформленных заказов> |
| Обнаружено кем | <пользователем / наблюдением / сторожем> |
| Время до обнаружения | <41 минута> |
| Время до первого уведомления пользователей | <1 ч 05 мин> |
3. Хронология — только факты с точным временем, без выводов
| Время | Событие | Откуда известно |
|---|---|---|
| <11:40> | <изменение настройки … выкачено на боевую систему> | <журнал изменений> |
| <11:52> | <первые ошибки в журнале> | <журнал ошибок> |
| <12:21> | <первое обращение пользователя> | <обращение № 1234> |
| <12:33> | <оператор заметил четвёртое однотипное обращение, объявил массовый сбой> | <переписка службы> |
| <12:45> | <уведомление пользователям отправлено> | <рассылка> |
| <13:10> | <причина определена> | <переписка> |
| <15:00> | <восстановлено> | <журнал> |
| <15:12> | <уведомление о восстановлении> | <рассылка> |
4. Почему это стало возможным — цепочка, а не одна строка
| № | Вопрос | Ответ |
|---|---|---|
| 1 | Почему <пользователи не могли работать>? | <потому что …> |
| 2 | Почему <это произошло>? | <потому что …> |
| 3 | Почему <это не было замечено на проверке>? | <потому что …> |
| 4 | Почему <сбой не заметили 41 минуту>? | <потому что наблюдение следило за доступностью страницы, а не за успешностью операции> |
| 5 | Почему <уведомление ушло через час>? | <потому что решение об уведомлении принимал человек, которого не было на месте> |
Каждый ответ обязан указывать на устройство работы, а не на человека. Если ответ звучит как «потому что <имя> не проверил» — вопрос задан не до конца: спросите, почему устройство работы позволило непроверенному попасть на боевую систему.
5. Что сработало
- <Оператор объявил массовый сбой на четвёртом обращении, а не на двадцатом.>
- <Резервная копия оказалась пригодной, проверка копий за неделю до этого была не напрасной.>
6. Что мешало
- <Признак сбоя был виден в журнале с 11:52, но никто туда не смотрел: уведомления настроены не были.>
- <Решение об уведомлении пользователей ждало руководителя; замещающий назван не был.>
7. Меры — каждая с ответственным, сроком и признаком выполнения
| № | Мера | Класс | Ответственный | Срок | Признак выполнения |
|---|---|---|---|---|---|
| 1 | <Наблюдение за успешностью операции, а не только за доступностью страницы> | предотвращение | <ФИО> | <ДД.ММ> | <искусственная поломка вызывает уведомление> |
| 2 | <Право объявлять уведомление пользователям передано дежурному> | сокращение времени | <ФИО> | <ДД.ММ> | <в регламенте, доведено до смен> |
| 3 | <Изменения на боевой системе только после проверки на <стенде>> | предотвращение | <ФИО> | <ДД.ММ> | <проверка обязательна процедурой> |
| 4 | <Заготовленный текст уведомления о массовом сбое> | сокращение времени | <ФИО> | <ДД.ММ> | <текст в быстрых ответах> |
8. Контроль исполнения
Меры проверяются <руководителем службы> на <еженедельной> встрече до закрытия всех пунктов. Невыполненная в срок мера переносится с указанием причины, а не удаляется.
9. Что сообщено пользователям
| Когда | Кому | Текст |
|---|---|---|
| <12:45> | <всем затронутым> | <краткое сообщение о недоступности и ожидаемом сроке> |
| <15:12> | <всем затронутым> | <восстановлено, что делать тем, у кого …> |
| <ДД.ММ> | <клиентам по договору> | <письмо с причиной и мерами> |
Как заполнять
Раздел 3 пишите первым и только фактами. Хронология, в которую просочились оценки («слишком поздно заметили»), перестаёт быть основой и становится предметом спора. Колонка «Откуда известно» отсекает восстановленное по памяти: то, что подтверждается только воспоминанием, помечайте прямо.
Два числа из раздела 2 важнее длительности. Время до обнаружения и время до уведомления — те, на которые вы действительно влияете. Длительность восстановления зависит от характера поломки, а сорок минут незамеченного сбоя — это всегда про устройство наблюдения. Если сбой обнаружен пользователем, наблюдения по этому признаку у вас нет, как бы ни выглядела панель.
Пять вопросов в разделе 4 — не ритуал. Останавливаться нужно там, где ответ указывает на устройство работы, которое вы можете изменить. Признак, что остановились рано: последняя мера в разделе 7 звучит как «быть внимательнее».
Меры делятся на два класса, и оба обязательны. Предотвращение уменьшает вероятность повторения, сокращение времени уменьшает ущерб, когда повторится всё равно. Разбор, где все меры одного класса, почти всегда неполон.
Колонка «Признак выполнения» — против меры, которая существует только на бумаге. «Настроено наблюдение» — не признак; «искусственная поломка вызывает уведомление» — признак, потому что его можно проверить действием.
Раздел 9 отвечает на вопрос, который зададут первым. Правило массового сбоя и порядок уведомления — в статье Схема эскалации обращений; заготовленный текст сводки для пользователей — в статье Скрипт первого ответа техподдержки, ситуация 5.
Частые ошибки
Разбор с фамилиями в графе «причина». Как только документ отвечает на вопрос «кто», участники перестают сообщать подробности, а следующий разбор будет короче и бесполезнее. Правило простое: если ответ указывает на человека, спросите ещё раз — почему устройство работы это допустило.
Разбор без хронологии. Без точных времён невозможно посчитать время до обнаружения и до уведомления, а без них разбор описывает поломку, но не описывает службу.
Меры без ответственного и срока. Перечень «что стоит улучшить» закрывается через полгода сам собой, потому что о нём забывают. Мера без фамилии и даты — это пожелание.
Разбор только крупных сбоев. Двадцать обращений об одном и том же за полчаса — уже повод для разбора, даже если восстановили за двадцать минут. Именно такие случаи дешевле всего разбирать и проще всего предотвратить.
Разбор через неделю. Подробности, не записанные в первые два дня, восстанавливаются неточно и с оправданиями. Черновик разбора пишется в день восстановления, согласование — позже.
Разбор, который никто не перечитывает. Раздел 8 существует ради этого: невыполненные меры из прошлых разборов — самое точное предсказание следующего сбоя. Сводка мер и повторяющиеся причины выносятся в месячный отчёт — см. Отчёт службы поддержки за месяц: образец для руководителя.
Связанные статьи
- Схема эскалации обращений: образец правил
- Отчёт службы поддержки за месяц: образец для руководителя
- Матрица приоритетов заявок: готовая таблица
- Как проверить, что техподдержка работает: семь замеров
Нужна поддержка, которая так и работает?
TehProf Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.