Что такое Root Cause Analysis (RCA): анализ корневых причин и методы их поиска

Что такое RCA и как расшифровывается аббревиатура

RCA расшифровывается как Root Cause Analysis — дословно «анализ корневой причины». На русском используют несколько равнозначных переводов: анализ корневых причин, анализ коренных причин, анализ первопричин. Все варианты обозначают один подход.

Важно разграничить два понятия, которые часто путают. Первопричина — непосредственный источник сбоя: сломался насос, упала база данных. Коренная причина залегает глубже — это системный сбой, породивший первопричину: отсутствие регламента технического обслуживания, ошибка конфигурации при деплое. RCA нацелен именно на коренную причину. Устранение симптома без анализа причинно-следственной цепочки — принципиально иной подход: он даёт быстрый результат здесь и сейчас, но не защищает от повторения.

Зачем нужен анализ корневых причин: польза и ценность

Организации, внедряющие структурированный RCA, получают пять ключевых выгод:

• снижение операционных расходов — повторные инциденты дорого обходятся: простой оборудования, аварийные ремонты, нарушения соглашения об уровне обслуживания (SLA). Устранение коренной причины обрывает этот цикл;
• рост надёжности — процессы и системы становятся предсказуемыми, критичные сбои случаются реже;
• накопление базы знаний — каждый завершённый RCA пополняет внутреннюю базу: следующий специалист тратит на диагностику похожего инцидента в разы меньше времени;
• переход к проактивной модели — анализ прошлых инцидентов помогает предупреждать будущие, а не только реагировать на уже случившиеся;
• рост удовлетворённости пользователей — стабильная работа систем напрямую влияет на доверие клиентов и внутренних заказчиков.

RCA производит корректирующие мероприятия и базу знаний, которые работают в долгую, а не ситуативно.

Пять ключевых принципов RCA

Анализ корневых причин строится на пяти принципах, которые отличают его от поверхностного разбора инцидентов.

1. Фокус на системах, а не на людях. Если «виновником» признаётся конкретный сотрудник — анализ не добрался до корня проблемы. Люди ошибаются в условиях, которые создают системы.
2. Объективность и фактическая база. Выводы строятся на данных — логах, метриках, хронологии событий — а не на предположениях.
3. Системность. Все факторы рассматриваются в совокупности, а не изолированно.
4. Многоуровневость. Цепочка «почему» прослеживается до фундаментального уровня без остановки на промежуточных звеньях.
5. Предотвращение повторения. Цель — не объяснить случившееся, а сделать так, чтобы оно не повторилось.

Отдельного внимания заслуживает принцип безвиновного анализа (blameless postmortem) — особенно популярный в DevOps-командах. Суть: если расследование заканчивается выводом «виноват оператор», значит, анализ нужно продолжить. Почему система позволила оператору совершить эту ошибку? Такой подход формирует культуру открытости: сотрудники честно сообщают об инцидентах и делятся полной картиной событий без страха наказания.

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

Этапы проведения анализа корневых причин: пошаговый алгоритм

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

Шаг 1. Определение проблемы. Применяется формула 6W: Что? Когда? Где? Почему важно? Кто затронут? Как много? Расплывчатая формулировка «сервер иногда тормозит» превращается в конкретную: «Служба авторизации недоступна каждые два вторника с 03:15 до 03:47 по московскому времени, влияет на 1 200 пользователей». Точное определение задаёт границы расследования.

Шаг 2. Сбор данных. Данные собираются на месте происшествия — в производственной практике это называется «гемба». Для ИТ-инцидентов — системные логи, метрики производительности, трассировки запросов, хронология событий.

Шаг 3. Анализ причин. Применяются инструменты RCA — метод «5 почему», диаграмма Исикавы, анализ дерева отказов. Цель — выстроить полную причинно-следственную цепочку от симптома до коренной причины.

Шаг 4. Разработка корректирующих мероприятий. Каждое мероприятие получает конкретные сроки и ответственного. Абстрактное «улучшить процесс» — не мероприятие. «Обновить регламент резервного копирования до 30 октября, ответственный — А. Петров» — мероприятие.

Шаг 5. Контроль эффективности. Если проблема повторилась — значит, в шаге 3 коренная причина не была найдена или решение оказалось недостаточным. Результаты фиксируются в базе знаний и замыкают цикл расследования отказов.

Инструменты и методы RCA: сравнительный обзор

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

Метод «5 почему» (5 Why) — быстрый универсальный инструмент

Метод разработал Сакити Тоёда в рамках производственной системы Toyota. Принцип прост: задавайте «Почему?» последовательно, пока не дойдёте до коренной причины. Стандарт — пять итераций, реально — от трёх до семи.

Пример из ИТ — цепочка причинно-следственных связей:

1. Служба не запустилась → файл конфигурации не загрузился.
2. Файл не загрузился → путь изменился при обновлении пакета.
3. Это не заметили → обновление не тестировалось в тестовой среде.
4. Тестовая среда не синхронизирована → нет единого управления конфигурацией.
5. Нет управления → отсутствует регламент проверки конфигурации перед обновлением ← первопричина.

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

Диаграмма Исикавы (рыбья кость) — для командного многофакторного анализа

Инструмент создан профессором Каору Исикавой в 1968 году. Визуально диаграмма напоминает рыбий скелет: в «голове» — проблема, от центральной оси отходят ветви шести категорий — метод 6M: Man (люди), Machine (оборудование), Method (методы), Material (материалы), Measurement (измерения), Mother Nature (внешняя среда).

