SRE
205 bites tagged SRE — interview questions with model answers, and 60-second explainers.
Error Budgets: Balancing Reliability and Innovation
An error budget is your service's allowance for unreliability, calculated as 1 minus the SLO. It provides a data-driven signal for when to halt new feature releases and focus on stability, protecting users from repeated SLO misses.
Service Level Indicators: Measuring What Matters
An SLI is a direct measurement of your service's performance, like request latency or error rate. It's the raw data that forms the basis for reliability goals (SLOs). The main footgun is measuring system internals instead of the actual user experience.
Embracing Risk: Reliability Is a Budget, Not a Goal
Instead of chasing 100% uptime, SRE treats reliability as a budget. The acceptable downtime, or 'error budget,' is permission to take calculated risks like shipping features faster. The footgun is wasting resources on reliability users won't even notice.
Toil: The Repetitive Work That Kills Engineering Velocity
Toil is manual, repetitive work that scales with your service, stealing time from real engineering. It's the operational treadmill of handling the same alerts or manually running scripts.
Site Reliability Engineering (SRE): Ops as a Software Problem
Site Reliability Engineering (SRE) treats operations as a software problem, using engineering to automate and scale system management. It's crucial for massive services like Google Search, ensuring availability, latency, and capacity.
Prometheus Alertmanager: Taming Your Alert Storms
Alertmanager is the traffic controller for your Prometheus alerts, turning a potential flood into actionable notifications. It groups, deduplicates, and routes alerts to services like PagerDuty. The footgun: don't load balance traffic to an HA cluster.
Cloud Disaster Recovery: Planning for Failure
Cloud DR isn't about backups; it's a business continuity plan defining acceptable downtime (RTO) and data loss (RPO). It's for when a whole region fails or a bad deploy corrupts data. The footgun is having a plan but never testing it, creating false security.
SLIs & SLOs: Measuring What Matters for Service Reliability
SLIs are what you measure (e.g., latency); SLOs are the target you aim for (e.g., 99% success). They replace vague feelings about service health with concrete numbers. This is how SREs define and manage reliability.
Chaos Engineering: Break Systems to Build Confidence
Chaos Engineering is like a fire drill for your software: you intentionally break things in a controlled way to find weaknesses. It's used in distributed systems to test resilience against server failures or network latency.
Synthetic Monitoring: Probing Your App Like a Robot User
Synthetic monitoring is like having a robot user click through your app's critical paths 24/7 to catch issues before real users do. It tests key flows like login or checkout, providing a consistent baseline for performance.
Service Level Objective (SLO): A Measurable Promise
An SLO is a precise, measurable promise about your service's performance, like "99.9% of requests will succeed." It's the internal engineering target that backs up a customer-facing SLA. The footgun is setting a 100% SLO, which leaves no room for failure.
Observability: Seeing Inside Your System
Observability is the ability to ask new questions about your system's health without shipping new code. It's crucial for debugging distributed systems and is the first step in triaging an outage.
Kubernetes Operators: SREs in a Box
Think of an Operator as an automated site reliability engineer for your app, encoding human knowledge into software. It's used to manage complex stateful applications like databases, automating tasks like backups and upgrades.
Get SRE bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.