Анализ корневых причин (RCA): методы, инструменты, практика

Анализ корневых причин (Root Cause Analysis, RCA) — это структурированный метод поиска глубинных причин проблемы, а не её симптомов. Вместо «упал сервис → починили → поехали дальше» RCA заставляет ответить на вопрос «почему это вообще произошло и как сделать, чтобы не повторилось». Метод одинаково работает в IT-инцидентах, на производстве, в здравоохранении и в бизнес-процессах.

Главная идея RCA: событие — это симптом, причина лежит глубже. Если вы чините только симптом, проблема вернётся в другом месте. Правильный RCA превращает «пожарную команду» в «инженеров, которые чинят систему».

О чём эта статья

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

• Что такое RCA и зачем он нужен — отличие от «тушения пожаров», реальные кейсы экономии
• Метод 5 Почему — простейший инструмент, который работает в 50% случаев
• Диаграмма Исикавы (рыбья кость) — структурирование причин по категориям
• FMEA и FTA — продвинутые методы для критичных систем
• Как проводить RCA после IT-инцидента — пошаговый шаблон post-mortem
• Чек-лист внедрения RCA в команде или компании
• Типичные ошибки и как их избежать

Для кого статья: менеджеры проектов и процессов, тимлиды, DevOps/SRE-инженеры, инженеры по качеству, аналитики. Подойдёт всем, кто хочет перестать разгребать последствия и начать устранять причины.

Источники: методология основана на стандартах NASA (NASA Handbook for RCA), ISO 9001 (Quality Management), TOGAF (ADM), классической работе Сакаichi Toyoda (изобретатель метода 5 почему), плюс практиках IT-компаний (Google SRE Book, Etsy Debriefing Culture, Atlassian Incident Handbook).

Аналитика спроса: «метод 5 почему» — 1 749 показов/мес, «FMEA анализ» — 815, «root cause analysis» — 462, «анализ корневых причин» — 313.

Что такое RCA и зачем он нужен

Проблема, которую решает RCA: в организациях без системного анализа причины проблем люди борются с симптомами. Сервис упал — подняли. Дефект в продукте — починили. Клиент ушёл — нашли нового. Внешне всё хорошо, но проблемы повторяются, потому что корневая причина не устранена.

RCA — это метод, который:

1. Определяет, что произошло (анализ инцидента)
2. Определяет, почему это произошло (цепочка причин)
3. Определяет, что сделать, чтобы не повторилось (корректирующие действия)

Разница между тушением пожаров и RCA

Реальный кейс экономии

Производство полупроводников (по материалам публикаций):

• 1990-е: дефект партии микросхем, убытки $500K
• RCA выявил: причиной была микроконцентрация примеси в кремнии
• Системное изменение: новый метод контроля сырья на входе
• Экономия за 5 лет: $50M+ на предотвращённых дефектах

IT-инцидент (Google SRE Book, кейс YouTube):

• Падение CDN на 30 минут в 2010 году
• RCA выявил: единственная точка отказа в системе кеширования
• Системное изменение: репликация всех кешей, автоматический failover
• За 10 лет подобные инциденты больше не повторялись в том же масштабе

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

Когда RCA НЕ нужен

• Проблема уже решена системно и не повторяется
• Причина полностью очевидна без анализа (опечатка в коде, забыли нажать кнопку)
• Затраты на RCA превышают потенциальные потери

Метод 5 Почему: простейший и эффективный

Метод 5 Почему (5 Whys) изобретён в Toyota Production System Сакаичи Тоёда в 1930-х. Идея: задать вопрос «почему» пять раз подряд, чтобы докопаться до системной причины.

Как работает

Каждый следующий вопрос «почему» копает глубже, пока не дойдёт до корня:

Проблема: Клиент получил повреждённый товар
Почему?    Товар был плохо упакован
Почему?    Упаковщик использовал неподходящую плёнку
Почему?    Плёнка была не той, что указана в спецификации
Почему?    На складе перепутали артикулы плёнки
Почему?    Склад хранит несколько типов плёнки без маркировки
   ROOT: Нет системы маркировки и контроля материалов на складе

