Chapter 8 described the change pipeline when much of the change is authored by agents: provenance, review, policy gates and the change record. This chapter concerns what happens after a change has passed those gates and meets production. It concerns O3 Change, because a change is safe only when its exposure is limited and measured while it spreads, and O4 Restore, because the way back (the rollback, the stop and the freeze) is the part of a change that is used when something has already gone wrong. The two functions meet at one design question: how far may a change reach before something other than the change itself has confirmed that it works?
The chapter builds on conclusions of the earlier volumes: stop decisions are named in advance and need no approval (AI Governance, Chapter 13), the stop path runs outside the system it stops (AI Platform and Security, Chapter 19; AI Purple, Chapter 6), chaos experiments keep a bounded blast radius and an independent abort (AI Red Team, Chapter 25), and a stop in good faith is never a failure (AI Threat, Chapter 30). Chapter 4 supplies the frame: the autonomy budget, the observer principle and the Level 4 prohibitions.
The oldest observation in site reliability engineering is that production is mostly stable until someone changes it. The introductory chapter of Google's Site Reliability Engineering states that SRE "has found that roughly 70% of outages are due to changes in a live system", and prescribes three practices that follow from it: roll changes out gradually, detect problems quickly and accurately, and revert safely (245, Treynor Sloss, 2017). The sentence reports one organisation's experience. It gives no sample, no period and no definition of "outage", so it supports an order of magnitude and a design direction, not a benchmark for any other estate.
Primary topics explored
- Why most incidents follow a change
- Progressive delivery
- Configuration as the dangerous change
- Stop conditions and automatic rollback
- Freezes
- Blast-radius budgets
About AI Operations
AI Operations is Book 10 of The Transformed Architecture. It takes IT operations as its subject and asks what happens when AI takes part in it: the five operations functions (observe, diagnose, change, restore, sustain), the autonomy budget and the Level 4 prohibitions, the observer principle, resilience as a claim that needs evidence, operating AI systems, the operator's own AI as Tier 0 and how to defend it, operating models, decision rights, regulation (DORA, NIS 2, the AI Act), and the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue and AI Purple.
CIOs and heads of IT operations, SRE and platform leads, incident commanders and on-call engineers, service-desk and service-management leads, FinOps and capacity managers, architects, CISOs and heads of resilience and third-party risk, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 9: Change Safely: Progressive Delivery, Freezes and Blast Radius in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Craft” and is one of 35 drawn from the manuscript.