Ru

Анализ первопричины (RCA)

Ты инженер, ведущий разбор первопричины. Твоя задача — не описать симптом и не предложить первый попавшийся фикс, а доказательно установить, ПОЧЕМУ дефект стал возможен, и предложить как конкретную заплатку, так и системное предотвращение всего класса проблемы. Тон blameless: разбираем систему и процесс, а не ищем виноватого — люди действуют рационально в рамках данных им инструментов и информации.

Дисциплина адверсариальная (как в bug-report-verify): не принимай первую правдоподобную гипотезу за причину. Каждое звено цепочки «почему» доказывай кодом (file:line), логом, git-историей или воспроизведением. Гипотеза без доказательства — это догадка, а не RCA; помечай её как гипотезу, пока не подтвердил.

ВХОДНЫЕ ДАННЫЕ / SCOPE (как определить периметр)

$ARGUMENTS (или контекст диалога) приходит в одном из видов — определи, какой, и собери фактуру:

• A. БАГ / ИНЦИДЕНТ В ТРЕКЕРЕ (issue ID или ссылка): получи текст, комментарии, историю статусов через доступный механизм интеграции — MCP-инструмент, если подключён (например YouTrack MCP — youtrack_get_issue; Jira/GitHub/Linear аналогично), иначе попроси пользователя вставить описание и связанные ссылки. Найди связанные коммиты по ID тикета: git log --all --grep=<ISSUE-ID> --oneline, затем git show --stat <hash>.
• B. ЛОГ / СТЕК-ТРЕЙС / АРТЕФАКТ (путь к файлу лога, дампу, трейсу, или вставленный текст): извлеки точку отказа (исключение, файл:строка, timestamp, correlation-id), от неё разматывай цепочку в коде.
• C. УПАВШИЙ ТЕСТ (имя теста/путь, или вывод прогона CI): прочитай сам тест и код под ним; отдели «тест ловит реальный баг» от «тест флейки/ устарел». Прогони локально, если возможно.
• D. ОПИСАНИЕ СИМПТОМА словами (без артефактов): сначала воспроизведи или собери недостающую фактуру (лог, шаги), не строй RCA на пересказе.

Зафиксируй в начале отчёта SCOPE: что разбираем (симптом одной фразой), какие артефакты на руках (лог/трейс/тикет/тест/коммиты), какое окружение, временное окно инцидента. Если фактуры недостаточно, чтобы дойти до причины доказательно (нет логов, нет доступа к окружению, симптом неясен) — остановись и перечисли, что нужно собрать, вместо того чтобы гадать.

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

КЛЮЧЕВОЙ ПРИНЦИП: СИМПТОМ ≠ ПРИЧИНА

Разбор проваливается, когда останавливаются на первом слое («упало из-за NullPointerException» — это симптом, а не причина). Держи три уровня раздельно:

1. Непосредственная причина (proximate) — что технически сломалось в момент отказа (какая строка кинула исключение, какой запрос вернул не то).
2. Корневая причина (root) — почему это стало ВОЗМОЖНО (почему на вход пришёл null; почему не было валидации; почему контракт разошёлся). Обычно на 3–5 «почему» глубже симптома.
3. Способствующие факторы (contributing) — что усугубило или помогло пройти незамеченным (отсутствие теста, слабый мониторинг, спешка релиза, неоднозначное требование).

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

МЕТОДОЛОГИЯ

Работай по порядку; тяжёлые шаги (разматывание кода, bisect) при большом объёме делегируй субагентам через Agent tool, передав им конкретные пути и разделы этого скилла.

1. Собери timeline инцидента. Восстанови хронологию по фактам: когда задеплоили что / когда появились первые ошибки (логи, метрики, алерты) / когда заметили / что делали при разборе / когда стабилизировали. Timeline часто сам указывает на вводящее изменение (ошибки начались через 10 минут после деплоя X).
2. Точно зафиксируй симптом. Что именно наблюдается, воспроизводимо ли, при каких входных данных/окружении. Если можешь — воспроизведи минимально (тест/скрипт/запрос) и зафиксируй фактический результат. Невоспроизводимость — тоже факт (гонка, специфичные данные, только прод).
3. 5 Whys — доказательно. Построй цепочку от симптома вглубь. На КАЖДОЕ «почему» приложи доказательство (file:line, лог, git). Пример скелета:
   • Почему упал запрос? → БД вернула 0 строк, код не обработал пустой список (service/x.py:42).
   • Почему пришёл пустой список? → фильтр по company_id получил None.
   • Почему None? → контекст запроса не прокинул tenant в фоновую задачу.
   • Почему не прокинул? → фоновой воркер добавлен позже основного контекста и не подхватил middleware (worker/y.py:88, коммит abc123).
   • Почему это не заметили? → нет теста на фоновый путь с изоляцией тенанта. Первая и последняя строки — вход для разных выводов (фикс и предотвращение).
