ICAM (Incident Cause Analysis Method)

ICAM (Incident Cause Analysis Method) — метод разбора инцидентов. Ищет системные причины, а не останавливается на ошибке конкретного человека. По итогам разбора формулируют меры, чтобы инцидент не повторился.

Ключевой вопрос метода — не «кто виноват?», а «почему система это допустила?» ICAM применяется в авиации, на железной дороге, в горнодобыче и нефтегазе. Подходит и для ИТ-инцидентов: сбоев систем, киберинцидентов, отказов бизнес-процессов.

Не путать: ICAM также расшифровывается как Integrated Computer-Aided Manufacturing (оттуда — нотация IDEF0).

Зачем нужен

• выводит разбор за пределы «человеческой ошибки»: наказание исполнителя не предотвращает следующий инцидент, а изменение системы — предотвращает
• выявляет латентные условия — скрытые системные проблемы, существовавшие задолго до инцидента
• даёт корректирующие действия, которые меняют барьеры защиты и организационные условия, а не симптомы
• создаёт общий язык для подразделений: категории факторов понятны и ИТ, и операциям, и качеству

Когда применять

• серьёзные инциденты: существенный ущерб, повреждения, риск для людей или бизнеса
• повторяющиеся инциденты, когда предыдущие разборы «на глаз» не помогли
• ситуации, где простой анализ (например, «5 почему») вывел на системную проблему, которую надо разбирать глубже
• сложные инциденты, к которым причастны несколько подразделений

Когда НЕ стоит использовать

• мелкие инциденты без системных признаков — достаточно «5 почему»
• нет времени или обученных расследователей: полное ICAM-расследование занимает дни, а не часы
• организация не готова менять процессы по итогам разбора

Как работает

В основе метода — модель «швейцарского сыра»: защита системы состоит из нескольких слоёв-барьеров, и в каждом есть слабые места — «отверстия». Инцидент происходит, когда отверстия выстраиваются в одну линию и угроза проходит насквозь. Отсюда два типа причин:

• Активные отказы: действия и ошибки, непосредственно приведшие к событию
• Латентные условия: скрытые системные проблемы организации, которые существовали до инцидента

Причины разбираются по четырём группам факторов:

• Отсутствующие или несработавшие барьеры (Absent or Failed Defences): контроли, которые должны были предотвратить или смягчить инцидент, но не справились
• Действия людей и команд (Individual or Team Actions): что сделали или не сделали вовлечённые люди — включая ошибки и нарушения
• Условия задачи и рабочей среды (Task and Environmental Conditions): состояние оборудования, нехватка времени, нагрузка, факторы среды, сбои коммуникации
• Организационные факторы (Organisational Factors): управленческие решения, политика, культура, распределение ресурсов

Иногда выделяют пятую группу — человеческие факторы: усталость, стресс, ситуационную осведомлённость.

Как работает по шагам:

1. Немедленное реагирование: локализовать инцидент, защитить людей и окружающую среду
2. Сбор доказательств: физические, документальные и свидетельские — фото, документы, логи, интервью. Доказательства быстро теряют качество, поэтому сбор начинается в течение часов; сам анализ — после стабилизации сервиса
3. Хронология (таймлайн): восстановить последовательность событий и условий, в которых они происходили
4. Анализ барьеров: какие контроли должны были предотвратить инцидент, где они отказали или отсутствовали
5. Анализ действий и условий: что делали вовлечённые люди и в каких условиях — задачи, рабочая среда — они работали
6. Анализ организационных факторов: какие решения, политика и культура допустили такие условия
7. Рекомендации и отчёт: сформулировать корректирующие действия по принципу SMART — конкретные, измеримые, достижимые, релевантные, ограниченные по времени — и внести их в отчёт расследования

Команда расследования должна быть независимой: без надзорных функций и без заинтересованности в итогах разбора.

Пример

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

Разбор по ICAM выявил:

• Несработавший барьер: плановое обслуживание платформы было назначено внахлёст с критическими бизнес-операциями
• Действия людей: инженеры неверно интерпретировали инструкции по перезагрузке системы
• Латентные условия: реестр рисков устарел и не отражал ИТ-зависимости бизнес-процессов
• Организационные факторы: ИТ-отдел работал изолированно, интеграция с бизнес-операциями была слабой

Итог: перестроили планирование между отделами, усилили управление подрядчиками, руководителям внедрили дашборд, который в реальном времени показывает состояние ИТ-систем. Все выводы — про изменение системы, а не про поиск виноватых.

Плюсы и минусы

Плюсы:

• системный охват: видна полная цепочка — от действий исполнителя до организационных причин
• уход от поиска виновных снижает страх сообщать о проблемах
• универсальность: одна и та же рамка для производственных, ИТ и процессных инцидентов — отдельная «версия для ИТ» не нужна
• рекомендации в формате SMART доходят до внедрения, а не остаются декларацией

