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

Что это значит на практике

Анализ корневых причин, по-английски root cause analysis, сокращённо RCA, — это поиск ответа на вопрос «из-за чего это случилось». Что сломалось и как починили, известно и без него. Искать надо то, что запустило цепочку событий. Причина считается найденной, когда её можно показать и когда после исправления сбой больше не повторяется. Методы RCA у всех одни и те же: пять «почему», диаграмма Исикавы, дерево отказов. Результат зависит от другого: что известно о системе до начала анализа. В эксперименте Grafana Labs 2026 года одна и та же программа находила причину в 15 случаях из 16, когда у неё была карта связей между частями системы, и в 1 случае из 16 без неё.

Короткий ответ

RCA отвечает на один вопрос: из-за чего это случилось. Что сломалось и как починили, известно и без анализа. Искать надо событие, которое запустило цепочку, в конце которой оказался сбой. По-русски ту же работу называют анализом первопричин и анализом коренных причин. Слова разные, суть одна: выявление истинной причины, а не симптома.

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

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

Ещё одно предупреждение, оно из ITIL 4, самого известного свода правил по управлению ИТ. В сложных системах единственной причины часто нет. Отказ рождается из сочетания нескольких маловероятных факторов. Поэтому останавливаться на первом найденном звене нельзя: надо смотреть глубже, пока не станут видны все связанные факторы.

Где RCA стоит в работе ИТ: проблема и известная ошибка

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

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

ITIL 4 делит процесс на три этапа: выявить проблему, разобрать её и взять под контроль известную ошибку. Поиск корневой причины — это второй этап процесса. Российский стандарт ГОСТ Р ИСО/МЭК 20000-1—2021 в пункте 8.6.3 требует того же: разбирать данные об инцидентах, находить проблемы, проводить анализ корневых причин (в тексте стандарта — «коренных») и не давать инцидентам повторяться.

За пределами ИТ та же работа есть в управлении качеством. ГОСТ Р ИСО 9001-2015 в пункте 10.2 требует при каждом несоответствии решить, надо ли устранять его причину, и называет это корректирующим действием. Оттуда, из качества, надёжности и бережливого производства, пришло и большинство методов RCA.

Симптом, следствие и причина: цепочка на живом примере

Разницу между причиной и следствием проще всего показать на настоящем случае. Он взят из статьи Grafana Labs от 19 августа 2026 года. Grafana делает системы наблюдения за серверами, и статья описывает её собственный сбой и эксперимент на нём. Все числа об этом эксперименте на нашей странице взяты оттуда.

Сначала три слова, без которых пример не понять. Лог — это журнал, куда программы записывают всё, что с ними происходит, строка за строкой. Индекс — это оглавление к логу, по нему поиск находит нужную строку быстро. JSON — текстовый формат, в котором программы передают друг другу данные, длинные записи с фигурными скобками.

Теперь сам случай. Один из клиентов Grafana стал записывать в поле, по которому строится индекс, целые куски JSON. Для каждого нового значения индекс заводит отдельную запись, а два куска JSON почти никогда не совпадают. Поэтому почти каждая строка лога добавляла в индекс новую запись. Число разных значений в этом поле выросло с примерно 2 700 до 86 000 с лишним в день.

Индекс перестал помещаться в память. Серверы, которые его держат, упирались в предел 8 ГБ, и система их останавливала. Они запускались снова, память снова заполнялась, и так примерно каждые 48 минут. Поиск замедлился. Программы, которые выполняют поиск, встали в очередь. Пользователи увидели, что поиск тормозит. Именно на этом сработало оповещение: по счёту авторов, в трёх шагах от причины.

Теперь ловушка. Тот же раздутый индекс сделал запросы самого клиента медленными и тяжёлыми. В момент оповещения этот шторм запросов был самым заметным сигналом во всех показателях. Это тоже следствие, второе, но выглядело оно ровно как причина: тяжёлые запросы, занятые программы, медленный поиск. Программа-агент, о которой речь ниже, без карты связей в 10 случаях из 16 назвала причиной именно шторм запросов и решила, что чинить нечего, система восстановится сама. На деле чинить надо было другое: перестать индексировать это поле.

Цепочка получилась такая: изменили содержимое поля, индекс вырос, память кончилась, серверы стали перезапускаться, поиск замедлился, сработало оповещение. Симптом в конце, причина в начале, а самое заметное событие в стороне, на боковой ветке. Задача RCA — не остановиться на самом заметном, а дойти до первопричины.

