SAF and Site Reliability Engineering
Nature and status of the approach
Site Reliability Engineering (SRE) is an engineering practice, a set of principles, and a professional role for reliable operation of production systems. This study uses the open Google SRE body of knowledge as of August 3, 2026. SRE is not a conformity standard, a complete ITSM model, or an architectural metamodel.
Purpose and audience
SRE helps balance the speed of change with service reliability, apply software engineering to operations, and make decisions using observable measures. Its audience includes product and service owners, developers, SRE and operations teams, incident responders, and engineering leaders.
Management scope and unit
The main subject is user-perceived service reliability and the production systems that provide it. Service-level indicators and objectives, error budgets, monitoring, incident and change management, capacity, and toil are important. These concepts complement SAF but do not automatically create new architectural types.
Concepts and SAF mappings
| SRE | Nearest concept in SAF | Type / confidence | Boundary |
|---|---|---|---|
| Service | Service and supporting Systems | Composite / medium | SRE often starts with a technical or digital service. |
| User journey / critical user action | Actor, Channel, Service, and Process | Composite / medium | A journey is a view over SAF objects. |
| SLI, SLO, error budget | External measures and service policy | Not applicable / high | A measure is outside the 13 core types. |
| Production system | System, Components, Deployments, and resources | Composite / high | SRE uses the actual operational projection. |
| SRE team, on-call, service owner | Actors with roles | Partial / high | Schedules and escalation remain outside SAF. |
| Incident, postmortem, toil item | Operational record or management artifact | Not applicable / high | A record refers to SAF but does not become an architectural object. |
Relationships
An SLO is set for observable service behavior; an SLI measures that behavior; an error budget guides the balance between reliability and change. Events and incidents affect the service and production configuration. SAF traces the impact further to an Actor, Process, Capability, System, Components, Deployments, and resources.
Lifecycle and organization of work
SRE work includes reliability design, readiness, observation, response, recovery, post-incident learning, and toil reduction. This is a continuous engineering cycle. SAF is updated when a finding changes an architectural constraint, dependency, target deployment, or ownership; postmortems and alert history remain in external systems.
Roles and governance
SRE relies on shared development and operations responsibility, explicit service ownership, on-call duties, and escalation mechanisms. The “Actor owns object” relationship provides an architectural accountability point but does not replace an operational readiness review, on-call rotation, or incident-command procedure.
Measures, maturity, and adaptation
SLIs and SLOs should reflect a user outcome, not only the health of one server. SAF maturity levels describe model quality, not SRE maturity. A startup may need only a few critical SLOs; an enterprise may govern objectives, dependencies, error budgets, and evidence in a federated way.
Using the approaches together
A SAF Service becomes the stable attachment point for an SLO. The observed System and Deployment are mapped to telemetry resource labels, an incident refers to the Service and affected CIs, and a postmortem finding may create an architecture decision. Operational feedback then improves SAF without copying telemetry into the model.
Mapping limitations
Google SRE describes experience and practices, not a universal organizational design. SRE implementations vary, and the public body of knowledge evolves. This page does not claim that having an SLO or an on-call rotation constitutes SRE adoption, and it does not replace local reliability design.