Правила метода:

1. Каждый ответ должен быть фактом, а не догадкой. Если не знаете — ищите данные.
2. Не останавливаться на людях. «Оператор ошибся» — это не root cause. Ищите, почему система позволила оператору ошибиться.
3. Количество «почему» не обязательно 5. Иногда хватает 3, иногда нужно 8. Главное — дойти до системной причины.
4. Избегать «потому что так исторически сложилось». Это не root cause, а сигнал копать дальше.

Пример: IT-инцидент

Инцидент: Сайт был недоступен 2 часа
Почему?    Сервер БД перестал отвечать
Почему?    Дисковое пространство закончилось
Почему?    Логи не ротировались и заняли весь диск
Почему?    Скрипт ротации логов был написан, но не запускался по cron
Почему?    Cron на сервере был выключен при миграции полгода назад
   ROOT: Нет процесса валидации работоспособности cron после миграций

Системное решение: добавить автоматические проверки состояния cron в pipeline миграций, мониторинг свободного места на диске с алертом при >80%.

Когда 5 Почему не работает

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

Диаграмма Исикавы (рыбья кость)

Диаграмма Исикавы (автор — Каору Исикава, 1968) структурирует причины по категориям. Визуально напоминает скелет рыбы: голова — проблема, кости — категории причин, мелкие кости — конкретные причины.

Классификация 6M

Стандартные категории причин (метод 6M):

Пример для IT-инцидента

Проблема: Production-база перегружена в пиковые часы.

Как строить диаграмму Исикавы

1. Сформулируйте проблему чётко: «что произошло», «когда», «какой эффект».
2. Нарисуйте «хребет» — горизонтальную стрелку с проблемой в «голове».
3. Добавьте основные категории причин (кости первого уровня) — 4–6 категорий.
4. Мозговой штурм по каждой категории — что могло вызвать проблему.
5. Голосование — выберите наиболее вероятные причины для дальнейшего анализа.
6. Проверьте гипотезы — данные, метрики, логи.

Инструменты: Mermaid (для markdown), Miro, draw.io, Figma.

Подробнее о диаграмме Исикавы — в статье «Исикава: диаграмма рыбьей кости».

FMEA: анализ видов и последствий отказов

FMEA (Failure Mode and Effects Analysis) — систематический метод выявления потенциальных отказов до того, как они произойдут. Используется в аэрокосмической отрасли с 1960-х, сейчас стандарт в automotive (IATF 16949), медицине, IT-инфраструктуре.

Структура FMEA

Пример FMEA для IT-системы

Приоритеты: RPN > 100 — обязательные действия; 50–100 — желательные; <50 — приемлемый риск.

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

• Разработка нового продукта/системы (до запуска)
• Критичные изменения в существующей системе
• Анализ после серьёзного инцидента
• Регулярный аудит (раз в квартал/год)

Преимущества: количественная оценка рисков, возможность сравнивать альтернативы, документирование для compliance.

Недостатки: трудоёмкость (для сложной системы — десятки часов), субъективность оценок, требует экспертизы команды.

FTA: дерево отказов

FTA (Fault Tree Analysis) — метод, при котором строится логическое дерево отказов от корневой проблемы вниз к базовым причинам. Использует булеву логику (AND, OR) для комбинации событий.

Пример FTA для IT-инцидента

НЕДОСТУПНОСТЬ СЕРВИСА (TOP)
├── OR
│   ├── СБОЙ БАЗЫ ДАННЫХ
│   │   ├── OR
│   │   │   ├── Диск переполнен
│   │   │   │   └── AND
│   │   │   │       ├── Логи не ротируются
│   │   │   │       └── Мониторинг диска не настроен
│   │   │   └── Мастер БД упал
│   │   │       ├── OR
│   │   │       ├── Аппаратный сбой
│   │   │       └── Программный сбой
│   │   └── Реплики рассинхронизированы
│   └── СБОЙ СЕТИ
│       ├── OR
│       ├── Проблемы у провайдера
│       └── DDoS-атака

