Site Reliability Engineer

SLIs, SLOs & SLAs

Why: You set a realistic SLO from real user data and agree it with the product owner, so the target reflects what users tolerate and not an arbitrary number of nines.

Error Budgets

Why: You track budget burn and apply the policy, so when the budget runs out the team pauses risky releases instead of arguing about whether to continue.

Metrics Collection

Why: You control cardinality and naming across services, so a dashboard query stays fast and an alert can be trusted during a real incident.

Logging & Aggregation

Why: You derive metrics from logs and set retention with compliance in mind, so you can alert on an error pattern while keeping storage cost and legal limits in check.

Incident Response

Why: You classify severity, assign roles and mitigate before diagnosing fully, so a customer-facing outage is contained in minutes rather than debated by ten people.

Incident Communication

Why: You update the status page and stakeholders with clear impact and next update times, so customers and executives are informed without interrupting the responders.

Capacity Planning

Why: You forecast demand and find the bottleneck before a launch, so you can request headroom ahead of a traffic peak instead of scaling during it.

Load Testing & Performance

Why: You run load and soak tests with a tool such as k6 and read the results, so a memory leak or slow query shows up in a test and not on release day.

Infrastructure as Code

Why: You describe infrastructure in code with versioned state, so an environment can be rebuilt after a failure and changes are reviewed like application code.

CI/CD Pipelines

Why: You use canary or blue-green rollout with a tested rollback, so a bad release is reverted automatically before it affects most users.