Always the same final answer to all WHYs
Root-cause analysis = ask WHY until the answer is ‘i don’t know’, meaning that root-cause analysis inevitably arrives @ UNKNOWN or UNKNOWABLE:
Boss: Our application is slow and end-users are unhappy, why?
You: Database is slow
You: Because our report query is taking too long.
You: Database server is out of memory.
You: I think Bob messed up. Honestly sir ….. we don’t have a clue. Sorry.
Boss: Call Bob.
Bob: …… Not my problem, sir. Nothing was changed.
The final answer will always be “I DON’T KNOW“, no matter what the original WHY is — just follow the chain. Most application diagnostic tools go 2-3 levels deep — app is slow; it is the database A or a WebService B; here is the exception or piece of code. 3 WHYS — Story Ends.
Root-cause analysis is like walking a decision tree, which predisposes that only 1 or a few conditions actually CAUSE your problem. In many instances it is the interplay of independent variables that create conditions for the problem to occur. Neither one specifically causes the problem. A better question to ask is HOW and not WHY. How the problem occurred allows you to explore process, conditions, context and relationships, which are far more telling then asking WHY recursively. HOW — paints the picture, WHY — draws the line.
It is about blame
Root-cause is about placing the blame. It is not about solving problems. The blame is always placed on the developer who is last on the WHY chain. It is the HOW that ultimately helps resolve problems, not the WHY. DevOps should avoid asking WHY and instead start asking HOW. Asking HOW helps people collaborate vs. blame and hide.