Skip to content

CONCEPT Cited by 1 source

Systems thinking for reliability

Definition

Systems thinking for reliability is the engineering-discipline stance that software systems are complex socio-technical systems whose reliability behaviour is non-linear, and that the right substrate for managing them is control theory: explicit feedback loops, phased actuation, bounded rate of change, and back-off on observed deviation — not linear reasoning about direct effects.

The stance is canonicalised verbatim in Redpanda's 2025-06-20 GCP-outage retrospective (sources/2025-06-20-redpanda-behind-the-scenes-redpanda-clouds-response-to-the-gcp-outage):

"With the resurgence of AI, systems will inevitably get even more complex. So, it seems valuable and timely to reconsider our current mindset, and I cannot think of anything better than a systems thinking mindset, especially when engineering our socio-technical systems, which should also result in increased adoption of control theory in our change management tools."

The six-mitigation substrate

Named in Redpanda's retrospective as the concrete engineering primitives a systems-thinking posture produces in change-management tools. These are the controls that keep non-linear systems from going runaway under the small perturbations they routinely experience:

  1. Closed feedback control loops — measure deviation from a setpoint during any change and actuate on the deviation, not on the change schedule. See concepts/feedback-control-load-balancing.
  2. Phased change rollouts — no change goes from zero to 100% of the fleet; every change passes through observable intermediate states. See patterns/staged-rollout.
  3. Load shedding — drop low-value work under saturation so saturation doesn't propagate into cascading failure.
  4. Backpressure — slow upstream when downstream can't keep up; prevent unbounded queueing from masking the problem until catastrophic. See concepts/backpressure.
  5. Randomised retries — avoid retry-storm synchronisation; jittered back-off so clients don't collectively amplify each glitch.
  6. Incident response processes — a rehearsed playbook for the moment when the first five have been overwhelmed.

Redpanda's retrospective also names chaos + load testing as part of the substrate — the Netflix Simian Army discipline applied as standard vendor hygiene.

The two canonical industry instances

The 2025-06-20 post positions two industry-scale outages as instances of the same structural gap — a failure to internalise systems-thinking in change-management tooling:

  1. 2024-07 Crowdstrike Falcon update — a content-update file pushed globally to Falcon agents cascaded into a kernel crash on millions of Windows hosts, "affecting millions of Windows computers, and resulting in hundreds of millions of dollars in damages to their customers". The mitigations that were missing: phased rollout, feedback control loops, load- shedding on bad-update-rate.
  2. 2025-06-12 GCP outage — an automated quota update to GCP's API management system cascaded into a global multi- service outage. Same class of failure (global rollout of a small change + missing feedback control).

The retrospective framing: "As an industry, it seems we keep having to relearn hard lessons from the past."

Why it's hard

  • Linear reasoning is cheap; systems reasoning is expensive. Most change-management decisions can be made in seconds by reasoning about direct effects. Systems-thinking requires modelling second- and third-order interactions — a much higher cognitive and tooling cost.
  • Socio-technical feedback is slow. The incentives that drive change-management culture are faster than the incentives that drive reliability culture. Teams ship features weekly; they have incidents yearly. The signal-to-noise ratio on reliability investments is genuinely low in the short run.
  • Control theory is not part of standard CS curriculum. Backpressure, PID controllers, stability margins, observability-as-control-input are more common in hardware / controls-engineering / aerospace curricula than in software engineering. The gap is a training issue, not a technology issue.
  • Tooling is not there by default. Most change-management tooling lacks primitives for "abort the rollout if metric X deviates by Y%" as a first-class notion. Feature flags, canary deploys, progressive delivery systems are the partial substrate that exists today; not every team has access to them.

What AI shifts

The Redpanda retrospective positions AI as amplifying the need for systems-thinking: "Time will tell, perhaps all the above will be left to AI agents to control, perhaps not, for the foreseeable future, it seems we have no AI replacement, so we better hone our systems thinking skills." The framing is humble: AI agents are not yet a substitute for human systems-thinking; their introduction adds complexity (another control loop, another non-linear feedback path, another surface for cascading failure), so the discipline becomes more important, not less.

Caveats

  • Systems-thinking is a posture, not a deliverable. The concept page can enumerate six mitigations and a framing quote; applying them is ongoing work. "We've adopted systems thinking" is not a meaningful claim; "we require phased rollout + feedback control on every change that touches a shared dependency" is.
  • The Crowdstrike / GCP framing is editorial. Redpanda is making a retrospective argument that these outages share a root cause. A formal RCA would need access to each vendor's internal change-management tooling and post-mortem process to evidence the claim. The wiki preserves the framing as one vendor's reasoned position, not as a consensus analysis.
  • Not every reliability failure is a systems-thinking gap. Some outages are straightforward bugs, bad configuration, or hardware failures that linear reasoning would have caught. The systems-thinking framing is most load-bearing for global rollout of a small change class of incident — where the change looked innocuous and the consequences did not.
  • Systems-thinking posture doesn't obviate cell-based architecture, static stability, or chaos engineering. It's the engineering-philosophy layer above those substrate primitives, not a substitute. The six-mitigation list is concrete; the philosophy is the scaffolding.

Seen in

  • sources/2025-06-20-redpanda-behind-the-scenes-redpanda-clouds-response-to-the-gcp-outage — Canonical wiki introduction of the systems-thinking-for- reliability framing. Redpanda's 2025-06-20 GCP-outage retrospective closes with a systems-thinking-and-control- theory prescription for change-management tooling, positions Crowdstrike 2024-07 + GCP 2025-06 as paired instances of the same structural gap, and enumerates the six concrete mitigations (feedback control loops, phased rollouts, load shedding, backpressure, randomised retries, incident response processes) that a systems-thinking posture produces. The essay voice is editorial but the six-mitigation list is concrete substrate-canonicalisation.
Last updated · 470 distilled / 1,213 read