Разбор инцидента — это одна страница текста, написанная в течение трёх рабочих дней после сбоя и отвечающая на семь вопросов: что произошло, когда заметили, кто чинил, сколько длилось, почему случилось, что меняем и к какому сроку. Не отчёт на двадцать листов и не совещание на два часа. Задача у этой страницы ровно одна — не дать тому же сбою произойти второй раз.
Без такой страницы происходит предсказуемое: аварию чинят за сорок минут, все выдыхают и возвращаются к работе. Причину никто не записывает, потому что она в этот момент кажется очевидной. Через шесть недель сбой повторяется, и выясняется, что никто уже не помнит, что именно делали в прошлый раз. Начинается второй поиск с нуля — и так до тех пор, пока кто-нибудь случайно не сложит эпизоды вместе.
Сквозной пример здесь тот же, что и в остальных материалах раздела: оптовая компания на 60 человек, ассистент в клиентском канале, классификатор обращений, автозаполнение CRM и ночной обмен с 1С:УТ по остаткам и статусам заказов. Раннее обнаружение сбоя — задача мониторинга; здесь речь о том, что происходит после того, как авария уже устранена.
Семь полей карточки разбора
Формат намеренно жёсткий: семь полей, одна страница, никаких приложений. Свободная форма превращает разбор либо в переписку, из которой ничего не извлечь, либо в документ, который никто не пишет, потому что «нужно время подготовиться». Заполняется карточка за 40–60 минут, ещё полчаса уходит на короткую встречу, где её читают вслух.
| Поле | Что писать | Пример из модельного случая |
|---|---|---|
| Что произошло | Одно предложение на языке бизнеса, а не техники | Ночной обмен с 1С:УТ не прошёл, утром остатки в CRM были вчерашние |
| Когда заметили и как | Время и источник обнаружения: сигнал, сотрудник, клиент | 10:40, менеджер увидел расхождение вручную. Сигнала не было |
| Кто чинил | Имена и роли, без оценок | Администратор системы, затем инженер подрядчика |
| Сколько длилось | От начала сбоя до восстановления, а не от момента обнаружения | С 02:10 до 11:20, то есть 9 часов 10 минут |
| Что затронуло | Объём в штуках и деньгах, а не «пострадали пользователи» | 74 заказа подтверждены по устаревшим остаткам, 6 из них — на отсутствующий товар |
| Почему случилось | Техническая причина и организационная причина отдельными строками | Кончилось место на диске: журналы обмена росли без ротации. Сигнала о свободном месте не было ни у кого |
| Что меняем и к какому сроку | Одно-три действия с фамилией и датой | Ротация журналов и сигнал «менее 20 % свободного места», инженер, до 28 апреля |
Самое ценное поле — предпоследнее, и оно же чаще всего заполняется неправильно. Техническая причина обычно мелкая и чинится за час; организационная — та, из-за которой мелочь дошла до аварии. В примере это «кончилось место» и «свободное место никто не смотрел, потому что сигнал не был ни к кому привязан». Исправление только первой даёт повтор через шесть недель.
Нарисованный (не скриншот) лист формата А4 с семью подписанными полями сверху вниз: «Что произошло», «Когда заметили и как», «Кто чинил», «Сколько длилось», «Что затронуло», «Почему случилось» (две строки: техническая причина и организационная причина), «Что меняем и к какому сроку». В поле длительности стоит «9 часов 10 минут», в поле объёма — «74 заказа, 6 на отсутствующий товар». Внизу листа — строка «срок разбора: 3 рабочих дня». Чертёжный стиль, подписи по-русски.
Правило без виноватых — это процедура, а не лозунг
Половина инцидентов начинается с действия человека: нажал не ту кнопку, выгрузил файл в старом формате, поменял настройку и забыл сказать. Пока за такое наказывают, в карточке пишут «сбой в системе», и разбор становится вымыслом: по ложной причине делают ненужную доработку, а настоящая срабатывает снова.
Посмотрите последние пять карточек. Если ни в одной нет строки вида «сотрудник сделал X, потому что в инструкции этого не было», это не значит, что люди не ошибались, — это значит, что они перестали писать правду. Нормальная доля инцидентов с действием человека в причине — примерно половина.
Удерживается правило четырьмя вещами, и все четыре — организационные, а не воспитательные.
- В карточке нет поля «виновный» — есть «кто чинил» и «почему случилось». Действие человека попадает во второе как факт хронологии, наравне с кончившимся местом на диске.
- Формулировка причины доводится до системы. Не «менеджер выгрузил не тот файл», а «форма выгрузки допускает прошлогодний шаблон и ничем это не проверяет». Первая ведёт к выговору, вторая — к правке.
- Разбор ведёт не начальник участника. Ведущий — владелец процесса или администратор системы, а руководитель сотрудника участвует как источник фактов, а не как судья.
- Результат разбора — задачи, а не выводы о людях. Решение «быть внимательнее» означает, что разбор не состоялся: внимательность не механизм защиты и в план работ не ставится.
Хронология: откуда брать отметки времени
Хронология — это половина ценности карточки, потому что именно по ней видно, где терялось время: сбой шёл девять часов, из которых восемь никто ничего не знал. Проблема в том, что подробных журналов у большинства систем в первый год нет, и восстанавливать порядок событий приходится из подручных источников. Их пять, и они почти всегда есть.
- 1Служебные отметки самой системы: время последнего успешного обмена, последнего созданного документа и последней записи в журнал. Даже при бедном журналировании эти три метки дают границы интервала.
- 2Переписка в рабочем чате. Сообщение «а почему остатки старые?» — это точное время обнаружения, а не приблизительное. Скриншоты и пересланные файлы в той же переписке датируют промежуточные шаги.
- 3Журнал обращений в поддержку и записи разговоров. Первое обращение клиента по теме сбоя — верхняя граница того, когда проблема стала видна наружу.
- 4Почта: автоматические письма об ошибках и уведомления смежных сервисов. Письмо пришло ночью, прочитали утром — такая пара отметок обычно оказывается самой полезной строкой всего разбора.
- 5Память участников — последней и только для связок между установленными точками: через две недели она даёт сдвиг в часы.
Три рабочих дня — не бюрократический срок, а срок годности деталей. На четвёртый день участники помнят сюжет, но не помнят порядок: что было раньше — перезапуск обмена или звонок подрядчику. Через неделю появляется уверенная реконструкция, в которой половина неверна. Если разбор откладывается, сохраните сырьё в тот же день — переписку, письма и служебные отметки, — а карточку напишите по нему позже.
Сколько стоит не разбирать
В модельном случае сбой повторился четырежды за полгода: 14 апреля, 27 мая, 9 июля и 21 августа. Каждый раз его чинили одинаково — удаляли старые журналы и перезапускали обмен, — и каждый раз это занимало у инженера около сорока минут. Причину устранили только после четвёртого эпизода, когда администратор случайно заметил совпадение в переписке.
Дорогая часть здесь не техническая. Сорок минут работы инженера — малая доля счёта; основные деньги дают перепроверка заказов и сорванные отгрузки. Эти строки растворяются в фонде оплаты труда и в скидках — ровно поэтому отсутствие разбора долго выглядит бесплатным.
Двухосевой график за шесть месяцев. По горизонтали — месяцы с апреля по сентябрь, четыре отметки инцидентов: 14 апреля, 27 мая, 9 июля, 21 августа. По вертикали — накопленный ущерб в рублях, ступенчатая линия растёт на 16 930 ₽ на каждой отметке и доходит до 67 720 ₽. Горизонтальная штриховая линия на уровне 17 250 ₽ подписана «разбор и устранение причины после первого случая». Область между линиями заштрихована и подписана «50 470 ₽». Чертёжный стиль, подписи по-русски.
Журнал инцидентов и квартальный обзор
Отдельная карточка чинит один сюжет. Настоящая польза появляется, когда карточек набирается два десятка и их читают подряд: видно, что половина сбоев за квартал имеет три-четыре общих корня, и чинить надо их, а не последний инцидент. Журнал — таблица со ссылками на карточки, живёт там же, где задачи.
| Повторяющаяся причина | По какому признаку узнаётся в карточках | Что её закрывает |
|---|---|---|
| Ресурс кончился: место на диске, квота, лимит запросов | Сбой ночью или в пик, чинится удалением и перезапуском | Ротация и сигнал с порогом за две недели до исчерпания |
| Истёк или сменился доступ: токен, ключ, сертификат, пароль | Обмен встал резко и целиком, накануне не меняли ничего | Реестр сроков и напоминание за 14, 3 и 1 день |
| Обновилась смежная система | Сбой начался сразу после планового окна или в понедельник | Регламент предупреждения и прогон обмена на копии |
| Данные пришли не в том формате | Ошибка на конкретном файле или контрагенте, остальное работает | Проверка формата на входе и очередь необработанного |
| Изменили настройку и не сказали | Никто не признаёт изменений, а поведение системы другое | Журнал изменений и регламент правок |
| Человек сделал шаг, которого нет в инструкции | Действие сотрудника в хронологии, в инструкции случая нет | Дописать инструкцию и по возможности запретить шаг технически |
Обзор занимает 30 минут раз в квартал и делается вместе с квартальным техосмотром системы. Порог, после которого причина уходит в план работ, фиксируется заранее: три инцидента с одним корнем за квартал либо один инцидент дороже 50 000 ₽. Остальное ждёт статистики — иначе план работ забивается случайностями.
За исполнением следит тот, кто ведёт журнал, — обычно администратор системы. Строка «что меняем» превращается в задачу с датой, и следующий обзор начинается со списка незакрытых задач. Если он не сокращается два квартала подряд, разбор стал ритуалом.
Между обзорами достаточно смотреть на четыре числа раз в неделю — это пять минут и делается вместе с обычной сводкой по системе.
- Открытых инцидентов на сегодня. Норма — ноль или один; больше означает, что предыдущий не закрыт, а забыт.
- Инцидентов за последние 30 дней. Рост вдвое к среднему за квартал — повод не ждать обзора.
- Незакрытых задач из карточек разбора со сроком в прошлом. Норма — ноль.
- Сбоев, о которых узнали от человека, а не от сигнала. Эта доля прямо показывает, чего не хватает в наблюдении.
Порог для звонка подрядчику вне графика тоже записывается заранее: два инцидента с одним корнем подряд либо любой инцидент, затронувший деньги клиентов. Остальное копится до планового разговора.
Когда разбор не нужен
Процедура стоит времени трёх человек, и навязывать её на каждый чих — верный способ убить её за два месяца. Есть три случая, когда карточку писать не надо.
- Причина внешняя и вам не подконтрольна: авария у провайдера, район без электричества. Пишется одна строка в журнал с датой и длительностью — она понадобится при разговоре о времени реакции и доступности, — но полноценный разбор не даёт ничего.
- Сбой длился минуты и никого не затронул. Ночная задача упала и перезапустилась сама, документы догнались, никто не заметил. Такое попадает в счётчик, а не в карточку; разбор нужен, если счётчик вырос.
- Система в первый месяц после запуска. Дефекты идут потоком, и это нормальная часть первого месяца эксплуатации. Разбор здесь заводят только на то, что затронуло клиентов или деньги.
И честная граница процедуры. Разбор не уменьшает число аварий — он уменьшает число повторных аварий, и только если строка «что меняем» превращается в сделанную работу. Компания, которая пишет карточки и не закрывает по ним задачи, тратит 8 250 ₽ на каждое совещание и получает архив описаний того, как у неё всё ломается.
Инцидент стоит денег один раз. Неразобранный инцидент стоит их столько раз, сколько повторится.