На рисунке одна причина и две цепочки следствий. Громкое следствие стоит в одном шаге от причины, оповещение — в трёх. Тот, кто начинает искать от оповещения, видит громкую цепочку и принимает её за причину. Схему мы перерисовали по единственному рисунку из статьи Grafana Labs, само изображение владельца не воспроизводим.

Как проходит анализ: шесть шагов

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

• Собрать факты. Что и когда менялось, что показывали наблюдение и логи, какие жалобы пришли и в каком порядке. Первый рабочий документ — хронология с точным временем каждого события, а не «примерно вечером». Проблему заводят в журнал сразу, иначе факты разойдутся по переписке.
• Отделить жалобы от фактов. «Поиск тормозит» — это жалоба, то есть симптом. «Сервер перезапускается каждые 48 минут» — это факт, у него есть время и место.
• Построить цепочку от отказа назад. На каждом шаге спрашивать, из-за чего произошло это событие, пока не найдётся то, что можно изменить.
• Проверить версию. Первопричина считается найденной, когда отказ удалось воспроизвести или когда после исправления он перестал повторяться. Пока есть только правдоподобное объяснение, это версия, а не ответ.
• Записать. Причина, обходное решение, если оно есть, и признаки, по которым такую проблему узнают, попадают в запись проблемы. С этого момента она становится известной ошибкой.
• Устранить и убедиться. Исправление проводят через управление изменениями, а не правкой на сервере посреди ночи. Тот же ГОСТ Р ИСО/МЭК 20000-1—2021 в пункте 8.6.3 прямо этого требует. После исправления смотрят, прекратились ли отказы этого типа.

Последний шаг пропускают чаще других: причина названа, отчёт написан, а изменение так и не сделано. Поэтому в процессе управления проблемами проблему держат открытой до устранения, а не до объяснения.

Методы RCA: пять «почему», рыбья кость и остальные

Метод RCA — это способ задавать вопросы в нужном порядке. У каждого метода есть преимущества и границы. Он помогает думать, но не заменяет данные: диаграмма, нарисованная без хронологии, красиво показывает догадки. Методов существует множество, ниже шесть наиболее ходовых и границы каждого. ITIL 4 из них прямо называет пять «почему» и дерево отказов.

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

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

Дерево отказов. Сверху нежелательное событие, под ним условия, при которых оно наступает, соединённые словами «и» и «или». Метод пришёл из анализа надёжности сложных систем. В ИТ он полезен, когда отказ случается только при совпадении нескольких условий.

Анализ видов и последствий отказов (FMEA). Это метод не расследования, а предупреждения: с его помощью для каждого компонента системы заранее перечисляют, как он может отказать и чем это обернётся. В RCA его берут, когда цепочка уже построена и надо понять, какие ещё дефекты того же рода ждут своего часа в продукте и как их избежать.

Анализ Парето. Инциденты группируют по причинам и считают, какие немногие проблемы дают большую часть отказов. Это способ решить, какую проблему разбирать первой, а не поиск причины одного случая, и основной метод планирования работы группы анализа.

Анализ изменений. Сравнивают, что менялось в системе перед отказом: обновления, настройки, данные, нагрузка. В ИТ с этого разумно начинать: у изменения есть автор, время и содержание, то есть это уже готовое звено цепочки. Случай с индексом — ровно такой: клиент изменил содержимое поля.

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

Что нужно знать о системе до начала: эксперимент Grafana

Методы у всех одни, а результаты разные. Разница в том, что известно о системе, когда анализ начинается. Таких входов четыре.

• Карта связей: из каких частей состоит услуга и что от чего зависит. Без неё неясно, относятся ли перезапуски сервера и медленный поиск к одной услуге или к разным. В ИТ такую карту ведут в базе конфигураций, её называют CMDB.
• Журнал изменений: что, когда и кто менял; для анализа изменений это основной источник информации.
• История: прошлые инциденты, открытые проблемы и известные ошибки, то есть что уже случалось и чем кончилось.
• Телеметрия: показатели, логи и трассировки, которые собирает система наблюдения и к которым можно обращаться по ходу анализа.

Что из этого важнее, долго было делом веры. Grafana Labs измерила это хотя бы для первого входа. Проблему с индексом превратили в эксперимент по RCA. Поиск причины поручили агенту, то есть программе на языковой модели, которая сама запрашивает данные и делает выводы. Модель — Claude Opus 4.8 в режиме усиленного рассуждения. Агенту давали оповещение и доступ к телеметрии рабочей системы. В половине запусков он получал ещё и карту связей: Grafana называет её графом знаний, в нём автоматически собраны сервисы, серверы и базы данных, связи между ними и состояние каждого узла с обновлением раз в минуту. Верный ответ записали до запуска, ответы агента оценивали две другие модели, не зная, была ли у него карта. По 16 запусков на каждый вариант.

