Site reliability engineering applies software-engineering approaches to operating reliable services. The central idea is to define what reliability users need, measure it, and make explicit tradeoffs between feature delivery and reliability work.<\/p>\n
SRE practices make sense only in relation to a service and its users. Define what the service provides, which journeys matter, and who owns operational outcomes.<\/p>\n
Development and operations responsibilities increasingly overlap around service reliability; the DevOps career guide<\/a> shows how that overlap appears in DevOps roles.<\/p>\n A service level indicator is a metric that represents an aspect of service experience, such as successful request rate or latency below a threshold.<\/p>\n Choose indicators users actually experience rather than convenient infrastructure metrics.<\/p>\n A service level objective sets the desired reliability over a period. For example, an API may target a certain percentage of successful requests.<\/p>\n The objective should reflect user needs and business tradeoffs, not an arbitrary pursuit of 100 percent.<\/p>\n The difference between perfect reliability and the SLO creates an error budget. Teams can use it to reason about acceptable risk.<\/p>\n If the budget is being consumed too quickly, reliability work may take priority over aggressive release.<\/p>\n Higher availability may require redundancy, capacity, testing, operational staffing, and more complex architecture.<\/p>\n Dependable cloud services require automation, monitoring, safe change, and recovery; the AWS DevOps Engineer path<\/a> treats those capabilities as one operational engineering discipline.<\/p>\n Toil is repetitive operational work that is manual, predictable, and automatable. SRE aims to reduce toil so engineers can spend more time improving systems.<\/p>\n Repeated operational work is a strong automation candidate because removing toil frees attention for engineering; workflow automation<\/a> reinforces that repeatability principle.<\/p>\n Alert volume, escalation, documentation, and staffing need design. Pages should indicate actionable user impact rather than every small infrastructure anomaly.<\/p>\n A noisy on-call system hides the incidents that matter.<\/p>\n Measure demand, growth, resource saturation, and dependency limits. Keep enough headroom for expected peaks and failure scenarios.<\/p>\n Do not rely on autoscaling without understanding what triggers it and where bottlenecks remain.<\/p>\n Progressive delivery, automated testing, and rollback reduce the impact of bad releases. Observe service indicators during change.<\/p>\n Reliability depends on changing services safely as well as monitoring them; AZ-400 DevOps guide<\/a> connects delivery controls with production operations.<\/p>\n After restoring service, examine detection, blast radius, recovery, contributing conditions, and missing controls.<\/p>\n The goal is system improvement rather than blame.<\/p>\n SRE should not become a team that receives every production problem from developers. Product and platform teams need clear ownership of the services they build.<\/p>\n Architecture and organizational ownership shape whether SRE practices can scale, and the DevOps architect guide<\/a> addresses those broader DevOps design responsibilities.<\/p>\n Before launching, confirm dashboards, alerts, runbooks, capacity, dependencies, access, recovery, and escalation.<\/p>\n When services run on Kubernetes, reliability work includes cluster and workload operations; CKA versus CKAD<\/a> makes those skill boundaries visible.<\/p>\n Security incidents can cause availability failures, and reliability shortcuts can weaken security. Treat identity, secrets, patching, and resilience as connected operational concerns.<\/p>\nSLIs measure user-relevant behavior<\/h2>\n
SLOs define the target<\/h2>\n
Error budgets make tradeoffs visible<\/h2>\n
Reliability has a cost<\/h2>\n
Automation reduces toil<\/h2>\n
On-call should be sustainable<\/h2>\n
Capacity planning supports reliability<\/h2>\n
Change is a major source of risk<\/h2>\n
Incidents generate reliability work<\/h2>\n
Reliability ownership is shared<\/h2>\n
Operational readiness should be explicit<\/h2>\n
Security and reliability interact<\/h2>\n