What's changed: Created Professional Cloud DevOps Engineer Chapter 3 (Domain 3 "SRE": SLI/SLO/SLA, error budgets, nines vs cost/opportunity cost; service lifecycle, capacity planning = quotas/limits/reservations/Dynamic Workload Scheduler, autoscaling = MIG/Cloud Run/GKE, incident mitigation = drain/redirect/add capacity/rollback).
3.2Service lifecycle, capacity planning, and incident mitigation
Understand service lifecycle management (plan/deploy/maintain/retire), capacity planning (quotas, limits, reservations, Dynamic Workload Scheduler), autoscaling (managed instance groups, Cloud Run, GKE), and mitigating incident impact on users (draining/redirecting traffic, adding capacity, rollback).
Reliability is upheld in operations: manage services from planning to retirement, match capacity to demand, and quickly shrink user impact during incidents.
3.2.1Lifecycle, capacity planning, and autoscaling
Manage services through the plan→deploy→maintain→retire lifecycle. For capacity, know your quotas/limits; for guaranteed capacity use reservations, and use Dynamic Workload Scheduler to schedule scarce resources like GPUs/TPUs. Handle demand with autoscaling: VM fleets via managed instance groups (MIG), serverless via Cloud Run, containers via GKE (HPA/cluster autoscaler). Map "guaranteed capacity = reservations" and "auto-scale VMs = MIG."
3.2.2Mitigating incident impact on users
During incidents, prioritize mitigating user impact first (root-causing happens in parallel/after). Concretely: drain/redirect traffic away from unhealthy targets (load balancer/Cloud Service Mesh), add capacity if saturated, and roll back if a bad change caused it. After mitigation, do permanent fixes and a blameless postmortem. Map "stop the bleeding first (mitigate impact)" and "bad change → rollback."
Common: requirement → means. E.g., "guarantee capacity" = reservations; "schedule GPU/TPU capacity" = Dynamic Workload Scheduler; "auto-scale a VM fleet" = MIG; "serverless autoscale" = Cloud Run; "move traffic off unhealthy targets" = drain/redirect; "bad change caused it" = rollback.
Watch the mix-ups: (1) In incidents, mitigate user impact before root-causing. (2) Quotas/limits (default caps) vs reservations (pre-secured capacity) differ. (3) Pick autoscaling by target: MIG (VMs)/Cloud Run (serverless)/GKE (containers).
3.2.3Section summary
- Manage services plan→deploy→maintain→retire; capacity via quotas/limits/reservations/Dynamic Workload Scheduler
- Autoscaling = MIG (VMs)/Cloud Run (serverless)/GKE (containers)
- In incidents, mitigate first (drain/redirect, add capacity, rollback); then permanent fixes and a blameless postmortem
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To automatically scale a group of VMs with demand, which is best?
Q2. To guarantee capacity of a specific machine type for future demand, which is best?
Q3. An incident occurs in production. As an SRE, what should you do first?
Q4. Errors spiked right after deploying a bad change. What is the best mitigation?
Q5. To schedule capacity acquisition for scarce accelerators like GPUs/TPUs, which is best?