AIOps in Production

What this book helps you do

AIOps becomes useful when a method changes a decision the operations team can observe and review. This book follows the path from trustworthy telemetry to threshold design, incident grouping, capacity planning, graph context, diagnosis, and controlled recovery. It separates a plausible model output from evidence that an on-call team can rely on, and uses a bounded fictional case and local exercises rather than presenting product performance claims.

Problems this book helps you solve

• Adaptive alerts create a new source of noise or hide real incidents.
• Alert grouping merges unrelated failures into one misleading incident.
• Capacity forecasts look precise but fail under a change in demand or deployment.
• A topology graph loses the time and provenance needed for diagnosis.
• A root-cause recommendation outruns the available counterevidence.
• An automated recovery repeats or broadens a change after its authorization expires.

Start with a practical question

Use a focused guide for the immediate problem, then return here when you need the complete operating method.

• When should an alert use an adaptive threshold?
• How do I group alerts without hiding separate incidents?
• When is a capacity forecast safe to use for decisions?
• How should an operational graph represent change and time?
• How do I test an AIOps diagnosis against counterevidence?
• What evidence should an automated recovery require?
• How do I evaluate AIOps before putting it on call?

Decisions you will be able to make

• Choose an alert method against an explicit operational consequence.
• Group or separate alert streams using inspectable incident identity.
• Evaluate forecast error by decision horizon and asymmetric cost.
• Represent topology and change with valid time and observation time.
• Test competing incident hypotheses before recommending action.
• Bind recovery to current authority, state, limits, and a verified effect.

Reading path

1. Chapters 1–2: Scope and data foundationStart with the operational decision and identify the telemetry and ownership needed to support it.
2. Chapters 3–5: Alerts, incidents, and forecastsEvaluate threshold, grouping, and capacity methods against the consequences of errors.
3. Chapters 6–7: Graph context and diagnosisTrack changing relationships and test hypotheses with counterevidence.
4. Chapters 8–10: Bounded decisions and evaluationKeep knowledge, model outputs, reproducibility, and acceptance criteria separate.
5. Chapters 11–12 and laboratory: Recovery and operationConstrain effects, rehearse rollback, and measure the operating system over time.

Begin with the pager decision

A threshold, graph, forecast, or diagnosis is valuable only when it changes a specific operational decision with a known cost of error. The book asks what the team would do differently, which observations support that move, and when the system must abstain.

Keep recovery smaller than the evidence

A suggested action is still only a proposal. Current state, authority, blast radius, execution receipt, and post-change observation must agree before the team describes a recovery as successful. The companion exercises use synthetic data and deliberately leave production identity and distributed guarantees to the reader’s environment.

Evidence and method

The book draws on cited operations and telemetry documentation and uses an original fictional commerce incident and synthetic local exercises. Scenario rates, graph relationships, and outcomes are teaching inputs, not customer measurements. Each alert policy, forecast, and recovery rule requires local calibration and incident review before production use.

Read a sample

Signal Studio does not reproduce manuscript chapters on this site. Open the Amazon listing to use Read Sample or Kindle Instant Preview

Resources

Errata

Report or review an erratum.