7.2 Problem Management & Known Error Database
Key Takeaways
- Problem Management reduces the likelihood and impact of incidents by identifying actual and potential causes, establishing workarounds, and managing known errors.
- Reactive Problem Management investigates past disruptions and analyzes recurring incident trends, whereas Proactive Problem Management leverages infrastructure telemetry, health checks, and vulnerability reports to eliminate defects before failures occur.
- The practice executes across three structured phases: Problem Identification (trend detection), Problem Control (investigation via 5 Whys, Ishikawa fishbone, and Pareto), and Error Control (Known Error Records and permanent fix evaluation).
- The Known Error Database (KEDB) acts as an enterprise knowledge asset detailing symptoms, root causes, and verified workarounds, empowering frontline support and self-service portals to deflect and swiftly restore incidents.
7.2 Problem Management & Known Error Database
Quick Summary: While Incident Management mitigates the immediate symptoms of service failure, Problem Management identifies and addresses underlying causes to prevent recurrence and reduce operational risk. Through distinct reactive and proactive workflows, Problem Management navigates three core phases: Problem Identification, Problem Control, and Error Control. Central to this practice is the Known Error Database (KEDB), an enterprise repository of documented root causes and verified workarounds that accelerates user support and enables shift-left resolution.
In ITIL 4 Create, Deliver and Support (CDS), organizations must transition from firefighting repetitive operational emergencies to eliminating systemic instability. Problem Management represents the primary practice responsible for understanding why incidents occur and mitigating their architectural impact.
Purpose & Core Concepts: Incident vs. Problem
Understanding practice boundaries is essential for the CDS exam:
- Incident: An unplanned interruption to a service or reduction in the quality of a service (e.g., a payment service returning HTTP 500 errors).
- Problem: A cause, or potential cause, of one or more incidents (e.g., thread pool exhaustion in a checkout microservice under heavy load).
- Known Error: A problem that has been analyzed and has a documented root cause and/or a viable workaround.
The primary objective of Problem Management is to reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents, and managing workarounds and known errors.
Reactive vs. Proactive Problem Management
Problem Management operates through two complementary operational workflows:
| Dimension | Reactive Problem Management | Proactive Problem Management |
|---|---|---|
| Primary Trigger | Incidents, major outages, or recurring incident patterns | Telemetry trends, health checks, capacity alerts, audits |
| Operational Goal | Identify root cause and establish workarounds for past disruptions | Eliminate latent vulnerabilities before incidents manifest |
| Key Inputs | Major incident reports, Post-Incident Reviews (PIRs), ticket clusters | APM telemetry, log analytics, security scanning, stress tests |
| Timing | Post-disruption (responsive to realized operational impact) | Continuous and pre-emptive (prior to user-visible impact) |
| Typical Activities | Facilitating blameless post-mortems; analyzing incident recurrence | Reviewing memory leak trends; analyzing third-party patch notes |
In modern CDS value streams with Continuous Delivery and cloud architectures, proactive problem management leverages automated telemetry. Algorithms analyze infrastructure performance drift, identifying memory leaks, disk fill-rate trajectories, and latency anomalies long before service levels degrade.
The Three Phases of Problem Management
Problem Management executes through three sequential, disciplined phases:
[Incident Clusters / APM Alerts] ──> Phase 1: Problem Identification
│ (Problem Record Logged)
▼
Phase 2: Problem Control
│ ──> 5 Whys Analysis
│ ──> Ishikawa Fishbone Diagram
│ ──> Pareto 80/20 Prioritization
│ (Root Cause & Workaround Found)
▼
Phase 3: Error Control
│ ──> Known Error Record (KER) in KEDB
│ ──> Cost-Benefit of Permanent Fix
▼
┌──────────────────┴──────────────────┐
▼ ▼
[Permanent Fix Justified] [Workaround Accepted]
│ │
Submit RFC to Change Enablement Maintain KER in KEDB
Phase 1: Problem Identification
Identifies and logs problems by analyzing incident trends, service desk ticket patterns, monitoring alerts, and supplier advisories. Activities include:
- Detecting duplicate or recurring incidents logged across the Service Desk.
- Conducting post-incident analysis following a resolved Major Incident.
- Logging structured Problem Records capturing affected Configuration Items (CIs), symptoms, and potential business exposure.
Phase 2: Problem Control
Investigates the problem to diagnose the root cause and formulate effective workarounds. When a problem cannot be resolved immediately, teams establish a validated workaround to mitigate ongoing disruption. Key analytical techniques include:
- The 5 Whys: An iterative inquiry drilling past superficial technical symptoms to uncover foundational design, testing, or process failures.
- Ishikawa (Fishbone) Diagram: A structured diagram categorizing potential failure causes across major axes: People (skills, training), Process (procedures, handoffs), Technology (code, database), Partners/Suppliers (third-party APIs), and Environment.
- Pareto Analysis (80/20 Rule): Demonstrates that roughly 80% of service disruptions stem from 20% of underlying infrastructure components or recurring bugs, ensuring engineering resources target high-yield fixes.
Phase 3: Error Control
Manages known errors where initial analysis is complete. Once root cause and/or a viable workaround are determined, the problem transitions into a Known Error Record (KER):
- Evaluating Permanent Solutions: The team conducts cost-benefit and risk assessments. Fixing every defect is neither economically viable nor operationally safe. If rewriting a legacy module costs $200,000 but the defect causes only $5,000 of annual impact and has an automated script workaround, the organization may formally accept the known error and maintain the workaround indefinitely.
- Initiating Changes: When a permanent fix is justified, Error Control submits a Request for Change (RFC) to Change Enablement.
- Workaround Review: Error Control periodically re-evaluates documented workarounds to verify they remain viable as underlying architectures evolve.
The Known Error Database (KEDB)
The Known Error Database (KEDB) is an enterprise repository containing all active and historical Known Error Records. A well-architected KEDB record includes:
- Known Error Identifier & Title: Clear naming linked to affected services and CIs.
- Symptom Profile: Exact error codes, logs, stack traces, and user-visible behavior.
- Identified Root Cause: Technical explanation of the underlying failure mechanism.
- Verified Step-by-Step Workaround: Clear instructions enabling support agents or users to bypass the error immediately.
- Permanent Fix Status: Current state within the development backlog, planned release version, or formal acceptance as an open known error.
A mature KEDB integrates with the Service Desk to suggest workarounds during triage, surfaces articles in user self-service portals to deflect tickets, and enables robotic scripts to automate self-healing.
Practice Boundaries: Incident vs. Problem vs. Change Enablement
| Practice | Primary Mission | Key Output | Typical Action |
|---|---|---|---|
| Incident Management | Rapid service restoration | Restored operational service | Restarting an unresponsive application node |
| Problem Management | Root cause identification & trend elimination | Known Error Records, workarounds | Analyzing heap dumps to locate the memory leak |
| Change Enablement | Risk assessment & change authorization | Authorized Change Models, releases | Authorizing memory limit updates in production |
Critical Exam Traps & Guidance
[!WARNING] Exam Trap: Requiring a Permanent Fix for Known Error Classification
A problem becomes a Known Error as soon as root cause is understood and/or a viable workaround is documented. Organizations may permanently accept known errors without developing software patches if the cost or risk of fixing outweighs the benefit.
[!IMPORTANT] Exam Trap: Problem Management Authorizing Production Fixes
Problem Management investigates root causes and designs fixes, but never authorizes or deploys changes directly in live environments. Permanent fixes must be submitted to and authorized by Change Enablement to safeguard live service stability.
An IT service provider conducts two distinct problem management activities: first, engineering teams review monthly telemetry trends to detect subtle memory leaks in microservices before users notice latency; second, an incident commander facilitates a post-incident review following a severe network outage to uncover why redundant links failed. Which types of problem management do these activities represent?
A problem management team is investigating why an enterprise billing system experienced intermittent transaction drops over the past quarter. To ensure a thorough diagnosis, the lead investigator maps potential causes across five categories: People, Process, Technology, Partners/Suppliers, and Environment. Which root cause analysis technique is being applied?
During the Error Control phase of Problem Management, engineers identify the root cause of a legacy application defect that causes sporadic print spooler errors once a quarter, costing approximately $500 annually in lost productivity. Developing a permanent software fix requires rewriting core legacy modules at an estimated engineering cost of $150,000 and carries significant regression risk. An automated PowerShell restart script resolves the error in ten seconds. What should Problem Management decide?
A production database node encounters sudden storage exhaustion, crashing an enterprise retail portal. An engineer executes three distinct tasks: (1) runs a script to purge temporary cache files and restart the node to restore customer checkout; (2) examines database log files and transaction growth rates to identify the unpurged audit table causing the bloat; (3) submits an authorization request to alter production maintenance schedules and apply a schema modification. How are these three tasks correctly mapped to ITIL 4 practices?