openskills.info
Open Course

Site Reliability Engineering Fundamentals

Site reliability engineering applies software engineering to operating services. It helps teams set user-centered reliability targets, reduce repetitive operational work, respond to incidents, and improve services through evidence.

itPlatform engineering and SRE

Don't Panic — Site Reliability Engineering Fundamentals

Site reliability engineering, or SRE, is the habit of running a production service with engineering rather than with an ever-growing pile of emergency rituals. Services still fail. Dependencies still wobble. Demand still arrives at the least decorative moment. The useful question is what behavior users need, and how you know it has stopped happening.

The central device is the service level indicator, or SLI: a quantitative measure of a service behavior. An order submission, a request latency, or an error rate can all qualify when they represent a real user journey. The SLI gets a target called an SLO, measured over a window. That target is not a protective charm. It is a statement of which amount of failure is allowed before reliability work must interrupt ordinary change.

This allowance is the error budget. It turns the familiar argument between “ship the change” and “make the service safer” into a decision with evidence. A spent budget does not make user impact disappear, sadly. It makes the cost visible early enough to choose reliability work deliberately, rather than discovering the choice later inside an incident channel.

The surprise is that monitoring is not the whole arrangement. An alert asks somebody to act now. A ticket asks for later work. A log keeps evidence for diagnosis. If every signal becomes an alert, the system has invented a very efficient way to make urgent action indistinguishable from background noise. SRE gives those outputs different jobs.

The rest is an operating loop: scope the service and its risks, set user-centered targets, observe behavior, respond and recover, then learn. Manual, repetitive work that can be automated is toil, and reducing it protects time for improving the service instead of repeatedly rescuing it. A postmortem then records what happened and the follow-up work that changes the system or the practice.

Read the Intro for the full map and glossary. Use Slides when the relationships between SLI, SLO, SLA, and error budget need a compact shape. Keep the Cheatsheet nearby when defining monitoring outputs or an incident flow. The practice reference and exercise turn one user journey into a measurable target and a policy, which is where the respectable nouns become useful.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources