Nodea — logo

SRE (Site Reliability Engineering)

SRE (Site Reliability Engineering) is a discipline combining software engineering with system administration, aimed at building and maintaining reliable, scalable services. The concept was developed by Google, which formulated the principle: treat operations like an engineering problem — measurable, automatable and solvable with code.

What SRE is about

SRE replaces intuitive "server maintenance" with a data-driven approach based on clear goals. The key concepts are:

  • SLI (Service Level Indicator) — a measurable metric, such as the share of successful requests or response time,
  • SLO (Service Level Objective) — the target value of an indicator, for example 99.9% availability,
  • error budget — the acceptable margin of downtime, which helps balance release velocity against stability,
  • toil — repetitive manual operational work that SRE strives to automate.

The foundation of the work is observability — collecting metrics, logs and traces so the team can quickly detect and diagnose problems before users feel them.

SRE in practice

The SRE approach is used by companies running online services for which high availability and predictable performance matter — SaaS platforms, stores, payment systems and cloud infrastructure. SRE engineers build deployment automation, alerting systems, incident response procedures and self-healing mechanisms. In practice their work is closely tied to DevOps and to disaster recovery planning described by RTO and RPO parameters — all so a service stays stable despite growing traffic and inevitable failures.

Powiązane pojęcia

Najczęstsze pytania

How is SRE different from DevOps?

DevOps is a broad philosophy of collaboration between development and operations. SRE is a concrete implementation of that idea created by Google, introducing measurable indicators (SLIs, SLOs), an error budget and treating reliability as engineering with measurement. You could say SRE is DevOps with hard metrics.

What is an error budget?

An error budget is the acceptable margin of downtime derived from the chosen SLO — for example, at 99.9% availability that is about 43 minutes of downtime per month. While the budget is not exhausted, the team can ship changes more boldly; when it runs out, stabilization becomes the priority.