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 | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
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
- https://sre.google/sre-book/introduction/
Supports
- SRE as software engineering applied to service operations
- Error budgets, monitoring outputs, engineering focus, and change management
- https://sre.google/sre-book/service-level-objectives/
Supports
- Definitions and use of SLIs, SLOs, SLAs, and error budgets
- User-centered service measurements including latency, errors, throughput, and availability
- https://sre.google/sre-book/eliminating-toil/
Supports
- Definition of toil and the role of automation in reducing recurring operational work
- https://sre.google/workbook/incident-response/
Supports
- Incident-response procedures and coordinated mitigation
- https://sre.google/workbook/postmortem-culture/
Supports
- Blameless postmortem culture and follow-up actions
- https://github.com/dastergon/awesome-sre
Supports
- Discovery of the Availability Calculator and the postmortem collection
- https://dastergon.github.io/availability-calculator/
Supports
- Availability target calculations expressed as permitted downtime
- https://github.com/danluu/post-mortems
Supports
- Curated collection of incident postmortems
- https://sre.google/workbook/error-budget-policy/
Supports
- Error-budget policy examples and the effect of miscategorized errors
- https://dropbox.tech/infrastructure/lessons-learned-in-incident-management
Supports
- Practitioner lessons on incident coordination, responder distraction, and blameless review
- https://engineering.atspotify.com/2022/05/failing-forward-how-we-grow-from-incidents
Supports
- Incident-review findings on recovery-time measurement and synthetic-test coverage
- https://prometheus.io/docs/introduction/overview/
Supports
- Prometheus as an open-source monitoring and alerting toolkit
- https://grafana.com/oss/
Supports
- Grafana OSS as open-source visualization and dashboarding software
- https://opentelemetry.io/docs/
Supports
- OpenTelemetry as a vendor-neutral open-source telemetry framework
- https://www.datadoghq.com/pricing/
Supports
- Datadog free and paid observability plan availability
- https://newrelic.com/pricing
Supports
- New Relic free tier and usage-based observability pricing
- https://support.pagerduty.com/main/docs/incidents
Supports
- PagerDuty incident assignment, escalation, acknowledgement, and resolution workflow
- https://www.pagerduty.com/faq/
Supports
- PagerDuty trial and paid-subscription availability