Где использовать: анализ критичных систем (авиация, АЭС, банкинг), сертификация по стандартам безопасности, сложные инциденты с множеством возможных причин.

RCA для IT-инцидентов: шаблон post-mortem

Лучшие IT-компании (Google, Atlassian, Etsy) сделали post-mortem частью культуры. Хороший post-mortem не обвиняет людей — он ищет системные причины и предотвращает повторение.

Шаблон post-mortem

# Post-Mortem: [Краткое описание инцидента]

**Дата:** YYYY-MM-DD
**Длительность:** HH:MM
**Severity:** SEV-1 / SEV-2 / SEV-3
**Автор:** [Имя]
**Статус:** Draft / In Review / Final

## TL;DR
Что произошло, как исправили, какой ущерб.

## Влияние (Impact)
- Кто пострадал: N пользователей / N% сервиса
- Финансовый ущерб: $X / Y часов простоя
- Репутационный ущерб: [описание]

## Timeline (UTC)
- HH:MM — Что-то пошло не так
- HH:MM — Алертинг сработал / Кто-то заметил
- HH:MM — Команда начала разбор
- HH:MM — Идентифицирована причина
- HH:MM — Применён fix
- HH:MM — Сервис восстановлен
- HH:MM — Мониторинг подтвердил стабильность

## Root Cause
Что было корневой причиной (один абзац).

## Contributing Factors
Что усугубило ситуацию (2-3 пункта).

## What Went Well
Что сработало хорошо в процессе реагирования.

## What Went Wrong
Что не сработало или замедлило восстановление.

## Action Items
| Действие | Ответственный | Дедлайн | Тип |
|----------|---------------|---------|-----|
| Добавить алерт на X | @user | YYYY-MM-DD | Предотвращение |
| Документировать процедуру | @user | YYYY-MM-DD | Detection |
| Провести симуляцию инцидента | @user | YYYY-MM-DD | Улучшение процесса |

## Lessons Learned
Чему научились как команда.

Принципы blameless post-mortem

Главное правило: обвинять систему, а не людей.

Почему: если виноват «Вася, который забыл нажать кнопку» — Вася научится скрывать ошибки. Если виновата «система, которая позволяла Васе ошибиться» — мы можем её улучшить.

Классический пример из авиации: после авиакатастрофы никогда не пишут «пилот был невнимателен». Пишут «система предупреждения была недостаточно громкой, кнопка подтверждения была неудачно расположена, инструкция не покрывала этот случай».

В IT это значит:

• ❌ «Иван сделал неправильный merge»
• ✅ «Code review не поймал проблему, потому что нет обязательного чек-листа для изменений в БД»

Чек-лист внедрения RCA в команде

Этап 1. Подготовка (1–2 недели)

• Определить владельца процесса RCA в команде
• Выбрать шаблон post-mortem (наш или адаптировать)
• Создать доску для отслеживания action items
• Согласовать критерии инцидентов, требующих RCA
• Провести обучение команды методам (5 почему, Исикава, FMEA)

Этап 2. Пилот (1–2 месяца)

• Применять RCA к 3–5 последним инцидентам
• Собирать обратную связь — что работает, что мешает
• Корректировать шаблон и процесс
• Отслеживать метрики: повторяемость инцидентов, время на RCA, % закрытых action items

Этап 3. Закрепление (2–3 месяца)

• Сделать RCA обязательным для инцидентов уровня SEV-1 и SEV-2
• Включить обзор action items в ретроспективы команды
• Публиковать post-mortem для всей компании (transparency)
• Связать с процессом управления рисками (см. «Управление рисками»)

Этап 4. Масштабирование (3–6 месяцев)

• Кросс-командный обмен post-mortem
• База знаний по типовым инцидентам и решениям
• Регулярный FMEA-аудит критичных систем (раз в квартал)
• Интеграция с системой управления инцидентами (PagerDuty, Opsgenie)

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