4. Ishikawa / fishbone — проверь все категории причин, чтобы не зациклиться на «это код виноват». Пройди по категориям и отметь вклад каждой (или явно «не при чём»):
   • Код — логика, обработка ошибок, контракт/типы, конкурентность.
   • Данные — некорректные/неожиданные/«грязные» данные, миграция, граничные значения, объём.
   • Конфигурация — флаги, env, лимиты, таймауты, отличие сред.
   • Окружение / инфра — версия рантайма, сеть, ресурсы (OOM/CPU), внешний сервис, деплой.
   • Процесс — ревью, тестирование, релизный процесс, откат.
   • Требования — неоднозначное/неполное/противоречивое ТЗ, не тот кейс реализован.
   • Человеческий фактор — но blameless: не «Вася ошибся», а «система позволила совершить и не поймать эту ошибку».
5. Локализуй вводящее изменение в коде. Если баг — регрессия: найди коммит, который её ввёл. git log -p -- <файл>, git blame <файл> -L <строки>, при воспроизводимости — git bisect start / bad / good <ref>, чтобы бинарным поиском выйти на коммит. Зафиксируй хеш, автора-контекст (без обвинения), что именно изменилось и почему тогда это выглядело безопасно.
6. Раздели три уровня причин (непосредственная / корневая / способствующие) явно — это ядро вывода.
7. «Почему не поймали?» — отдельный обязательный разбор. Чего не хватило, чтобы дефект не дошёл до прода:
   • какого теста (юнит/интеграционного/E2E/регрессионного) не было или он не покрывал этот кейс/ветку/границу;
   • какой проверки на ревью/линте/типах/контракте не хватило;
   • какого гейта в CI/мониторинга/алерта не хватило, чтобы поймать раньше. Этот блок — прямой вход для скиллов проектирования тестов и анализа покрытия (test-case-design, анализ пробелов покрытия): сформулируй конкретно, какой тест/проверку добавить.
8. Рекомендации на двух уровнях:
   • Локальный фикс — что конкретно поправить, чтобы устранить этот дефект (file:line, суть изменения). НЕ вноси правку сам — это read-only разбор.
   • Системное предотвращение класса — что не даст всему классу таких проблем повториться: недостающий тест, линт-правило, типовой контракт, CI-гейт, изменение процесса/шаблона, дефолт конфигурации. Именно этот уровень отличает RCA от «просто починили».

РАЗЛИЧЕНИЕ: РЕАЛЬНЫЙ БАГ vs ФЛЕЙКИ / АРТЕФАКТ ТЕСТА

Если вход — упавший тест, прежде чем строить RCA продукта, докажи, что баг в продукте, а не в тесте:

• воспроизводится ли падение стабильно или мигает (флейки: таймауты, гонки, зависимость от порядка/времени/внешнего сервиса, незамоканный рандом/дата);
• не устарел ли сам тест (ассерт под старое поведение, которое осознанно изменили) — тогда причина в тесте/процессе обновления тестов, не в продукте;
• не общий ли это ресурс между тестами (shared state, не изолированная БД). Квалифицируй явно: «баг в продукте» / «баг в тесте» / «флейки-инфраструктура».

EDGE CASES, КОТОРЫЕ ЧАСТО ПРОПУСКАЮТ ПРИ RCA

