Chapter 33 — Safety and resilience under partial failure

Chapter 33 — Safety and resilience under partial failure

Lesson map

Lesson 33 published. Map, example, EX065.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["33.1 What fail-safe means for response"]
  N2["33.2 Circuit breakers and bulkheads"]
  N3["33.3 Expiry and leases"]
  N4["33.5 Monitoring and manual override"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX065"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["33.1 What fail-safe means for response"]
  N2["33.2 Circuit breakers and bulkheads"]
  N3["33.3 Expiry and leases"]
  N4["33.5 Monitoring and manual override"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX065"]

[Learning outcomes and connection]
    |
    v
[33.1 What fail-safe means for response]
    |
    v
[33.2 Circuit breakers and bulkheads]
    |
    v
[33.3 Expiry and leases]
    |
    v
[33.5 Monitoring and manual override]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX065]

Learning outcomes and connection

After this chapter you can (1) define fail-safe states for response components whose dependencies fail; (2) apply circuit breakers, isolation and timeouts to prevent cascading harm; (3) design monitoring and manual override for automatic and manual recovery; and (4) test safe behaviour when the policy service or control plane is unreachable. It builds on Chapters 10, 17, 26 and 32 and prepares Chapters 38, 40 and 47.

33.1 What "fail-safe" means for response

A component is fail-safe if, on failure, it moves to a state that does not cause harm. For a containment controller, which state is safe depends on the action. If it loses contact with the policy service, should hosts already isolated stay isolated? Should pending isolations proceed? The answer must be decided per action class and written down: typically, already applied containment persists until a human with authority reverses it or its approved expiry passes; no new containment is initiated without fresh policy confirmation; collection continues. Leveson's STAMP model (2004) treats such unsafe control actions — providing, not providing, providing too late or too long — as the core of system safety analysis.

33.2 Circuit breakers and bulkheads

A circuit breaker stops calls to a failing dependency after a threshold of errors, returning a defined failure quickly instead of piling up retries; it probes periodically and closes when the dependency recovers. A bulkhead isolates resources so one tenant's or one integration's failure cannot exhaust shared capacity. For response, a breaker on the endpoint-management API prevents a retry storm from making a provider outage worse; a bulkhead prevents a flood of one client's alerts from starving others. In the HVSS partition, the controller's breaker opens after five consecutive failures and probes every 30 s.

33.3 Expiry and leases

Containment applied under a lease expires unless renewed by an authorised decision. Leases bound the harm of a controller that crashes or loses its policy: a forgotten isolation ends automatically, and the expiry is visible in advance. But expiry is itself an action with risk — releasing a compromised host — so the case must alert the owner before expiry.

In the HVSS partition example, one lease reached its expiry while the controller could not consult the policy service. The design extended it once by 60 minutes automatically and alerted the duty manager, so a compromised workstation was not released without review. The extension is bounded, so a forgotten isolation still ends.

33.4 Worked example (synthetic): controller loses its policy service

HVSS's containment controller enforces network isolation for workstations via the endpoint agent and consults a policy service for scope rules. A network partition separates the controller from the policy service for 40 minutes.

Designed behaviour:

Test results in staging: existing isolations persisted; one lease extended and the alert reached the duty manager; two queued requests executed after the policy service returned, each re-checked against current policy — one was rejected because the target had been reassigned to another tenant during the partition, demonstrating why queued requests must be re-checked rather than replayed.

33.5 Monitoring and manual override

Monitor: breaker states, queued-action count and age, lease expiries in the next hour, and controller heartbeat. Manual override must exist, be tested, be logged and be harder to use than the normal path — never easier, or it becomes the normal path.

During the 40-minute HVSS partition, these signals would show an open breaker toward the policy service and two queued isolation requests growing older. They would also show the lease that was extended and alerted. The duty manager's break-glass isolation is limited to a single host and requires retrospective approval, which keeps it harder than the normal path.

33.6 Errors and limits

• One failure behaviour for all actions.
• Replaying queued actions without re-checking current policy.
• Leases that expire silently.
• Override paths that bypass logging.

The staging test of the HVSS partition shows why the second error matters most. Of the two queued isolation requests, one targeted a host that had been reassigned to another tenant during the 40 minutes. Replaying it without a policy re-check would have isolated a machine outside the case's authority. The test also confirmed that the lease extension raised an alert instead of passing silently.

Exercises — chapter 33

EX065 — Unsafe control actions. Objective: apply STPA vocabulary. Inputs: the controller action "isolate host". Steps: list one unsafe control action for each of: provided when not needed; not provided when needed; provided too late; applied too long. Give a constraint for each. Expected evidence: four rows. Rubric: 3 = four specific UCAs with constraints; 2 = three; 1 = vague; 0 = none.

EX066 — Breaker parameters. Objective: tune a breaker. Inputs: endpoint API that normally fails 0.5% of calls; during outages 100%; controller sends 10 calls/s. Steps: choose an opening threshold and probe interval; estimate how often the breaker would open falsely under normal conditions if the threshold were 3 consecutive failures. Expected evidence: numbers and choice. Rubric: 3 = P(3 consecutive) ≈ 1.25e-7 per window start → ≈ 0.11 false openings per day at 864,000 calls/day, with justified threshold; 2 = numbers; 1 = attempt; 0 = none.

Chapter synthesis

Decide per action what is safe when dependencies fail: keep applied containment under leases, initiate nothing without policy, keep collecting, break circuits instead of storming, re-check queued actions and keep a logged, tested manual override.

Continue studying — chapter 33 of 50

← Chapter 32 · Course chapter index · Chapter 34 →

Continue to the next authored lesson.