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.
Framework guide
Site Reliability Engineering source-backed Guide
Defines source-backed service, SLI, SLO, error budget, toil, alerting, incident, postmortem, capacity, and reliability decision review, evidence handling, and action boundaries.
Read the fileOverview
Site Reliability Engineering Overview
source-backed framework bundle for service, SLI, SLO, error budget, toil, alerting, incident, postmortem, capacity, and reliability decision review, evidence reconciliation, reviewable decisions, and controlled.
Read the fileWorkflow
Site Reliability Engineering source-backed Triage
1. State the decision and direct answer possible now. 2. Record Verified, Provided, Assumed, and Needs verification separately. 3.
Read the fileTemplate
Site Reliability Engineering review brief
Review-ready artifact for service, SLI, SLO, error budget, toil, alerting, incident, postmortem, capacity, and reliability decision review.
Read the fileIs this bundle right for your task?
Who it is for
- Practitioners using Site Reliability Engineering to structure analysis, decisions, facilitation, or review
- Teams working in Technology, Business operations
When to use it
- A team needs to apply Site Reliability Engineering to a concrete decision without skipping evidence, constraints, or stakeholder judgment.
- An existing analysis needs its assumptions, reasoning, affected parties, and review criteria checked.
What you need to provide
- The decision or question, available evidence, operating constraints, affected stakeholders, and desired outcome.
- Existing analysis, definitions, assumptions, examples, and review criteria that the framework must reconcile.
Tasks and expected outputs
Questions it helps answer
- Prepare a site reliability engineering review brief without fabricating local facts.
- Separate verified, provided, assumed, and missing evidence.
- Produce a review-ready decision with explicit verification and approval boundaries.
What it helps produce
- Site Reliability Engineering review 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.
Provide the decision or question, available evidence, operating constraints, affected stakeholders, and desired outcome. Ask the agent to apply Site Reliability Engineering and produce Site Reliability Engineering review brief that shows how evidence maps to the framework, where judgment is required, and what remains unresolved. Begin with sre.google — Sre Book, then confirm that the reference is current and applicable. Inspect Site Reliability Engineering source-backed Guide before drafting.
Context path: bundles/frameworks/site-reliability-engineering
What the bundle includes
Frameworks
- Site Reliability Engineering
- source-evidence matrix
- qualified-review gate
Evaluations
- Site Reliability Engineering 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
- Applying the framework mechanically when the decision requires missing evidence, stakeholder judgment, or qualified review.
Known limitations
- Use the listed authoritative or identified source surfaces for general Site Reliability Engineering guidance; local facts, records, values, states, permissions, and results require inspected evidence.
- Task-specific work requires current evidence for service and user journey, owners and dependencies, SLI event and measurement specification, SLO target and window, exclusions, source telemetry and quality, error-budget calculation and policy, alert rules, incident and postmortem evidence, toil measure, capacity and change history, risks, approvals, and rollback.
- Do not infer service health, SLI or SLO value, budget consumption, alert validity, incident cause, toil, capacity, or release safety.
Safety notes
- Minimize personal, customer, employee, financial, credential, security, privileged, health, student, and other sensitive data.
- Require explicit confirmation before actions that change SLOs, error-budget policy, alerts, on-call or incident state, production configuration, capacity, release pace, or customer communications; deploy or roll back changes.
- Route legal, privacy, security, compliance, financial, employment, clinical, safety, and other qualified judgments to an evidenced accountable reviewer.