Site Reliability Engineer

# Objectives and error budgets ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Turn SLOs into release and prioritization decisions. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools SLOs, policy ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[SLOs] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Objectives and error budgets
TOOLS: SLOs, policy

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Monitoring that matters ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Separate symptoms from causes and build dashboards operators can trust. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Grafana, Prometheus ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[Grafana] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Monitoring that matters
TOOLS: Grafana, Prometheus

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Logging and correlation ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Structure logs, propagate request IDs, and avoid sensitive data leakage. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools OpenTelemetry, JSON logs ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[OpenTelemetry] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Logging and correlation
TOOLS: OpenTelemetry, JSON logs

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Distributed tracing ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Follow a request across services and identify latency and failure boundaries. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools OpenTelemetry, Jaeger ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[OpenTelemetry] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Distributed tracing
TOOLS: OpenTelemetry, Jaeger

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Blameless postmortems ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Write timelines, contributing factors, actions, owners, and learning. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Postmortems ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[Postmortems] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Blameless postmortems
TOOLS: Postmortems

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Toil measurement ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Identify repetitive manual work and automate it with measurable outcomes. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Python, Bash ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[Python] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Toil measurement
TOOLS: Python, Bash

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Capacity planning ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Model demand, saturation, headroom, growth, and scaling lead time. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Load testing, forecasting ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[Load testing] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Capacity planning
TOOLS: Load testing, forecasting

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Load testing ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Create realistic traffic, define thresholds, and interpret results safely. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools k6, Grafana ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[k6] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Load testing
TOOLS: k6, Grafana

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# High availability ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Use redundancy, health checks, graceful degradation, and controlled failover. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools AWS, ALB ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[AWS] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: High availability
TOOLS: AWS, ALB

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Change management ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Reduce change risk with small releases, automation, reviews, and rollback. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools CI/CD, feature flags ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[CI/CD] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Change management
TOOLS: CI/CD, feature flags

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Reliability testing ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Inject failure safely and verify recovery behavior before incidents do. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Chaos Mesh, Litmus ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[Chaos Mesh] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Reliability testing
TOOLS: Chaos Mesh, Litmus

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Security and reliability ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Treat identity, patching, secrets, and abuse resistance as reliability concerns. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools IAM, threat modeling ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[IAM] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Security and reliability
TOOLS: IAM, threat modeling

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Executive reliability reporting ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Translate technical signals into customer impact and investment decisions. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools SLIs, dashboards ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[SLIs] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Executive reliability reporting
TOOLS: SLIs, dashboards

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# SRE capstone ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Operate a service through an injected incident, recovery, and postmortem. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Kubernetes, OpenTelemetry ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Site Reliability Engineering] App --> Control[Kubernetes] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: SRE capstone
TOOLS: Kubernetes, OpenTelemetry

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Chapter 3 — Embracing Risk ## Chapter focus Use error budgets to make explicit, data-driven trade-offs between reliability and delivery. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 3 — Embracing Risk

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 4 — Service Level Objectives ## Chapter focus Define SLIs and SLOs that represent customer experience and guide engineering priorities. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 4 — Service Level Objectives

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 5 — Eliminating Toil ## Chapter focus Identify repetitive manual work, measure it, and replace it with safe automation. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 5 — Eliminating Toil

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 6 — Monitoring Distributed Systems ## Chapter focus Design monitoring around symptoms, causes, signals, and actionable operator feedback. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 6 — Monitoring Distributed Systems

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 7 — Evolution of Automation ## Chapter focus Progress from manual operations to reliable, self-healing automation with guardrails. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 7 — Evolution of Automation

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 8 — Release Engineering ## Chapter focus Create repeatable releases with staged rollout, verification, rollback, and ownership. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 8 — Release Engineering

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 9 — Simplicity ## Chapter focus Reduce operational risk by keeping systems, interfaces, and dependencies understandable. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 9 — Simplicity

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 10 — Practical Alerting ## Chapter focus Build alerts that are urgent, actionable, owned, and connected to user impact. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 10 — Practical Alerting

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 13 — Emergency Response ## Chapter focus Stabilize incidents quickly while preserving communication, evidence, and decision quality. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 13 — Emergency Response

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 14 — Managing Incidents ## Chapter focus Use clear incident roles, command structures, status updates, and service restoration steps. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 14 — Managing Incidents

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 15 — Postmortem Culture ## Chapter focus Learn from failure through blameless timelines, contributing factors, and owned actions. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 15 — Postmortem Culture

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 16 — Tracking Outages ## Chapter focus Classify and trend outages to discover systemic reliability improvements. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 16 — Tracking Outages

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 17 — Testing for Reliability ## Chapter focus Test failure behavior, recovery, dependencies, and capacity before production incidents. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 17 — Testing for Reliability

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 18 — Software Engineering in SRE ## Chapter focus Apply software engineering methods to automation, tooling, and operational scale. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 18 — Software Engineering in SRE

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 19 — Load Balancing at the Frontend ## Chapter focus Distribute requests safely with health, latency, capacity, and failure-aware routing. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 19 — Load Balancing at the Frontend

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 20 — Load Balancing in the Datacenter ## Chapter focus Reason about regional and zonal load distribution, failover, and capacity. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 20 — Load Balancing in the Datacenter

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 23 — Distributed Consensus ## Chapter focus Understand critical state, consensus trade-offs, quorum, and safe coordination. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 23 — Distributed Consensus

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 24 — Distributed Periodic Scheduling ## Chapter focus Design reliable scheduled work with ownership, idempotency, jitter, and recovery. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 24 — Distributed Periodic Scheduling

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 25 — Data Processing Pipelines ## Chapter focus Build observable pipelines with backpressure, retries, checkpoints, and replay. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 25 — Data Processing Pipelines

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 26 — Data Integrity ## Chapter focus Ensure that what users read is what the system safely wrote and verified. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 26 — Data Integrity

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 27 — Reliable Product Launches ## Chapter focus Coordinate launch readiness, capacity, monitoring, rollback, and cross-team communication. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 27 — Reliable Product Launches

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 28 — Accelerating SREs to On-Call ## Chapter focus Create training and shadowing that moves engineers safely toward independent ownership. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 28 — Accelerating SREs to On-Call

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 29 — Dealing with Interrupts ## Chapter focus Protect focus and reliability work by measuring, routing, and reducing interruptions. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 29 — Dealing with Interrupts

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 30 — Recovering from Operational Overload ## Chapter focus Use embedded support, boundaries, and deliberate investment to restore team health. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 30 — Recovering from Operational Overload

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 33 — Lessons from Other Industries ## Chapter focus Borrow safety, resilience, and learning practices from mature high-risk industries. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 33 — Lessons from Other Industries

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Chapter 34 — Conclusion ## Chapter focus Synthesize SRE principles into a sustainable operating model for reliable services. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Chapter 34 — Conclusion

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Appendix A — Availability Table ## Chapter focus Practice translating availability targets into allowable downtime and error budgets. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Appendix A — Availability Table

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Appendix B — Production Service Best Practices ## Chapter focus Use a practical readiness checklist for ownership, observability, security, and recovery. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Appendix B — Production Service Best Practices

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Appendix C — Example Incident State Document ## Chapter focus Create a shared incident document that keeps facts, decisions, and actions aligned. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Appendix C — Example Incident State Document

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Appendix D — Example Postmortem ## Chapter focus Write a useful postmortem with impact, timeline, causes, and prevention actions. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Appendix D — Example Postmortem

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Appendix E — Launch Coordination Checklist ## Chapter focus Coordinate a launch with dependencies, owners, gates, communication, and rollback. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Appendix E — Launch Coordination Checklist

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up

# Appendix F — Production Meeting Minutes ## Chapter focus Capture operational decisions, risks, owners, and follow-ups in a durable record. ## How to study this chapter Translate the idea into a service you can observe. Define the user impact, the reliability signal, the failure mode, and the recovery action. Compare the ideal process with how your current service behaves. ## Practical lab 1. Choose a small service or local demo. 2. Write an SLI, an expected behavior, and a failure hypothesis. 3. Run a controlled test using logs, metrics, or a simple script. 4. Record evidence, mitigation, and one follow-up engineering action. ## Architecture ```mermaid flowchart LR Service[Production service] --> Signal[SLI, logs, metrics] Signal --> Operator[SRE or on-call operator] Operator --> Action[Mitigate, learn, automate] Action --> Service ``` ## Source This tutorial is an original learning guide linked to the chapter title. Read the full chapter at the Google SRE Book table of contents, then complete the lab and explain the trade-off in your own words.

SRE BOOK: Appendix F — Production Meeting Minutes

[ ] Identify user impact
[ ] Define an observable signal
[ ] Name the failure mode
[ ] Practice mitigation
[ ] Capture evidence
[ ] Create one owned follow-up