Для ИТ-домена 6M адаптируется в три категории: People (люди и компетенции), Process (процессы и регламенты), Technology (инфраструктура). Диаграмма особенно эффективна при командном анализе инцидентов с несколькими возможными источниками: структура не даёт пропустить ни одно направление. Здесь выигрывает многофункциональная команда — каждый участник заполняет «свою» ветвь.

FTA, FMEA и диаграмма Парето

Анализ дерева отказов (FTA) — дедуктивный метод: от нежелательного события строится логическое дерево с операторами И/ИЛИ для всех сочетаний причин. Применяется там, где цена ошибки максимальна: авиация, атомная энергетика, высоконагруженные ИТ-платформы.

FMEA (анализ видов и последствий отказов) — превентивный инструмент, работает до возникновения сбоя. Для каждого потенциального отказа рассчитывается приоритетное число риска: ПЧР = серьёзность × вероятность × обнаружение. По временно́й логике FMEA — противоположность RCA: один проектирует защиту заранее, другой расследует уже случившееся. На практике методы дополняют друг друга.

Диаграмма Парето применяет принцип 80/20: помогает определить, какие 20% причин порождают 80% инцидентов, и направить ресурсы именно туда — это инструмент приоритизации источников времени простоя.

Когда применять RCA: триггеры и критерии отбора

Анализ корневых причин запускают при наступлении шести типов событий:

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

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

Типичные ошибки при проведении RCA и как их избежать

Даже правильно запущенный анализ корневых причин может дать слабые результаты из-за четырёх распространённых ошибок.

Остановка на симптоме. Команда устраняет непосредственный сбой и считает задачу закрытой. Решение: контрольный вопрос перед закрытием — «Это коренная причина или следствие чего-то более глубокого?»

Поиск виноватого вместо системной причины. Если итог RCA звучит как «виноват сотрудник X» — анализ не завершён. Принцип безвиновного анализа требует копать глубже: почему система позволила этой ошибке случиться?

Анализ на предположениях, а не на данных. Повторяющиеся дефекты часто объясняют «экспертным суждением», минуя шаг сбора фактических данных. Результат — неверная гипотеза и нерабочее решение.

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

Где применяется анализ корневых причин: ИТ, производство и Lean

Анализ коренных причин востребован в любой сфере, где важна надёжность процессов: производство и техническое обслуживание, ИТ-инфраструктура и ITSM, управление надёжностью, Бережливое производство и Six Sigma, DevOps, логистика, управление качеством и промышленная безопасность.

RCA в ИТ-инфраструктуре и ITSM

В библиотеке практик управления ИТ-услугами ITIL анализ корневых причин — центральный элемент управления проблемами. Два смежных процесса разграничены чётко: управление инцидентами восстанавливает сервис максимально быстро (нередко через временное решение-обход), тогда как управление проблемами через RCA ищет и устраняет первопричину, чтобы инцидент не повторился.

Результаты RCA в ИТ интегрируются в управление изменениями (корректирующее действие → задача → бэклог → деплой → мониторинг), базу знаний и планы аварийного восстановления.

RCA в Бережливом производстве и Six Sigma

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

В Six Sigma RCA встроен в фазу Analyze цикла DMAIC (Define → Measure → Analyze → Improve → Control). В системе всеобщего обслуживания оборудования (TPM) применение RCA переводит стратегию технического обслуживания от реактивной к превентивной: вместо ремонта по факту поломки — устранение источников потенциальных отказов до их возникновения.

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

Чем RCA отличается от FMEA?

RCA применяется реактивно — после инцидента — для поиска первопричины. FMEA (анализ видов и последствий отказов) — превентивный инструмент: оценивает потенциальные отказы до их возникновения. Для каждого сбоя FMEA рассчитывает ПЧР = серьёзность × вероятность × обнаружение. На практике методы дополняют друг друга: FMEA проектирует защиту заранее, RCA расследует случившееся.

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

Первопричина — непосредственный источник проблемы: «поломка маслонасоса». Корневая причина — более глубокий системный сбой, устранение которого предотвращает повторение: «отсутствие регламента по замене масла». Суть RCA — добраться до корневой причины, а не остановиться на первопричине, которая является лишь следствием системной проблемы.

Сколько раз нужно задавать «почему» в методе 5 Why?

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

Когда НЕ нужно проводить RCA?

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

Как RCA связан с ITIL и управлением проблемами?

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

Что такое безвиновный анализ (blameless postmortem)?

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

Можно ли автоматизировать RCA?

Да. В микросервисных и контейнеризированных средах инструменты класса систем искусственного интеллекта для ИТ-операций (AIOps) применяют машинное обучение для корреляционного анализа логов, метрик и трассировок — автоматически выявляя аномалии и потенциальные корневые причины. Автоматизированный RCA сокращает время диагностики с часов до минут, однако интерпретация результатов и разработка корректирующих мер по-прежнему требуют участия специалиста.

В каких отраслях применяется анализ коренных причин?

RCA востребован там, где важна надёжность процессов: производство (дефекты, простои), ИТ-инфраструктура и управление ИТ-сервисами (инциденты, нарушения SLA), техническое обслуживание (отказы оборудования), логистика (задержки в цепи поставок), управление качеством (несоответствия и рекламации), промышленная безопасность. В Бережливом производстве и Six Sigma RCA встроен в цикл непрерывного улучшения DMAIC.