Root cause

As explained in Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform

The underlying condition or defect that produces an observed software problem.

A root cause is the underlying defect or condition that produces an observed problem. Finding it matters because a change that makes a symptom disappear may only hide or move the problem. In a microservices application, the search can cross several interacting processes, making the source harder to locate. section 11.3

When the cause is not obvious, narrow the search deliberately:

• Use monitoring or observability data to inspect current and historical behavior. Ask what went wrong and where to look next. section 11.3
• Form a hypothesis, then run an experiment to test it. Revise your search as the evidence rules out possible sources. section 11.3
• Once you identify the cause, fix it and check the result. A failing automated test that reproduces the problem gives you a reliable way to tell whether the fix works. section 11.3.1

Figure 11.11 Cutting away the problem space until we isolate the exact source of the bug

The search is a process of cutting away possible sources until the defect is isolated. section 11.3.1

After the fix, consider what could prevent the same problem or help the team find it sooner next time. A regression test helps with this specific failure; improving development habits can address the wider process. section 11.3.1

How Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform covers it

How deep it goes

Explains a search using observations, hypotheses, and experiments, then connects the identified cause to fixing, testing, and reflection.

Examples

Uses a problem-space isolation figure and a failing automated test that reproduces a bug.

What it assumes

Uses monitoring or observability data when available and treats an automated reproducing test as useful rather than required.

What you can do after

Diagnose/debug with it by isolating a defect, checking a fix against a reproducing test, and considering prevention.

How it connects

Connects root-cause analysis to observability, debugging, automated testing, and microservices.

liveBookmanning.com

Read Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  The Art of CodeA root cause is the underlying condition or defect that initiates or substantially contributes to an observed failure.
• 

  liveBookmanning.com
  Think Like a Software Engineering ManagerA root cause is an underlying factor responsible for an observed outcome, problem, or change.
• 

  liveBookmanning.com
  Troubleshooting Java, Second EditionThe underlying reason a software behavior or failure occurs.
• 

  liveBookmanning.com
  Writing for Developers: Blogs that get readThe underlying defect or condition that produces an observed software failure.

Compare how 5 books explain root cause →

Related concepts

• Five Whysaddressed by · The Five Whys is a root-cause analysis technique that repeatedly asks why a problem occurred to trace it toward underlying causes.
• exceptioncontrasts with · An exception is a runtime signal or object representing an abnormal condition that interrupts ordinary program flow and may be handled or propagated.
• cause analysisproduced by · Cause analysis is a systematic investigation of the underlying factors that produced a problem, failure, incident, or other outcome.
• countermeasureaddressed by · A countermeasure is an action or control intended to address a problem or threat by reducing its causes, effects, or likelihood.
• postincident analysisproduced by · Postincident analysis is a structured examination of an incident and its response to understand what occurred, identify causes, and determine improvements or corrective actions.

This explainer was generated by Manning's knowledge graph from the text of Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform. The section links point to the parts of the book it draws on.