IBM Cloud Professional SRE key terms

A quantitative measure of one aspect of service behavior, such as request latency or error rate, expressed as a ratio of good events to valid events. SLIs supply the raw data from which objectives are judged.

A target range for an SLI over a defined window, such as 99.9 percent of requests succeeding in 28 days. It states how reliable a service must be without prescribing user-facing promises.

A contractual commitment with customers that specifies measurable service levels and remedies such as credits when those levels are missed. It is a business document, distinct from internal reliability targets.

The amount of unreliability an SLO permits in a period, computed as one minus the objective. Teams spend it on releases and experiments and freeze risky change when it is exhausted.

Manual, repetitive, automatable operational work that scales linearly with service growth and produces no lasting value. Reducing toil is a core SRE mandate and is often tracked as a percentage of time.

The average elapsed time from failure onset until service is restored. It measures recoverability rather than failure frequency and is reduced by good detection, runbooks, and rollback capability.

The average operating time between consecutive failures of a component or service. It characterizes how often failures occur and is used in availability modeling and redundancy decisions.

A structured review after an incident that documents timeline, impact, contributing causes, and follow-up actions without punishing individuals. Its purpose is learning and systemic improvement rather than assigning fault.

A ranked classification of an incident's customer and business impact that determines who is paged, how often updates are posted, and how much authority the responder holds. Severity is usually reassessed as the incident evolves.

The single person who coordinates response to a major incident, sets priorities, and communicates with stakeholders. This role deliberately does not perform hands-on debugging so that overall command stays clear.

A documented, step-by-step procedure for handling a known alert, failure, or routine operation. Good runbooks are versioned, linked from alerts, and tested so responders can act under pressure.

A higher-level guide describing roles, decision points, and communication patterns for a class of situations rather than exact commands. It complements runbooks, which give the concrete procedural steps.

Desensitization caused by too many low-value or duplicate notifications, leading responders to ignore or delay action on real problems. It is countered with symptom-based alerting, deduplication, and regular alert review.

Four service health metrics: latency, traffic, errors, and saturation. Monitoring them gives a compact, broadly applicable view of user-visible health before deeper diagnostic data is consulted.

A technique that follows a single request across services using propagated trace and span identifiers, showing where time is spent and which component failed. It is essential for diagnosing latency in microservice architectures.

The degree to which a system's internal state can be inferred from its outputs, typically logs, metrics, and traces. It enables answering novel questions without shipping new code to instrument the system.

A temporary policy that blocks non-emergency production changes during high-risk periods or when reliability targets are badly missed. It protects stability at the cost of delivery velocity.

A release pattern that sends a small slice of live traffic to a new version and compares its health against the old one before wider rollout. It limits blast radius and supports fast automated rollback.

A release technique that runs two identical environments and switches traffic from the live one to the updated one. Rollback is fast because the previous environment remains intact and ready.

Restoring a service to a previously known-good version or configuration after a faulty change. Effective rollback requires immutable artifacts, reversible migrations, and rehearsed procedures.

Managing compute, network, and platform resources through versioned definition files applied by tooling rather than manual console actions. It makes environments reproducible, reviewable, and auditable.

The file that maps declared resources to real cloud object identifiers and stores attributes needed for planning. It must be stored remotely with locking and treated as sensitive because it can contain secrets.

Divergence between the resources described in code or templates and what actually exists in the environment, usually caused by manual changes. Detection and reconciliation keep automation trustworthy.

A practice in which servers or containers are replaced with new builds rather than modified in place. It removes configuration drift and makes deployments predictable and repeatable.

The scope of impact a failure or change can cause, measured in affected users, services, or regions. Architecture and release practices aim to shrink it through isolation and staged rollout.

Duplicating critical components so that failure of one does not stop the service. Redundancy may be active-active or standby and must be paired with failover testing to be meaningful.

The process of shifting traffic or workload from a failed component to a healthy standby. Automated failover shortens outages but needs health checks and split-brain safeguards to avoid new failures.

Placing workload instances across independent availability zones within a region so a zone outage does not take down the service. It improves availability without the latency and cost of multi-region designs.

A logical container that organizes account resources for access control and billing visibility. A resource belongs to exactly one resource group, and IAM policies are frequently scoped to it.

The top-level billing and identity boundary for an organization's IBM Cloud usage, containing users, resource groups, and service instances. Access and cost controls are administered within it.

A rule granting a subject a role on a resource, resource group, or account, evaluated to authorize API and console actions. Policies combine who, what, and which platform or service roles apply.

A non-human IBM Cloud identity used by applications and automation to obtain API keys with scoped access. It separates machine credentials from personal user accounts and supports rotation.

Periodically replacing credentials and revoking old ones to limit the lifetime of a leaked secret. Automation should create the new key, deploy it, verify, then delete the previous key.

Granting only the permissions needed for a task and no more. It limits the damage from compromised identities or buggy automation and simplifies access reviews.

Forecasting demand for CPU, memory, storage, and network, then provisioning enough headroom to meet objectives at acceptable cost. It balances utilization efficiency against surge and failure headroom.

Automatically adjusting instance or worker counts in response to measured load or schedules. It requires sensible minimums, maximums, and warm-up behavior so scaling does not lag real traffic.

Spare capacity deliberately kept unused so the system absorbs traffic spikes and survives the loss of a zone or node. Too little causes saturation; too much wastes money.

Generating synthetic demand against a system to measure throughput, latency, and breaking points before real users arrive. Results inform capacity plans, autoscaling thresholds, and SLO feasibility.