SRE is often dismissed as "Google-scale thinking" irrelevant to startups. That's wrong. The practices themselves are universally applicable — you just apply them proportionally to your scale and team size.
Start with SLOs
A Service Level Objective is a reliability target: "99.9% of homepage requests complete in under 2 seconds." It seems simple — but defining it forces important conversations. What does "available" mean for your service? What do users actually notice? What can you realistically achieve with your current infrastructure?
Start with three SLOs: availability, latency at p95, and error rate. Track them in Grafana. Review them monthly. Adjust when you learn something new.
Error budgets make the trade-off explicit
A 99.9% availability SLO gives you 43 minutes of downtime per month as your error budget. When you're shipping features, you're spending error budget. When you're working on reliability, you're restoring it. The error budget makes the engineering trade-off between velocity and reliability visible and negotiable.
When you've burned your error budget for the month, stop shipping new features and fix reliability. When you have budget to spare, ship faster. This is much healthier than the "we need more uptime" vs "we need more features" argument that never resolves.
Blameless postmortems
When something breaks, write a postmortem within 48 hours. Describe the timeline. Identify contributing factors (plural — incidents always have multiple causes). Define action items with owners and deadlines. Publish it internally. Never name individuals as causes — the system allowed the error to happen, and the system needs to be fixed.
Psychological safety around incidents determines whether your team surfaces problems early or hides them. Blame creates the latter.
On-call runbooks
Every alert that fires should have a runbook — a step-by-step guide for the on-call engineer to diagnose and resolve the issue. "High error rate" should link to: check the logs, check these dashboard panels, try these commands, escalate if X. Runbooks reduce mean time to resolution dramatically, especially for engineers new to on-call.
Toil reduction
Toil is manual, repetitive work that scales with traffic but provides no lasting value. Provisioning servers manually, rotating logs, manually approving deploys. SRE practice says: if a task is toil, automate it or eliminate it. Track toil as a percentage of engineering time. Keep it under 50%. Every hour spent on toil is an hour not spent on the reliability improvements that reduce future toil.