С картой агент нашёл верную причину в 15 запусках из 16. Без карты — в 1 из 16. Такой разрыв случайным не бывает: авторы оценили вероятность случайности ниже одной десятитысячной. Запросов к данным с картой понадобилось вдвое меньше, в типичном запуске 10 против 19, при тех же затратах.

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

Во второй проблеме из того же эксперимента причины на карте не было. В глубине системы замедлился внутренний сервис. Сервис перед ним забился ожидающими запросами, и система остановила его из-за нехватки памяти. Оповещение сработало на нём, на шаг выше настоящей причины. Ответ давала одна строка лога с именем медленного сервиса, а строк логов на карте нет.

Здесь карта ничего не изменила: с ней агент нашёл причину в 8 запусках из 16, без неё в 7 из 16. Авторы этого и ждали. Боялись они другого: что карта подтолкнёт агента к неверной версии и верных ответов станет меньше. Этого не случилось. Запуски, в которых агент ошибся, пропустили ту же строку лога, что с картой, что без неё.

На рисунке оба случая: по шестнадцать запусков с картой связей и без неё, закрашено столько клеток, сколько раз агент нашёл причину. В первом случае карта решает исход, во втором ничего не меняет. Числа из двух таблиц статьи Grafana Labs, рисунок наш.

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

Автоматический RCA и три его провала

Часть систем управления ИТ-услугами обещает проводить RCA без участия специалистов, с пометкой «ИИ» в описании. Прежде чем встраивать такую систему в свой процесс, необходимо знать, на чём она спотыкается. Grafana Labs, наблюдая за тем, как языковые модели проводят RCA на её собственных серверах, назвала три провала.

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

Модель скорее выдумает, чем признается, что не знает. Автор эксперимента описывает свою ошибку. Один запуск ушёл вообще без доступа к данным: агенту нечем было заглянуть в показатели и логи. Агент всё равно провёл анализ и выдал уверенный, хорошо оформленный отчёт о причине. Он написал, что запросит показатели и логи, а дальше сочинил и сами запросы, и их результаты. Таблицу показателей заполнил числами, которых никогда не видел. Это один случайный запуск на старой модели, авторы так и пишут. Но для дежурной смены уверенная выдумка хуже молчания: на неё потратят время.

Один и тот же вопрос, разные ответы. Проблему с индексом запускали 16 раз с одинаковой постановкой. Ответы разошлись по четырём ступеням оценки, от верного до уверенно неверного. Число запросов к данным колебалось от 13 до 31, стоимость запуска от 0,56 до 1,26 доллара. Авторы сравнивают это с дежурным, который блестящ, но приходит, когда захочет.

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

На рисунке три провала, которые Grafana Labs увидела у агента, и ответ практики на каждый. Провалы описаны в статье, ответы наши.

Есть и хорошая новость про затраты. За неделю на рабочей системе Grafana набралось 553 пары RCA одного и того же оповещения: один вёл агент с картой, другой — без неё. Когда оба пришли к одному выводу, а таких пар было 258, агент с картой тратил меньше вычислений в 72 % пар, в типичной паре примерно на четверть. Повтор на 623 новых парах после доработки агента показал и скорость: с картой разбор заканчивался в типичной паре на 36 секунд раньше и был быстрее в 64 % пар. Итог: с картой RCA точнее и быстрее, а стоит не дороже.

Как внедрить анализ корневых причин в компании

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

Цель и границы. Сначала решить, зачем компании RCA: меньше повторных проблем, снижение простоев важных для бизнеса услуг, повышение предсказуемости обслуживания, меньше ночных вызовов дежурных. Цель должна измеряться, например долей отказов, которые повторились по уже известной проблеме, за квартал. Без такой цели внедрение превращается в отчётность ради отчётности. Границы тоже важны: не каждая проблема заслуживает полного анализа, и достаточно чётко записать, какие случаи разбирают обязательно. Обычно начинают с двух категорий: критичные инциденты и мелкие проблемы, которые повторяются и вместе съедают время поддержки.

