Ask a Fortune 500 IT director how they run change management, and you’ll hear about ITIL: Change Advisory Boards, service catalogs, CMDBs, weekly release windows. Ask an SRE at AWS, Azure, GCP, or OCI the same question, and you’ll get a puzzled look.
The big clouds don’t run ITIL. Not because ITIL is wrong. Because ITIL was designed for a world that doesn’t exist at hyperscaler scale.
ITIL was written for a few thousand internal customers who could wait. Hyperscaler operations are written for millions of external customers who can’t.
Five assumptions ITIL makes that break at scale
1. Change Advisory Boards
ITIL puts a weekly (sometimes daily) human meeting between an engineer and production. That works when you ship 10 changes a week. At a hyperscaler, teams push thousands of changes per day. A CAB with human review is a bottleneck the size of your business.
Instead: automated approval based on tests passing, canary metrics staying green, and feature flags rolling gradually. The board is a machine.
2. Single production instance
ITIL assumes one production system that a change either goes into or doesn’t. Hyperscalers run cell-based, region-based, availability-zone-based deployments. A change goes to one cell, waits for the canary window to prove safe, then propagates. Blast radius is a first-class concept ITIL doesn’t have.
3. Dev throws to Ops
ITIL comes from a world where developers wrote code and handed it to an operations team to run. Hyperscalers run “you build it, you run it.” The person on-call for the service is the person who wrote it. Different incentive, different quality bar.
4. Documentation-first process
ITIL wants every service in a service catalog with a signed SLA, in a CMDB, with a formal Configuration Item entry. Hyperscalers replace the CMDB with infrastructure as code (Terraform, Bicep, Pulumi). The truth is the repository with code, not the document.
5. Weekly release windows
ITIL treats “release” as a rare, ceremonial event. Hyperscalers release continuously. Deploying at 3 pm on a Friday to production is not a career-ending move. It’s a Tuesday.
What they use instead
The Google SRE model. Error budgets that let you spend reliability on speed. Blameless postmortems (AWS calls it Correction of Error). SLOs derived from customer contracts. On-call rotations owned by the service team. Runbooks in the same repo as the code.
What still transfers
Some ITIL habits earned their keep. Severity levels (SEV1-4). Postmortems. Explicit incident commander roles during a big outage. Runbooks. Change tracking (automated, not manual). These show up at every hyperscaler, just called something else.
ITIL didn’t fail. It was designed for a different problem.
If you’re running a small internal IT shop, ITIL is probably still the right frame. If you’re building for external customers at scale, the Google SRE book (and every hyperscaler’s private version of it) is the frame that actually fits.