Site Reliability Engineer
SLOs and incident management questions
101 questions on SLOs and incident management for site reliability engineers, easiest first.
Easy 34
- What is an SLO?easy
- Error budget for 99.9%easy
- Spotting toileasy
- Why blameless postmortems?easy
- Downtime allowed by 99.99%easy
- Writing an SLI as a ratioeasy
- What MTTR measureseasy
- A useful runbookeasy
- Escalation policieseasy
- Safer Bash scriptseasy
- Links inside alertseasy
- SLO stricter than the SLAeasy
- Why not aim for 100%?easy
- Error budget in requestseasy
- A good latency SLIeasy
- Choosing what to measureeasy
- Downtime at 99.95%easy
- An SLA crediteasy
- Data loss vs downtime targetseasy
- Data loss with 6-hour backupseasy
- Where outages come fromeasy
- A kill switcheasy
- A burn rate of 1easy
- Why a 28-day windoweasy
- What N+1 meanseasy
- Why run load testseasy
- Setting incident severityeasy
- The first status page updateeasy
- Keeping people informedeasy
- Recording what happenedeasy
- What MTTA measureseasy
- Handing over on-calleasy
- Incident vs problemeasy
- After a night of pageseasy
Medium 35
- Which alert should page?medium
- A pod stuck in Pendingmedium
- A script that hangs forevermedium
- Budget spent, release plannedmedium
- Three services in a chainmedium
- Two replicas in parallelmedium
- Budget left after an outagemedium
- Rolling or calendar windowmedium
- What an error budget policy saysmedium
- Calculating burn ratemedium
- How long the budget lastsmedium
- An SLI for a data pipelinemedium
- Do 404s count as failures?medium
- Promising more than a dependencymedium
- Agreeing an SLO with productmedium
- An SLO that is too strictmedium
- Picking an initial targetmedium
- One SLI for success and speedmedium
- Availability from MTBF and MTTRmedium
- Planning for monthly growthmedium
- Planning for a big salemedium
- Autoscaling at a flash salemedium
- Degrading instead of failingmedium
- One slow dependency takes all threadsmedium
- An incident report for customersmedium
- Roll back or roll forward?medium
- Declaring an incidentmedium
- When to write a postmortemmedium
- Action items that get donemedium
- How much toil is too muchmedium
- Sharing on-call across time zonesmedium
- Your payment gateway is downmedium
- "Human error" as the causemedium
- Reviewing a near missmedium
- Business impact of an outagemedium
Hard 32
- How much budget does a burn rate use?hard
- Little's Law for capacityhard
- Why a short window in burn-rate alertshard
- Misleading histogram quantileshard
- Alerting on queue laghard
- SLOs for a low-traffic servicehard
- Where to measure the SLIhard
- Emergency access to productionhard
- Which pods are evicted first?hard
- How many nodes to runhard
- Latency at 90% utilisationhard
- Retries and the SLIhard
- Counting requests or good minuteshard
- Do 429s burn the budget?hard
- Combining daily SLI numbershard
- Two targets for one servicehard
- A release during a freezehard
- SLOs for an internal platformhard
- Blaming the cloud providerhard
- When a bad incident rolls offhard
- How many queue workershard
- p99 per window vs a ratiohard
- Surviving a zone losshard
- An SLI that looks too goodhard
- Limits of the 5 whyshard
- The Swiss cheese modelhard
- How many incidents per shifthard
- How big an on-call rotation should behard
- Rewarding fewer incidentshard
- MTTR hiding the real picturehard
- Learning across postmortemshard
- A crowded incident channelhard