Люди и роли. Нужен владелец процесса управления проблемами: человек, который отвечает за то, что проблемы заведены, разобраны и закрыты устранением. Нужна группа анализа: инженеры, которые знают систему и умеют читать логи и показатели; для сложных случаев подключают разработчиков и поставщиков. И нужно обучение и развитие персонала, прежде всего методам RCA. Они просты по форме, но без тренировки их применяют формально, и пять «почему» заканчиваются на втором. Понимание того, как устроена услуга, важнее любой техники опроса.

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

Регламент. Записать в рамках регламента, когда заводится проблема, кто ведёт анализ и в какой срок должна появиться первая версия причины. Это не срок на устранение: устранение может занять и месяц. Записать, как фиксируются известная ошибка и обходное решение, как решение об устранении проходит через управление изменениями и когда проблема закрывается. Регламент короткий, на одну-две страницы. Длинные не читают, и процесс живёт только на бумаге.

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

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

Риски внедрения. Три типичных риска внедрения RCA. Анализ ведут только после критичных инцидентов и никогда по накопленным данным. Проблемы заводят, но не закрывают. RCA делают для отчёта, под давлением сроков из соглашения об уровне услуг. Все три видны по журналу проблем. Поэтому первые выводы о том, работает ли процесс, стоит делать по десятку разобранных проблем, а не по одной. Отсутствие результата в первые месяцы обычно приводит не к отказу от RCA, а к его имитации: отчёты есть, устранения нет.

Где анализ срывается

Срывы похожи в любой компании, и почти все видны по журналу проблем: по тому, как заведена и чем закрыта проблема.

• Остановились на самом заметном симптоме. Шторм запросов из примера выше: событие громкое, правдоподобное и не причина.
• Остановились на человеке. «Инженер ошибся в настройке» — место, где анализ прекратили, а не корневая причина. Вопрос «почему настройку можно было применить без проверки» ведёт дальше, к процессу и к обучению.
• На анализ поставили срок из соглашения об уровне услуг. Инциденты меряются временем восстановления, проблемы — тем, нашли ли причину. Срок превращает анализ в отписку.
• Причина найдена, изменение не проведено. Проблема закрыта объяснением, а не устранением, и через месяц тот же отказ.
• Причина найдена, известная ошибка не записана. Следующий дежурный разбирает ту же проблему с нуля.
• RCA ведут ради виноватого. Тогда факты прячут, и цепочка рвётся на первом же человеке.

Как понять, что анализ сработал

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

ITIL 4 называет ещё две меры. Сколько инцидентов записано без связи с известной ошибкой: чем больше, тем позже начинается выявление проблем. И сколько инцидентов потребовали срочного разбора проблемы: это случаи, где искать пришлось во время аварии, а не до неё. Полезно считать и третье, уже своё: сколько проблем закрыто устранением, а сколько объяснением. Вторая доля — счёт отложенной работы. Часть её отложена осознанно, но видеть её надо целиком. Регулярно, раз в квартал, эти числа стоит смотреть вместе с планом устранения.

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

Как это выглядит в жизни

Как правильно и как не надо

Что спросить у поставщика, который обещает искать причину автоматически

Пять вопросов поставщику инструмента RCA, и каждый вырос из эксперимента выше. Ответы стоит сверять с тем, как у вас устроен процесс управления проблемами: программа встраивается в него, а не заменяет.

Откуда программа знает, что от чего зависит? Если ответ «из ваших данных наблюдения», уточните, строит ли она карту связей сама или ждёт вашей базы конфигураций. Без карты она будет чаще находить самый громкий сигнал.

Что она делает, когда данных нет? Попросите показать разбор без доступа к логам. Честный ответ — «не могу установить причину». Уверенный отчёт на пустом месте — повод отказаться.

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

Что она предъявляет как улику? Ссылку на конкретную строку лога, показатель, изменение — или просто формулировку. В запись проблемы годятся первые три, формулировка без ссылки — нет.

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

Чем отличается от проблемы

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

Разбор соседнего термина — проблема.

Чем отличается от разбора после сбоя

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

Разбор соседнего термина — разбор после сбоя.

Где встречается

Практики справочника, рядом с которыми живёт этот термин:

Своды знаний, в которых этот термин определён:

Что с этим делать здесь

Откуда термин

ITIL 4, руководство по практике управления проблемами (2020); ГОСТ Р ИСО/МЭК 20000-1—2021, пункт 8.6.3; ГОСТ Р ИСО 9001-2015, пункт 10.2; Grafana Labs, «Knowledge Graph as context for LLMs: demonstrating decisive RCA», 19.08.2026. Формулировка на этой странице своя.

Термины рядом