Modern applications are expected to be available around the clock. Customers expect websites, mobile applications, payment systems, and APIs to function reliably regardless of traffic volume, geographic location, or infrastructure failures.
Consider a typical online shopping platform. During normal business hours, the application serves approximately 10,000 users. On major sale events such as Black Friday, traffic may increase tenfold within minutes. If the application becomes unavailable during this period, the organization risks losing revenue, customer trust, and brand reputation.
Historically, software development and operations teams worked independently. Developers focused on delivering features, while operations teams were responsible for maintaining infrastructure and responding to outages. This separation often created conflicting priorities:
As systems became increasingly complex, traditional operational practices were no longer sufficient. Manual server administration, reactive troubleshooting, and repetitive operational tasks created bottlenecks that prevented organizations from scaling effectively.
To address these challenges, Google introduced Site Reliability Engineering.
Site Reliability Engineering (SRE) is a discipline that applies software engineering principles to operations and infrastructure management. Rather than relying on manual processes, SRE teams use automation, measurement, and engineering practices to build reliable and scalable systems.
Google famously describes SRE as:
What happens when a software engineer is tasked with designing an operations function.
This definition highlights the core philosophy of SRE. Instead of hiring additional operators to manage growth, organizations invest in automation and engineering solutions that eliminate repetitive operational work.
The primary objective of SRE is not simply to keep systems running. The objective is to achieve an appropriate balance between reliability and innovation.
Imagine an e-commerce application hosted on AWS. The architecture consists of:
On a normal day, the platform processes 50,000 transactions but during a promotional campaign, traffic suddenly increases to 500,000 users and several issues begin to appear like,
At this point, the organization faces two options.
An engineer receives an alert and manually investigates the issue. They may:
Although the immediate issue may eventually be resolved, the same problem is likely to occur again under similar conditions.
An SRE team would focus on preventing recurrence. After analyzing the incident, they might implement:
The next time traffic increases, the platform automatically scales to meet demand without requiring human intervention. This shift from reactive operations to engineered reliability is the essence of SRE.
Many organizations mistakenly view reliability as a purely technical concern. In reality, reliability directly affects business outcomes.
Consider a payment platform generating USD 5 lakh per hour. If the platform experiences a one-hour outage:
Revenue Loss = USD 500,000
Customer Impact = Thousands of failed transactions
Reputation Impact = Negative customer perception
Compliance Impact = Potential SLA violationsFor this reason, SRE focuses heavily on measuring and managing reliability. Key questions include:
These questions are answered through concepts such as SLIs, SLOs, and Error Budgets, which are fundamental pillars of SRE. We will cover this in upcoming topics.
Reliability is not a tax on shipping. It’s not something you tack on at the end. It’s part of the product. Your users care about:
All of these are engineering problems, not operations problems. They need to be designed, not prayed for.
Practical implication: When a feature request comes in, SREs ask: “What does this feature cost us in reliability?” not “Can we build this?” They might say no, or they might say “yes, if you add error handling here and monitoring here.”
Toil = manual, repetitive, operationally necessary work that doesn’t have lasting value.
Examples of toil:
Examples of not toil (value-add work):
Practical implication: If you spend more than a few hours a month on toil, you have a problem. The solution is automation, not hiring more people to do the toil faster.
Perfect reliability is impossible. If you try to make a system 100% reliable, you’ll:
So: How much reliability is enough? The answer: Whatever your business needs.
A banking system holding customer money needs different availability than a social media photo feed. But both need to be intentional about their target, not ad-hoc.
We’ll dive deeper into this in Embracing Risk, but the mental model is: Every decision about reliability should be tied to business outcomes.
An SRE is not:
An SRE is:
Common SRE responsibilities:
| Area | What SREs Do |
|---|---|
| Observability | Design monitoring, logging, and tracing strategies; build dashboards and alerts |
| Automation | Write infrastructure-as-code, runbooks, auto-remediation, deployment pipelines |
| Incident Response | Triage and manage incidents; lead post-mortems; improve MTTR (mean time to recovery) |
| Capacity Planning | Forecast growth; prevent resource bottlenecks; right-size infrastructure |
| Testing & Validation | Design chaos tests; validate disaster recovery; stress-test systems |
| Collaboration | Work with product teams to design reliable features; advise on architecture |
All SRE work rests on three pillars:
You can’t improve what you don’t measure. SREs are obsessed with metrics:
Manual work doesn’t scale and is error-prone. SREs automate:
You can’t respond to what you can’t see. SREs build systems where:
Pick a service you maintain or know well (a web API, database, queue system, etc.) and answer below few questions:
These answers form the basis for everything in the rest of this course.