SRE Practitioner flashcards
SRE Practitioner · 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.
- Toil
- Manual, repetitive, automatable, tactical work with no enduring value that scales linearly as the service grows; guidance caps it at 50% of an SRE team's time.
- Blameless postmortem
- A review that assumes responders acted reasonably given the information they had, so analysis targets systemic and process failures instead of assigning individual punishment.
- Single root cause fallacy
- The mistaken belief that an incident has one root cause; most arise from interacting contributing factors, and hunting a single cause leaves the enabling conditions in place.
- SRE versus DevOps
- DevOps is a cultural and philosophical movement; SRE is a prescriptive implementation of it, using SLOs, error budgets, toil limits, and software-based operations.
- SLI
- A quantitative measure of service behavior from the user's perspective, usually expressed as a ratio of good events to valid events over a measurement window.
- SLO
- A target range for a specific SLI over a defined window, agreed with stakeholders so that the reliability target encodes what users actually require.
- Error budget
- One minus the SLO: the amount of unreliability permitted over the window. It funds releases and experiments, and running out triggers a release freeze.
- Burn rate
- Observed error rate divided by the error budget rate. A burn rate of 1.0 exhausts the entire budget exactly at the end of one SLO window.
- Multiwindow burn-rate alerting
- Alerting that combines a fast short window, such as 14.4x burn over one hour, with a slower long window, reducing false positives while keeping detection fast.
- Zero trust
- A security model granting no implicit trust from network location; every request is authenticated, authorized, and encrypted, following least privilege for each identity.
- mTLS workload identity
- Mutual TLS combined with cryptographic workload identities such as SPIFFE IDs, so both ends of every service-to-service call authenticate each other with short-lived certificates.
- Blast radius containment
- Structuring the system into cells, zones, and bulkheads so that failure or compromise in one unit cannot propagate to the entire service.
- Distributed trace
- A record of one request's path across services and asynchronous hops, composed of spans that share a single propagated trace identifier.
- Span
- One timed operation inside a trace, carrying a service name, operation, duration, status, attributes, and a parent link that reconstructs the request tree.
- Head-based sampling
- Deciding whether to record a trace at its start. It is cheap and simple, but blind to whether the request later fails or runs slowly.
- Tail-based sampling
- Deciding whether to keep a trace after it completes, so error and high-latency traces are retained while overall volume and cost stay low.
- Exemplars
- Trace or log references attached to individual metric samples, letting an engineer jump from a latency spike to a concrete example request.
- RED method
- Rate, Errors, Duration: the three signals recommended for every request-driven service, giving a minimal, uniform view of user-facing health.
- Observability-driven development
- Writing instrumentation and tests that assert on traces, metrics, and logs during development, so observability is designed in rather than added after an incident.
- AIOps
- Applying machine learning to operational telemetry for anomaly detection, alert correlation, noise reduction, root-cause suggestion, and predictive forecasting of capacity or failure.
- Alert correlation
- Grouping related alerts by topology, time, and shared entity so that one underlying outage produces one actionable incident instead of hundreds of pages.
- DataOps
- Versioned, tested, automated data pipelines with schema validation and lineage, keeping analytics and machine-learning inputs reproducible and trustworthy.
- Model drift
- Degradation of a predictive model as production data diverges from training data, requiring monitoring of inputs and outputs plus scheduled retraining.
- Internal developer platform
- A self-service layer of tooling, templates, and golden paths that lets product teams provision, deploy, and observe services without filing tickets.
- Golden path
- A pre-approved, secure-by-default template with CI/CD, observability, and SLO scaffolding pre-wired; teams may deviate only with explicit justification.
- Platform as a product
- Treating developers as customers: roadmaps informed by research, with adoption, time-to-first-deploy, and support load measured as platform objectives.
- Chaos engineering
- Running controlled experiments on a system to verify it withstands turbulent production conditions, always starting from a measurable and defined steady state.
- Steady-state hypothesis
- A measurable statement of normal behavior, often an SLI range, that an experiment attempts to disprove by injecting a realistic failure condition.
- Incident commander
- The single accountable role that coordinates response, sets severity, delegates tasks, and decides mitigation priorities during an incident, without debugging personally.
- Time to mitigate
- The interval from impact starting until customer impact ends. It is reported separately from full repair time because mitigation is what users and SLOs actually experience.
- Severity level
- A pre-agreed classification based on customer impact and scope that determines who is paged, how often stakeholders receive updates, and who must be notified.
- Error budget policy
- A written, pre-agreed rule set that halts feature releases and prioritizes reliability work once the error budget is spent, enforceable only with executive sponsorship.