Introduction

Hello, I'm Yuto Takashi from TIELEC Inc.

In this article, I'll introduce the DECSAR Method, a structured methodology for strategic troubleshooting.

For those of you in infrastructure operations, troubleshooting can be challenging, right? The DECSAR Method is a strategic framework that systematically organizes troubleshooting approaches from an academic perspective. If you're struggling with how to approach troubleshooting, this article is for you.

2026 January Update: Added a practical example from an actual Jenkins EFS incident response.

The DECSAR Method

What is the DECSAR Method?

The DECSAR Method is a troubleshooting approach consisting of six steps. It was developed by Craig Ross and R. Robert Orr as a standardized methodology to help students effectively learn troubleshooting techniques.

The Six Steps of DECSAR

  1. Defining the problem
  2. Examine the Situation
  3. Consider the Causes
  4. Consider the Solutions
  5. Act and Test
  6. Review Troubleshooting

The acronym DECSAR comes from the first letters of each step.

Let me explain each step in detail.

Defining the Problem

In the first step, you define the problem. The troubleshooter carefully considers the cause of the system malfunction to maximize the chances of finding an effective solution.

Examine the Situation

In the second step, the troubleshooter observes the entire system, paying attention to both what is functioning correctly and what is not, and documents findings for later review.

Consider the Causes

In the third step, you consider the causes of the problem. The troubleshooter presents multiple possible reasons for the system failure and ranks them according to the likelihood of being the root cause.

Consider the Solutions

In the fourth step, you consider solutions to the problem and rank them similarly to the cause analysis. You also verify that alternative troubleshooting approaches are available in case the first solution fails.

Act and Test

In this step, the solution is implemented and its effectiveness is verified. The results after implementing the solution are compared with the observations from the situation examination.

Review Troubleshooting

Finally, once the system is repaired, the troubleshooter strives to deepen their understanding of the system to handle future incidents more smoothly.

Practical Example: Complete DECSAR Process in Jenkins EFS Issue

Let's examine how the DECSAR Method functions in actual incident response, using the Jenkins EFS issue that occurred in January 2026 as an example.

Problem Overview

On Monday morning, Jenkins became slow, Git clone operations failed, and 504 errors were frequent. Through approximately three days of investigation and response, we identified the root cause and implemented a permanent solution.

Each DECSAR Step

1. Defining - Problem Definition

What happened: We moved from a vague sense of "it's slow" to a specific problem definition: "Jenkins overall is slow and Git operations are failing."

Key point: By observing multiple symptoms (slowness, errors, timeouts), we identified the common underlying problem.

2. Examine - Situation Investigation

Observations:

Key point: We comprehensively checked CloudWatch metrics and recorded both normal and abnormal aspects.

3. Consider the Causes - Cause Analysis

Evolution of hypotheses:

  1. Initial hypothesis: Temporary network issue
  2. As investigation progressed: tmp_pack_* (Git temporary files) accumulated to ~15GB
  3. Deeper analysis: From Burst Credit Balance graph, problem surfaced on 1/26, but root cause originated on 1/13

Final causes (compound):

Key point: By analyzing graphs chronologically rather than just surface symptoms, we reached the true root cause.

4. Consider the Solutions - Solution Planning

Solutions considered and decisions:

Solution Decision Reasoning
Continue Burst mode ❌ Investigation difficult with credit depleted
Provisioned 300 MiB/s ⚠️ Emergency High cost ($69/26h) but allows investigation
Elastic Throughput ⚠️ Temporary Surprisingly costly ($8/day)
Enable Shared Library caching ✅ Permanent Root solution

Key point: We considered multiple options from emergency response to permanent solution, clarifying trade-offs.

5. Act and Test - Implementation and Verification

Action taken: Enabled Shared Library caching (Refresh time: 180 minutes)

Results:

Key point: We compared metrics recorded during situation investigation with post-solution results, verifying effectiveness quantitatively.

6. Review - Retrospective

Technical learnings:

Process learnings:

Future actions:

Key point: Rather than just solving the problem, we verbalized it as organizational knowledge and implemented recurrence prevention measures.

Detailed Chronicle

For detailed coverage of this entire response, see our four-part series:

  1. How Jenkins Gradually Stopped Git Cloning - Problem discovery and emergency response
  2. Spending $10,000 on Provisioned Throughput - Dealing with costs
  3. Jenkins & EFS Continued ― Problem Surfaced on 1/26, But Root Cause Was on 1/13 - Root cause discovery
  4. SRE Work ― From Problem Discovery to Permanent Solution and Results - Final report and retrospective

Summary

Let me summarize the key points.

The DECSAR Method is a troubleshooting approach consisting of six steps:

  1. Defining the problem
  2. Examine the Situation
  3. Consider the Causes
  4. Consider the Solutions
  5. Act and Test
  6. Review Troubleshooting

Troubleshooting skills are essential for IT professionals, but many find them abstract and difficult to master.

Why not start by incorporating the DECSAR Method as a framework for approaching your troubleshooting tasks?

Even in actual incident response, being conscious of this framework makes it easier to grasp the overall picture of the problem and find effective solutions.

[📦 商品リンク: moshimo-backlog-banner-728x90]

Related Books

Recommended books for those who want to learn more about troubleshooting and SRE:

[📦 商品リンク: moshimo-book-sre-google]

[📦 商品リンク: moshimo-book-aws-operations]

References