How to become a
site reliability engineer

Site reliability engineering (SRE) treats operations as a software problem. Core practices include defining service level indicators (SLIs) and objectives (SLOs) that reflect user experience; using error budgets to balance reliability with release speed; building monitoring, logging, tracing and alerting; incident management with clear roles; blameless postmortems; reducing toil through automation; capacity planning and load testing; release safety (canaries, rollbacks); and designing for resilience.

Google's SRE book, which popularised the discipline, describes SLOs as target values for a service level measured by an SLI,¹ and argues that 100% reliability is the wrong target because users can't tell the difference beyond a point and the cost is enormous — hence error budgets.² DORA's metrics on time to restore service and change failure rate connect delivery with reliability.³ Reliability failures are costly; IBM's 2026 report shows breach costs rising, and outages carry similar business impact.⁴ In India, AmbitionBox lists SREs at a typical ₹14.8–16.4 lakh, up 14% in two years.⁵

Typical SRE pay in India (AmbitionBox)

₹14.8–16.4 lakh

Two-year rise in SRE pay (AmbitionBox)

14%

Example SLO — about 43 minutes of downtime a month

99.9%

DORA delivery metrics, two tied to reliability

4

Table: How SRE candidates are assessed (editorial summary)

Table: SLOs, error budgets and alerting policy (illustrative)

Table: How SRE developed (editorial summary)

• A service with defined SLIs and SLOs
• Dashboards and burn-rate alerts
• An incident runbook
• A blameless postmortem
• An automation that removed toil
• A verified SRE certificate

Show reliability outcomes: "Introduced SLOs and burn-rate alerts for payments; reduced pages 80% while catching real incidents; postmortem actions cut repeat outages."

"How would you set an SLO?"

Start from user journeys, choose measurable SLIs, look at historical data and agree targets with product.

"What's an error budget policy?"

Agreed actions when budget is spent — such as pausing feature launches to fix reliability.

"How do you reduce alert fatigue?"

Alert on user-facing symptoms and SLO burn, remove noisy alerts and route the rest to tickets.

"Walk me through an incident."

Detect, declare, assign roles, mitigate first, communicate, then investigate and write a postmortem.

"What's toil and how do you reduce it?"

Repetitive manual work; automate, eliminate or redesign it.

• "Are SLOs defined?" — maturity.
• "What's the on-call load?" — sustainability.
• "How are postmortems run?" — culture.
• "What share of time is project work vs ops?" — balance.

Table: Reliability roles and typical pay in India (AmbitionBox, October 2026; indicative)

Table: Common SRE tools (editorial guidance)

• Sysadmin / DevOps — operations foundations.
• SRE — service reliability.
• Senior SRE — complex systems and SLO programmes.
• Staff SRE / platform lead — organisation-wide reliability.
• Head of SRE / infrastructure — strategy.

1. Week 1: Concepts — SLIs, SLOs, error budgets, toil.
2. Week 2: Observe — Run a service with metrics and dashboards.
3. Week 3: Alert and respond — Burn-rate alerts; simulate an incident; write a postmortem.
4. Week 4: Prove it — Automate a task; take the SRE Fundamentals Certification.

Related: Kubernetes, CI/CD and DevOps and Cloud Cost Optimization. Guides: Kubernetes, CI/CD and cloud cost.

• On-call — responding to pages.
• SLO reviews — with product teams.
• Automation — removing toil.
• Postmortems — learning from incidents.
• Capacity — planning for peaks.
• Reliability projects — resilience improvements.

"What's a burn rate?"

How fast the error budget is being used relative to the allowed rate.

"How do you prepare for a festive sale peak?"

Load tests, capacity reservations, change freezes, runbooks and extra on-call.

Table: A first-90-days plan (editorial guidance)

Join on-call and learn where pain lies. Define SLOs for one important service and replace noisy alerts. Then automate a major source of toil — it shows SRE value quickly.

AI tools now summarise incidents, correlate alerts, suggest likely causes and draft postmortems, helping on-call engineers act faster. AI systems also create new reliability challenges: GPU capacity, latency of model calls and unpredictable output quality need their own SLIs. DORA's 2024 research found AI adoption can hurt delivery stability unless fundamentals stay strong. SREs who define good SLOs and verify AI-generated diagnoses are increasingly valuable.

Describe what happened, the impact on users and the timeline. Explain contributing factors in systems and processes, not individual blame. Note what went well, what went poorly and where you got lucky. List specific actions with owners and dates, focusing on prevention and faster detection. Share widely and track actions to completion. Blameless postmortems make people honest about mistakes, which is how organisations get more reliable.

Run a small service on a cloud free tier or local Kubernetes, instrument it with metrics, build a dashboard and define SLOs. Write burn-rate alerts, then break the service — add latency, kill pods, fill disks — and practise responding. Write a postmortem for each exercise. Automate one repetitive task with a script. This project covers most SRE interview topics.

"SRE means aiming for 100% uptime." The goal is the right reliability at the right cost.

"SRE is just on-call." Most time should go to engineering work.

"More alerts mean more safety." Noisy alerts hide real problems.

Alerts should wake someone only when users are affected or soon will be, and when a human needs to act. Alerting on symptoms — elevated error rates, high latency, SLO burn — catches real problems regardless of cause. Alerting on every possible cause, like a single CPU spike, creates noise that trains people to ignore pages. Burn-rate alerts are a powerful approach: they fire when the error budget is being consumed much faster than allowed, with fast-burn alerts for sudden failures and slow-burn alerts for gradual degradation.

Every page should be actionable and link to a runbook explaining what the alert means, how to check impact and first steps to mitigate. Review alerts regularly. If an alert fired and nobody needed to do anything, change or remove it. Track how many pages each on-call shift receives; sustained high numbers burn people out and reduce reliability.

Dashboards complement alerts. Build a top-level view showing SLIs against SLOs for key user journeys, with drill-downs into services. During incidents, responders should be able to see quickly what changed — recent deployments, configuration changes, traffic shifts — because changes cause a large share of incidents.

Indian consumer businesses face sharp peaks around festivals, sales, cricket matches and exam results. Capacity planning starts with forecasts from historical traffic and business plans. Load test critical paths to find limits before users do, and identify bottlenecks such as databases, third-party APIs or rate limits. Pre-scale or reserve capacity where autoscaling is too slow, prepare runbooks, freeze risky changes before the event and staff on-call accordingly. After the peak, compare actual load with forecasts to improve next time.

• SLOs not tied to users.
• Alerting on everything.
• Blame in postmortems.
• No automation.
• Ignoring capacity planning.

SRE practices come from Google's Site Reliability Engineering book; delivery metrics from DORA; cost context from IBM's 2026 report; and India pay from AmbitionBox (read October 2026). The SLO example, postmortem guidance and history are editorial. Science of Apps publishes the free test linked here. Last reviewed October 2026.

• SLI — service level indicator.
• SLO — service level objective.
• Error budget — allowed unreliability.
• Toil — manual, repetitive work.
• Postmortem — a review after an incident.