Минусы:

• ресурсоёмкость: полное расследование занимает дни и недели
• требует обученных расследователей — «само» не заработает
• качество выводов зависит от качества собранных данных; сбор информации не застрахован от предвзятости
• бесполезен в организациях, не готовых меняться по результатам разбора

Типичные ошибки

• остановиться на «человеческой ошибке» → разбор остаётся поверхностным, системные причины не устраняются, инцидент повторяется
• использовать результаты разбора для дисциплинарных мер (если только этого не требует закон) → сотрудники начинают замалчивать проблемы
• включать в команду расследования руководителей проверяемых процессов → конфликт интересов искажает выводы
• формулировать рекомендации без ответственных и сроков → задачи из разбора не выполняются
• начинать разбор до восстановления сервиса → в момент инцидента цель — восстановление, разбор идёт после

Сравнение ICAM с аналогами

Метод	Суть	Ограничение
«5 почему»	цепочка вопросов «почему?» — от симптома к первопричине	ведёт к одной причине, когда их обычно несколько
Диаграмма Исикавы	«рыбья кость»: проблема — в голове схемы, причины — на костях	инструмент группировки причин, а не метод расследования
Blameless-постмортем	разбор ИТ-инцидента после восстановления сервиса, без поиска виновных	не задаёт модели причин — какие причины искать, решает сама команда
ICAM	расследование по четырём группам: барьеры, действия, условия, организация	требует времени и обученных расследователей

«5 почему» удобно применять первым: для простых инцидентов этого достаточно, а если цепочка вывела на системную проблему — разбор продолжают по ICAM. Диаграмма Исикавы совместима с ICAM: на этапе поиска причин она помогает группировать факторы.

Что важно для аналитика

• в ИТ-контексте ICAM ложится на привычные практики — разборы инцидентов, постмортемы, управление проблемами по ITIL: метод подсказывает, какие факты искать и как разложить их по группам
• в разборе аналитик собирает факты, восстанавливает таймлайн и формулирует причинно-следственные связи
• причину формулируют в терминах системы: не «разработчик допустил ошибку», а «изменение у внешнего провайдера не отслеживалось, потому что не была настроена подписка на уведомления»
• типовые технические причины инцидентов — гонка событий, нарушение идемпотентности: их знание помогает быстрее выдвигать гипотезы
• Совет: спрашивать «какие факторы способствовали и при каких условиях», а не «что вызвало инцидент» — первый раскрывает систему факторов, второй сворачивает ответ в одно предложение

Подробнее про постмортемы в контексте SRE — тут.

Материалы

1. Метод ICAM (Incident Cause Analysis Method)
2. Контрольный список шаблона метода анализа причин инцидента (ICAM)
3. Модель швейцарского сыра
4. Blameless post-mortem: как разбирать инциденты так, чтобы они не повторялись
5. Постмортем без наказаний: культура разбора ошибок, которая реально улучшает качество проектов
6. Blameless 2.0. Как поделиться результатами Postmortem и получить максимум ценности
7. Инцидент-менеджмент с нуля: практический гайд для растущих команд
8. 5 инструментов для анализа первопричин (RCA), которые помогут вам улучшить тестирование и QA
9. RCA — расследования отказов на производстве
10. RCA для дата-инженеров
11. Управление проблемами в ITIL: руководство по процессам и реализации
12. Проведение ретроспективы инцидента без поиска виновных
13. What is ICAM? (en)
14. Incident Investigation & Management Methods: ICAM, 5 Whys, and Root Cause Analysis (en)
15. Work Health & Safety Incident Cause Analysis Method (ICAM) (en)
16. ICAM Incident Investigation: A Summary (en)
17. Beyond Safety: Expanding the Boundaries of ICAM Investigations (en)
18. The relationship between ICAM and 5 Whys (en)

Видео

1. Как провести разбор ошибок и ни с кем не поссориться / Константин Кафтан
2. Blameless culture. Как правильно работать с инцидентами / Андрей Синицин
3. Инцидент и постмортем — как не сплоховать в обоих случаях / Илья Вазем, DevOpsConf 2022
4. Как писать постмортем на реальном инциденте. Разбор инцидента
5. Процесс эффективного решения проблем (Root Cause Analysis) / Ирина Захарьина
6. Введение в бизнес-анализ. Техника «5 почему» / Лилия Данилкина

Конференции

1. SQA Days: Postmortem: учимся на собственных ошибках

Книги

1. Безопасные и надежные системы. Лучшие практики проектирования, внедрения и обслуживания как в Google — Хизер Адкинс, Бетси Бейер и др.