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

коренная (или причинная) проблема может быть связана с человеческим фактором, ошибкой, сбоем, проблемой процесса, да и вообще практически любой причиной.

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

самым удобным подходом для определения коренной причины считается "5 почему". когда на каждый возникший вопрос ответ будет "почему?". копаем, пока не поймем первопричину.

так же, можно пользоваться причинно-следственной диаграммой Исикавы, в которой от основной проблемы мы строим ответвления причин и следствий

плюс, перечислю несколько других способов (баззворды для гугла): FMEA, FTA, диаграмма Парето, диаграмма рассеяния

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

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

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

вау, многабукаф