Chapter 01 — Calculus I | Engineering Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 01 published. Map, example, EX001.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["1.1 Why an engineer of response systems needs rates"]
  N2["1.2 Derivative, rate and sensitivity"]
  N3["1.4 Where a derivative misleads"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX001"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["1.1 Why an engineer of response systems needs rates"]
  N2["1.2 Derivative, rate and sensitivity"]
  N3["1.4 Where a derivative misleads"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX001"]

[Learning outcomes and connection]
    |
    v
[1.1 Why an engineer of response systems needs rates]
    |
    v
[1.2 Derivative, rate and sensitivity]
    |
    v
[1.4 Where a derivative misleads]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX001]

Learning outcomes and connection

After this chapter you can (1) describe an incident queue as functions of time with explicit units; (2) use the derivative of the backlog to tell whether a response service is gaining or losing ground; (3) compute the sensitivity of a recovery estimate to its inputs; and (4) say where a smooth derivative misrepresents a queue of discrete cases. It prepares Chapter 6 (accumulation), Chapter 32 (reliability) and Chapter 36 (pipeline capacity).

1.1 Why an engineer of response systems needs rates

A response service is a machine that turns arriving work — alerts, reports, cases — into decisions. Whether it keeps up is a question about rates. Let $\lambda(t)$ be the arrival rate in cases per hour and $\mu$ the rate at which the team can close cases. If $Q(t)$ is the backlog, then, treated as a continuous quantity,

$$\frac{dQ}{dt} = \lambda(t) - \mu \quad \text{while } Q > 0,$$

and $dQ/dt = \max(0, \lambda - \mu)$ when the queue is empty. The sign of the derivative is the most important operational fact: positive means the backlog grows no matter how hard people work at the current capacity. Units keep you honest: $\lambda$ and $\mu$ are cases/hour, so $dQ/dt$ is cases/hour and $Q$ is cases. A design document that mixes "alerts per day" with "analyst hours" without a conversion is already wrong.

1.2 Derivative, rate and sensitivity

The derivative $f'(t)$ is the instantaneous rate of change; on a sampled series you estimate it with a difference quotient $(f(t+h)-f(t))/h$. A sensitivity is a derivative with respect to a parameter instead of time. If the time to drain a backlog $Q_0$ at net rate $\mu - \lambda$ is $T = Q_0/(\mu - \lambda)$, then

$$\frac{\partial T}{\partial \mu} = -\frac{Q_0}{(\mu-\lambda)^2}.$$

The square in the denominator is the engineering message: when capacity is only slightly above demand, a small loss of capacity — one analyst off sick — multiplies recovery time. Queueing theory reaches the same conclusion for waiting times as utilisation approaches one; Little (1961) gives the identity $L = \lambda W$ relating average number in system, arrival rate and time in system that we use in Chapter 36.

1.3 Worked example (synthetic): an outage surge at Harrow Valley Shared Services

Harrow Valley Shared Services (HVSS) is a synthetic public-service organisation used throughout this book. Its response desk closes $\mu = 12$ cases/h. Normal arrivals follow a daily cycle, $8 + 3\sin(2\pi t/24)$ cases/h. A service outage from $t = 2$ h to $t = 6$ h adds 14 cases/h of user reports and alerts. Lab 1 integrates the backlog in steps of 0.1 h.

"""Lab 1 (synthetic): incident-queue backlog during an outage. Euler integration, step 0.1 h."""
import math
MU = 12.0                      # analyst capacity, cases/hour (synthetic)
def lam(t):                    # arrival rate, cases/hour; outage surge 2 h..6 h
    base = 8 + 3 * math.sin(2 * math.pi * t / 24)
    return base + (14 if 2 <= t < 6 else 0)
dt, q, t, peak, peak_t, wait_area = 0.1, 0.0, 0.0, 0.0, 0.0, 0.0
rows = []
while t < 12 - 1e-9:
    dq = lam(t) - MU
    q = max(0.0, q + dq * dt)
    wait_area += q * dt
    t = round(t + dt, 10)
    if q > peak: peak, peak_t = q, t
    if abs(t - round(t)) < 1e-9 and int(round(t)) % 2 == 0:
        rows.append((int(round(t)), lam(t - dt), q))
for h, l, b in rows:
    print(f"t={h:2d}h  lambda={l:5.2f}/h  backlog={b:6.2f}")
print(f"peak backlog {peak:.2f} cases at t={peak_t:.1f}h")
print(f"case-hours waiting (area under backlog) {wait_area:.1f}")
print(f"derivative of backlog at t=3h: {lam(3)-MU:.2f} cases/h")

Expected output:

t= 2h  lambda= 9.43/h  backlog=  0.00
t= 4h  lambda=24.56/h  backlog= 24.14
t= 6h  lambda=25.00/h  backlog= 49.85
t= 8h  lambda=10.64/h  backlog= 47.60
t=10h  lambda= 9.57/h  backlog= 43.85
t=12h  lambda= 8.08/h  backlog= 37.46
peak backlog 49.85 cases at t=6.0h
case-hours waiting (area under backlog) 370.7
derivative of backlog at t=3h: 12.12 cases/h

Read it as an engineer. At $t = 3$ h the backlog grows at about 12 cases per hour: during the surge, every hour adds roughly an hour of work. After the surge ends at 6 h, arrivals fall but stay near 9–11 cases/h, so the net drain rate is only 1–4 cases/h; twelve hours after the outage began, 37 cases are still waiting. The 371 case-hours of waiting is the accumulated delay that Chapter 6 teaches you to compute by integration.

1.4 Where a derivative misleads

Cases are discrete, arrive in bursts and are not interchangeable: one ransomware case may consume more effort than forty phishing reports. The continuous model also ignores that people triage, merge duplicates and defer low-severity work — so the model overstates the backlog of important work and understates the backlog of trivial work. A difference quotient on noisy hourly counts amplifies noise; smooth before you differentiate, and report the window used. Finally, $\mu$ is not constant: fatigue, handovers and context switching reduce it exactly when the surge is worst.

1.5 Common errors and limits

Mixing units (per day vs per hour) in the same equation.
Treating capacity as fixed during a long incident.
Reporting a single "time to clear" without its sensitivity to capacity.
Differentiating raw counts without smoothing or stating the step size.

Each error shows up in the HVSS surge of Lab 1. A planner who reads 12 cases/h as 288 per day and compares it with an hourly outage peak of 25 arrivals will mistake a twelve-hour backlog for a momentary blip. The 37 cases still waiting at t = 12 h assume that all twelve hours of capacity were delivered, which tired analysts on a long shift rarely achieve. Quote that figure with its sensitivity to capacity, and state the 0.1 h step the lab used.

Exercises — chapter 01

EX001 — Drain time sensitivity. Objective: quantify how fragile a recovery estimate is. Inputs: backlog $Q_0 = 50$ cases, arrivals $\lambda = 10$ cases/h, capacity $\mu = 12$ cases/h. Steps: compute $T$; compute $\partial T/\partial \mu$; estimate $T$ if one of six analysts is lost (capacity falls proportionally). Expected evidence: three numbers with units and one sentence of interpretation. Rubric: 3 = all correct with interpretation; 2 = one error; 1 = formula only; 0 = none.

EX002 — Reading Lab 1. Objective: connect the model to a staffing decision. Inputs: Lab 1. Steps: change the outage surge to 7 h duration (2–9 h) in the code and record the peak backlog and its time; state one reason the real peak would differ. Expected evidence: modified line, two numbers, one limitation. Rubric: 3 = correct run and a substantive limitation; 2 = run only; 1 = attempt; 0 = none.

Chapter synthesis

The backlog derivative $\lambda - \mu$ tells you whether a response service is winning. Sensitivities show how close-to-capacity operation turns small losses into long delays. Use the continuous model to reason, then check its assumptions against the discrete, bursty and uneven reality of cases.