The Cynefin framework defines four primary domains plus a fifth state called Disorder (or Confusion). Each domain has a distinct relationship between cause and effect, and each demands a fundamentally different action strategy.
1. Clear (formerly called Simple or Obvious)
The relationship between cause and effect is obvious to everyone. You do not need expertise or investigation. The answer is self-evident.
What it feels like: "I've seen this exact thing before. I know exactly what to do."
DevOps examples:
- A certificate expired. Renew it.
- A disk hit 100% capacity. Expand it or clean up logs.
- A new team member needs repository access. Follow the onboarding checklist.
- A deployment failed because the Docker image tag doesn't exist. Fix the tag.
The strategy: Sense → Categorize → Respond.
You observe the situation (sense), match it to a known category, and apply the established procedure. This is the domain of best practices — there is genuinely one right answer, and everyone should follow it.
The operational goal: Automate everything in this domain. If a human is repeatedly solving Clear problems, you are wasting engineering time. Write a script. Build a self-service portal. Create a Terraform module. The entire DevOps automation movement is fundamentally about moving Clear-domain work from humans to machines.
Certificate renewal is a good example of this shift in practice. It used to be a Clear-domain problem a human solved by hand: notice the expiry date approaching, renew it. Tools like cert-manager in Kubernetes now watch expiry dates and renew certificates automatically — the Clear-domain decision (renew before it expires) got automated away entirely, freeing engineers to spend their attention on problems that actually need judgment.
2. Complicated
The relationship between cause and effect exists and is stable, but it is not immediately obvious. You need expertise, investigation, or analysis to find it. Given enough time and skill, the answer is discoverable.
What it feels like: "I know there's a reason this is happening, but I need to dig to find it."
DevOps examples:
- A database query that was fast is now slow. You need to examine the query execution plan, check for index bloat, and review recent data growth patterns.
- Network latency between two services increased by 200ms. You need to trace the path, check for MTU mismatches, inspect iptables rules, and review recent infrastructure changes.
- A Kubernetes pod is being OOMKilled intermittently. You need to profile the application's memory usage patterns under different load conditions.
- Designing a high-availability architecture for a new service with specific RTO/RPO requirements.
The strategy: Sense → Analyze → Respond.
You observe the situation (sense), bring in expertise or conduct investigation (analyze), and then apply the solution. This is the domain of good practices — there are multiple valid approaches, and which one is "best" depends on context. A PostgreSQL expert might solve the slow query differently than a MySQL expert, and both solutions could be correct.
The operational goal: Build expertise and create runbooks. When a Complicated problem is solved, document the investigation path so that next time, a less experienced engineer can follow the same steps. This effectively shifts the problem toward the Clear domain over time.
A good runbook entry for a Complicated problem like intermittent pod OOMKills captures exactly that investigation path: check current memory limits against actual usage, determine whether usage is trending upward (a possible leak) or just sitting stable near the limit, then branch — bump the limit if usage is stable, escalate to the application team if it's trending upward. Written down once, the next engineer to hit this doesn't have to rediscover the investigation from scratch. That's the Complicated-to-Clear shift in action.
3. Complex
The relationship between cause and effect only becomes visible after the fact. You cannot predict the outcome in advance, no matter how much expertise you have. The system is adaptive — it changes in response to your actions.
What it feels like: "We fixed it, but I'm not entirely sure why it worked. Or it fixed itself and we don't know why."
DevOps examples:
- Cascading failures in a microservices mesh where retries from Service A overwhelm Service B, which causes timeouts in Service C, which triggers circuit breakers in Service D, which causes Service A to retry even harder.
- Intermittent performance degradation that correlates with no single metric but seems related to a combination of traffic patterns, garbage collection pauses, and network congestion.
- Migrating a monolith to microservices — you cannot fully predict how the new architecture will behave under real production load with real user patterns.
- Team reorganization — how will changing team boundaries affect deployment velocity, incident response times, and cross-team communication?
The strategy: Probe → Sense → Respond.
You cannot analyze your way to the answer because the system is too dynamic and interconnected. Instead, you run small, safe experiments (probes), observe how the system responds (sense), and then amplify what works or dampen what doesn't (respond). This is the domain of emergent practices — the solution reveals itself through experimentation, not analysis.
The operational goal: Maximize observability and minimize blast radius. You need rich telemetry (distributed tracing, structured logging, metrics with high cardinality) to detect how the system responds to your probes. You need feature flags, canary deployments, and traffic shaping to keep experiments small and reversible.
Suppose you suspect a cascading failure is caused by an overly aggressive retry policy on one service. A probe in the Complex domain doesn't mean rolling out a fix everywhere — it means reducing that service's retry count for a small slice of traffic (say, 10%) using a traffic-splitting rule, then comparing error rates between the probed slice and the untouched control group over the next couple of hours. If the probed slice improves, you've learned something real about the system's behavior — something no amount of upfront analysis could have told you, because in a Complex system the causal relationship only becomes visible after you act.
A common interview question is: "How do you troubleshoot an intermittent production issue that doesn't correlate with any single metric?" The strong answer demonstrates Complex-domain thinking: "I would design small, reversible experiments — like canary deployments or feature flag toggles — to isolate variables, while increasing observability to detect emergent patterns. I would not assume I can find the root cause through log analysis alone, because in complex systems, causation is often multi-factorial and only visible in hindsight." This shows you understand the difference between Complicated (analyzable) and Complex (emergent) problems.
4. Chaotic
There is no perceivable relationship between cause and effect. The system is in freefall. There is no time for analysis or experimentation.
What it feels like: "Everything is on fire. I don't know what's happening. We need to do something right now."
DevOps examples:
- An active security breach where an attacker is exfiltrating data in real time.
- A cloud provider has a region-wide outage and your disaster recovery plan has never been tested.
- A ransomware attack has encrypted your production databases and your backup integrity is unknown.
- A critical configuration change was applied to all production servers simultaneously and everything is down.
The strategy: Act → Sense → Respond.
The priority is to stop the bleeding. Take immediate, decisive action to establish some order — even if it's not the optimal action. Shut down the compromised server. Failover to the DR site. Revert the configuration change. Then assess the situation. Then respond more thoughtfully.
The operational goal: Have pre-planned "break glass" procedures that require zero analysis. When chaos hits, you need muscle memory, not investigation. This is why incident response drills, game days, and chaos engineering exist — they build the reflexes needed when there is no time to think.
A "break glass" response in the Chaotic domain looks like: immediately revert the last production deployment, then lock down all external traffic while you assess — decisive, low-analysis actions taken to stop the bleeding before you understand the full picture. Only once the system stops actively degrading do you shift out of Chaotic and into more deliberate diagnosis.
5. Disorder (Confusion)
This is not a domain — it is the state of not knowing which domain you are in. It is the center of the Cynefin diagram, and it is the most dangerous place to be. When you are in Disorder, you default to your comfort zone: an expert assumes the problem is Complicated, a manager assumes it is Clear, a firefighter assumes it is Chaotic. These defaults are often wrong.
The operational goal: Get out of Disorder as fast as possible. The first step in any incident response should be to classify the situation: "Do we know what's happening? Do we know how to investigate? Do we need to experiment? Do we need to act immediately?" This classification drives everything that follows.
Key Point: The domains are not permanent labels for systems — they describe the current state of your relationship with a problem. A problem that starts as Chaotic (active breach) transitions to Complex (understanding the attack vector) to Complicated (hardening the specific vulnerability) to Clear (adding the fix to your automated security baseline). Skilled incident commanders consciously manage these transitions, explicitly calling out when the team should shift strategy.