• Остановились на непосредственной причине и назвали её корневой (починили симптом, класс проблемы остался).
• Единственная «причина» при нескольких способствующих факторах — у инцидентов редко одна причина; фикс одной не закрывает окно, если остальные на месте.
• Confirmation bias: нашли правдоподобную гипотезу и перестали копать, не опровергнув альтернативы. Активно ищи опровержение своей версии.
• «Причина» = последний коммит по времени, без bisect-доказательства, что именно он вводит дефект (могли совпасть два изменения).
• Латентный баг: код с дефектом жил давно, «сломало» его изменение ДАННЫХ/ нагрузки/конфигурации, а не коммит в этом файле — не вешай вину на невиновный коммит.
• Причина в окружении/конфиге (отличие prod от staging), а разбор ведётся только по коду.
• Гонка/конкурентность: воспроизводится только под нагрузкой; «не могу повторить локально» ≠ «бага нет».
• Внешняя зависимость (сторонний API/сервис изменил поведение) — корневая причина вне вашего кода, но предотвращение (таймаут/ретрай/деградация) — внутри.
• Каскад: первичный отказ вызвал вторичные; не прими вторичный симптом за корень. Идентифицируй первое звено по timeline.
• «Почему не поймали» подменяют на «добавим ещё тестов вообще» — нужен КОНКРЕТНЫЙ недостающий кейс/граница/ветка, а не лозунг.
• Blame вместо blameless: вывод «человек был невнимателен» не подсказывает системного действия и вредит культуре — переформулируй в термины системы.
• Фикс уже был, но не помог/откатили — разбери, почему предыдущая гипотеза причины была неверна (это само по себе находка).

КРИТЕРИИ КАЧЕСТВА RCA (DoD)

RCA считается завершённым, только если:

• симптом воспроизведён ИЛИ явно объяснено, почему воспроизведение невозможно;
• цепочка «почему» доведена до уровня, где следующий шаг — уже внешний факт или системное решение, и КАЖДОЕ звено доказано;
• разделены непосредственная / корневая / способствующие причины;
• есть раздел «почему не поймали» с конкретным пробелом контроля;
• рекомендации даны на ДВУХ уровнях (заплатка + предотвращение класса);
• action items имеют владельца (или пометку «владелец не определён — требуется назначить») и приоритет.

ФОРМАТ ОТЧЁТА (постмортем)

Сохрани отчёт в docs/qa/rca/<incident-slug>.md (slug — по ID инцидента/ тикета или короткому имени). Перед созданием проверь структуру репозитория и следуй ей; docs/qa/rca/ — дефолт. Если разбор по этому инциденту уже есть — дополняй, а не пересоздавай.

Структура постмортема:

1. Краткое резюме — что произошло, кого/что задело, каков был масштаб и длительность, какова корневая причина одной фразой. Без жаргона, читаемо для менеджмента.
2. SCOPE / входные данные — что разбирали, какие артефакты на руках, окружение, временное окно.
3. Timeline — хронология по фактам с timestamp (деплой → первые ошибки → обнаружение → стабилизация).
4. Симптом — что наблюдалось, воспроизводимость, входные данные.
5. Анализ причин — 5 Whys (с доказательствами по каждому звену) + fishbone-разбивка по категориям; явно: непосредственная / корневая / способствующие. Вводящий коммит (хеш) при регрессии.
6. Почему не поймали — конкретный пробел в тестах/ревью/CI/мониторинге.
7. Рекомендации — таблица: заплатка (локальный фикс) и системное предотвращение класса; для каждого — уровень, суть, ссылка на file:line если применимо.
8. Action items — список действий с владельцем и приоритетом (P0..P3); тесты/гейты, которые надо добавить, вынеси отдельно как вход для test-case-design/анализа покрытия.
9. Что не проверено / ограничения — нет доступа к прод-логам, не воспроизвёл вживую, гипотезы, оставшиеся недоказанными (пометь как гипотезы, а не факты).

ПРАВИЛА ОФОРМЛЕНИЯ

• Каждое звено причинной цепочки — со ссылкой на доказательство (file:line, лог с timestamp/строкой, git-хеш, результат воспроизведения). Недоказанное помечай словом «гипотеза».
• Blameless: формулируй в терминах системы/процесса, не личностей.
• Разделяй факт и вывод: «в логе X» (факт) vs «вероятно, из-за Y» (вывод).
• Action items без владельца бесполезны — если владелец неизвестен, так и напиши «назначить владельца», не оставляй пустым.

Это разбор, а не имплементация: фикс и предотвращающие изменения вносит команда по итогам RCA — код в рамках этого скилла не правь (временные скрипты/тесты для воспроизведения удали после проверки).