Enhancing Digital Platforms with SRE

Begin with measurement — you cannot set an objective for something you do not monitor.

Reliability as a product feature

In the age of digital services, reliability is not a background concern. Organisations like Amazon handle millions of transactions around the clock, where a momentary failure costs an amount that justifies almost any preventative spend.

Most organisations are not Amazon, but the principle scales down. If your service is how customers transact with you, its availability is part of the product, not part of the infrastructure budget.

In the age of digital services, reliability is not a background concern.

Where SRE came from

Site Reliability Engineering originated at Google, from a deceptively simple proposition: treat operations as a software problem.

Rather than scaling a service by adding people to run it, SRE applies engineering to the operational work itself — automating it, measuring it, and holding it to explicit reliability targets. That is the whole idea, and everything else follows from it.

What SRE teams actually do

• Define reliability numerically — service level objectives, and an error budget derived from them
• Automate toil, the manual repetitive work that scales with traffic
• Own monitoring and observability, so failures are seen before customers report them
• Run incident response, including blameless post-incident review
• Gatekeep on evidence: when the error budget is spent, the priority becomes stability rather than features

The error budget is the mechanism that makes SRE more than a job title. It converts "should we ship this or stabilise?" from an argument into a calculation.

What to actually monitor

Monitoring everything is the same as monitoring nothing — too much signal buries the alert that matters. The four measures worth building dashboards around are latency (how long a request takes), traffic (how much demand the service is under), errors (the rate of requests failing), and saturation (how close a resource is to its limit). Between them, they tend to catch a failing service well before a customer notices, which is the entire point of watching in the first place.

How teams are organised

There are two workable models. An embedded SRE sits within a product team and shares its priorities. A central SRE team builds the platform, tooling and standards that product teams use.

Larger organisations generally end up with both, and the failure mode is the same in either: an SRE team that becomes the operations department under a new name, absorbing all the toil instead of engineering it away.

Starting an SRE journey

Begin with measurement — you cannot set an objective for something you do not monitor. Then set one SLO on one important service and let the organisation experience what it means to hold to it.

From there, attack toil in order of how much time it consumes, and establish blameless post-incident reviews early. Both are cultural changes as much as technical ones, and both are much harder to introduce once the team is firefighting full time.