SRE Foundation flashcards
SRE Foundation · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Site Reliability Engineering
- A discipline that applies software engineering to operations problems, using SLOs, automation, and blameless learning to run reliable production systems at scale.
- Fifty percent rule
- The SRE guideline that no more than half of an SRE's time goes to operational work such as toil, tickets, and on-call; the rest goes to engineering.
- Simplicity as a virtue
- The SRE principle that systems with fewer components and simpler interactions have fewer failure modes, so simplicity is preferred unless a strong reason justifies complexity.
- Error budget
- One minus the SLO, expressed as the amount of unreliability a service may consume over the window; exhaustion shifts priority from feature launches to reliability work.
- Service Level Indicator
- A quantitative measure of service behavior, such as the ratio of successful requests to total requests, or the fraction of requests faster than 300 milliseconds.
- Service Level Objective
- A target value or range for an SLI over a defined window, for example 99.9 percent of requests succeeding over a rolling 28-day period.
- Burn rate alerting
- Alerting on how quickly the error budget is consumed relative to the sustainable rate, usually pairing a fast short window with a slower long window.
- Error budget policy
- A pre-agreed written rule stating what happens when the error budget is exhausted, typically freezing non-essential releases until reliability is restored.
- Toil
- Work that is manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as the service grows.
- Toil budget
- A cap, commonly 50 percent of an SRE's time, on manual operational work; exceeding it triggers investment in automation or a reduction in scope.
- Toil measurement
- Quantifying manual work through time tracking or periodic surveys so a team can set a toil budget and justify automation projects with data.
- Four golden signals
- Latency, traffic, errors, and saturation: the four metrics recommended for monitoring a user-facing system when only a few signals can be watched.
- USE method
- For each resource, check utilization, saturation, and errors; a checklist for finding bottlenecks in infrastructure such as CPU, memory, disks, and networks.
- RED method
- For each service, monitor the rate of requests, the number of errors, and the duration of requests; a compact service-level monitoring checklist.
- Tail latency
- Latency at a high percentile, such as the 99th, which averages hide and which often dominates the slowest user experiences in fan-out request patterns.
- Idempotent automation
- Automation that produces the same end state when run repeatedly, making retries, crash recovery, and periodic reconciliation safe.
- Canary release
- Shipping a change to a small slice of traffic first, comparing its SLIs against the baseline, and expanding only if no regression appears.
- Progressive rollout
- Releasing a change in stages to increasing fractions of traffic, with automated checks and rollback when service level indicators degrade.
- Configuration as code
- Keeping service and infrastructure configuration in version control so every change is reviewable, reproducible, and easy to revert.
- Blameless postmortem
- A written review of an incident that assumes people acted reasonably given their information at the time and focuses on systemic causes and fixes.
- Chaos engineering
- Running controlled experiments, usually in production, that inject realistic failures to discover weaknesses before they cause unplanned outages.
- DiRT
- Disaster Recovery Testing: scheduled exercises that rehearse responses to large-scale failures such as loss of a datacenter or a critical dependency.
- Graceful degradation
- Designing a service so that when a dependency fails it continues to deliver a reduced but still useful function instead of failing completely.
- On-call time cap
- The guideline that on-call duty should consume no more than about 25 percent of an SRE's working time, leaving the rest for engineering.
- Two incidents per shift
- A rule of thumb that an on-call shift is too burdensome if it produces more than two significant incidents, signaling the service needs work.
- Embedded SRE model
- An engagement where SREs join a product team, often temporarily, to build reliability practices and transfer operational skills to that team.
- Class SRE implements DevOps
- A phrase expressing that SRE is a concrete implementation of DevOps principles, sharing the goals while adding practices such as SLOs and error budgets.
- DORA four keys
- Deployment frequency, lead time for change, change failure rate, and time to restore service: four measures of software delivery performance.
- CAMS model
- The DevOps framing of Culture, Automation, Measurement, and Sharing; SRE contributes most directly to measurement through SLIs and error budgets.
- Platform engineering
- Building internal self-service platforms and toolchains so product teams can deliver and operate software with reliability defaults without deep infrastructure expertise.
- FinOps
- A discipline bringing financial accountability to cloud spending, treating cost as an engineering metric managed alongside reliability and latency.
- Reliability as a product
- Treating reliability features, SLOs, and error budgets as product capabilities with named owners, roadmaps, and explicit user-facing promises.