1. Останавливаться на первом «почему»

Инцидент: Сайт упал
Почему? Сервер перегружен
ROOT CAUSE: Сервер перегружен

Это не RCA, это пересказ симптома. Настоящий root cause — «почему сервер оказался перегружен» и далее по цепочке.

2. Обвинять людей

ROOT CAUSE: DevOps-инженер не настроил мониторинг

Это перекладывание ответственности. Правильная формулировка: «Нет процесса обязательной настройки мониторинга при создании новых сервисов».

3. Забыть про action items

RCA без действий — пустая трата времени. Хороший пост-мортем заканчивается конкретными задачами с ответственными и дедлайнами.

4. Слишком долго копать

RCA на 3 месяца для инцидента с ущербом $1K — overkill. Определите порог: для мелких инцидентов достаточно 5 почему за 1 час, для критичных — полноценный анализ.

5. Не закрывать action items

Action item «добавить мониторинг» висит в Jira 6 месяцев. Решение: ревью action items в каждой ретроспективе команды, эскалация просроченных.

6. Игнорировать near-misses

«Мы чуть не упали, но обошлось» — это подарок. RCA потаких случаев даёт больше, чем после реального падения. Введите категорию SEV-0 для near-misses.

Инструменты для RCA

Ресурсы для углублённого изучения

Книги:

• «Toyota Production System» Тайити Оно — первоисточник метода 5 почему
• «Antifragile» Нассим Талеб — о системном мышлении и устойчивости
• «The Field Guide to Understanding 'Human Error'» Сидни Деккер — о природе ошибок
• «Site Reliability Engineering» (Google) — полный гайд по post-mortem для IT
• «Effective DevOps» Дженнифер Дэвис, Кэтрин Дэниелс — про культуру без обвинений

Стандарты и фреймворки:

• NASA Root Cause Analysis Handbook — методология для критичных систем
• ISO 9001:2015 — требования к управлению качеством (включает RCA)
• ITIL 4 — практики управления инцидентами и проблемами
• TOGAF ADM — методология архитектуры предприятия (управление рисками)

Онлайн-ресурсы:

• Etsy Debriefing Culture — открытые post-mortem Etsy, можно изучать
• Google SRE Book (бесплатно онлайн) — культура и практика RCA
• Atlassian Incident Handbook — шаблоны и процессы для IT-инцидентов

Заключение

Анализ корневых причин — это не бюрократия, а инвестиция. Каждый час, потраченный на правильный RCA, экономит десятки часов на будущих инцидентах. Но главное — меняет культуру: с «тушения пожаров» на «улучшение системы».

Принципы эффективного RCA:

1. Ищите систему, а не виноватого. Люди ошибаются — системы должны это предотвращать.
2. Каждый ответ на «почему» — факт, а не догадка. Данные, логи, метрики.
3. Action items с дедлайнами и владельцами. RCA без действий — ритуал.
4. Blameless culture. Иначе люди скрывают ошибки, и вы теряете информацию.
5. Не только после падений. Near-misses дают больше, чем реальные инциденты.
6. Документируйте. Через год вы забудете, а база знаний поможет.
7. Связывайте с риск-менеджментом. RCA инцидента — это input для управления рисками.

С чего начать прямо сейчас:

• Выберите последний инцидент (даже мелкий) в вашей команде
• Примените метод 5 почему — 30 минут
• Запишите 1–2 системных действия
• Через месяц проверьте: повторилась ли проблема?

Что дальше

Связанные статьи на сайте:

• Исикава: диаграмма рыбьей кости — детальный разбор метода Исикавы с примерами
• 5 почему — подробнее о методе 5 почему
• Управление рисками — как связать RCA с общим риск-менеджментом
• Антикризисное управление — что делать, когда инцидент уже происходит
• Проблем-солвинг: методы решения проблем — общий обзор подходов
• Анализ требований к системе — как предотвращать проблемы на этапе требований
• System Design: проектирование систем — проектирование с учётом надёжности
• Системное мышление — фундаментальный подход к сложным проблемам