Inspect before downloading
See what is inside
These previews come from the published bundle files, so you can judge the method and writing before using it.
Role guide
Site Reliability Engineer (SRE) source-backed Guide
Defines source-backed site reliability engineering, evidence handling, and action boundaries.
Read the fileOverview
Site Reliability Engineer (SRE) overview
Use this bundle to prepare source-backed site reliability engineering analysis and a review-ready service reliability brief.
Read the fileWorkflow
Site Reliability Engineer (SRE) source-backed triage
1. State the requested decision or artifact. 2. Inventory evidence: service, users, critical journeys, owners, and production scope; SLI definitions, data sources, SLO windows, targets, and.
Read the fileTemplate
service reliability brief
Review-ready artifact for site reliability engineering, evidence quality, verification, and controlled next actions.
Read the fileIs this bundle right for your task?
Who it is for
- SREs, platform and DevOps teams, engineering leads, and service owners preparing reliability decisions or operational reviews
When to use it
- A team needs to define or review SLIs, SLO windows, targets, and an error-budget policy against actual service and user-journey evidence.
- Incidents, alerts, capacity concerns, or recent changes need to be reconciled before recommending reliability work.
- A proposed deployment or operational change needs alternatives, stop conditions, rollback evidence, and an accountable approval boundary.
What you need to provide
- Service scope, owners, users, critical journeys, architecture, dependencies, failure modes, and recent change history.
- SLI definitions and data sources, SLO targets and windows, error-budget policy, monitoring, alerts, incidents, runbooks, postmortems, capacity, deployment, access, and rollback evidence.
Tasks and expected outputs
Questions it helps answer
- Prepare a service reliability brief without fabricating local facts.
- Separate verified, provided, assumed, and missing evidence.
- Produce a review-ready recommendation with explicit verification and approval boundaries.
What it helps produce
- service reliability brief
Practical example
Use it with an agent
Load the bundle as context, provide the evidence named above, then adapt this example to your situation.
Load the Site Reliability Engineer bundle and provide the service map, SLI queries, SLO and error-budget definitions, recent incident and change records, alert evidence, capacity data, and rollback plan. Ask the agent to label evidence status, reconcile conflicting periods or definitions, and draft a service reliability brief with alternatives, stop conditions, verification steps, and actions requiring approval.
Context path: bundles/roles/site-reliability-engineer-sre
What the bundle includes
Frameworks
- source-evidence matrix
- site reliability engineering review matrix
- qualified-review gate
Evaluations
- Site Reliability Engineer (SRE) source verification check
Sources used to build this bundle
These are the public references behind the role definition and operating guidance. The bundle does not replace current documentation or evidence from your site.
Limitations and safe use
Do not use this for
- Asserting service health, SLO attainment, error-budget consumption, incident cause, or capacity without inspected evidence; deploying releases, changing production or alerts, using credentials, or issuing incident communications without explicit approval.
Known limitations
- Use the cited official, originator, standards, or professional sources for general site reliability engineering context; local facts, records, values, states, and permissions require inspected evidence.
- Task-specific work requires current evidence for service, users, critical journeys, owners, and production scope; SLI definitions, data sources, SLO windows, targets, and error-budget policy; architecture, dependencies, failure modes, and change history; monitoring, alerts, incidents, runbooks, postmortems, capacity, access, deployment, and rollback evidence.
- Do not infer service health, SLI validity, SLO attainment, error-budget consumption, incident cause, capacity, or production state.
Safety notes
- Minimize personal, customer, employee, financial, credential, security, privileged, and other sensitive data.
- Require explicit confirmation before changing production, deploying releases, modifying alerts or access, using credentials, or issuing incident communications.
- Route legal, privacy, security, compliance, financial, employment, safety, and other qualified judgments to an evidenced accountable reviewer.