IBM Cloud Associate SRE key terms

A quantitative measure of one aspect of service behavior, such as request latency, error rate, or availability, calculated from monitoring data. SLIs are the raw numbers against which objectives are compared.

A target range for an SLI over a defined window, for example 99.9 percent of requests succeeding over 30 days. SLOs guide reliability investment and alerting thresholds.

A contract with customers that states promised service levels and the financial or other remedies available when they are missed. SLAs are usually looser than internal SLOs.

The allowed amount of unreliability derived from an SLO, such as 0.1 percent of failed requests in a 30-day window. Teams spend it on releases and experiments.

How fast an error budget is consumed relative to the SLO window. A burn rate of one exhausts the budget exactly at window end; multi-window alerts catch both fast and slow burns.

Repetitive, manual, automatable operational work that grows with the service but produces no lasting value. SRE teams cap toil and shift effort toward engineering.

Deliberately injecting controlled failures, such as killing instances or adding latency, to verify that resilience mechanisms work before real outages occur.

Four key metrics for user-facing services: latency, traffic, errors, and saturation. Monitoring these first gives broad visibility before adding service-specific metrics.

A monitoring approach for request-driven services that tracks rate, errors, and duration for each service. It complements golden signals with a per-service focus.

A resource-oriented method that checks utilization, saturation, and errors for every resource such as CPU, memory, disks, and network links.

Recording a request's path across services with shared trace and span identifiers so engineers can find which hop adds latency or produces errors.

Emitting logs as machine-parsable fields, typically JSON, with consistent keys such as request ID and severity, so logs can be filtered, searched, and aggregated reliably.

Desensitization caused by too many low-value or noisy alerts, which makes responders slower or likely to miss real problems. Fixing it requires actionable, symptom-based alerts.

Paging on user-visible symptoms such as a high error rate or slow checkout rather than on every internal metric change, so each page maps to real impact.

The average elapsed time between the start of a failure and the moment monitoring or a person notices it. Lowering MTTD shortens total outage duration.

A hosted observability service, based on Sysdig, that collects metrics, events, and container and host telemetry from IBM Cloud resources and applications, with dashboards and alerts.

A managed log service in IBM Cloud for ingesting, searching, and retaining application and platform logs. It supports alerting and integration with monitoring dashboards.

A written review after an incident that focuses on system conditions, contributing factors, and preventive actions rather than punishing individuals, so people share details honestly.

A ranking, for example SEV1 through SEV4, that sets response urgency, who is paged, communication cadence, and escalation. Severity reflects customer impact, not effort.

Step-by-step operational instructions for handling a specific alert or routine task, kept close to the alert definition and updated when incidents reveal gaps.

The average time from failure detection to restored service. Reducing MTTR through automation, rollback, and practice matters more than preventing every failure.

Managing infrastructure through versioned definition files such as Terraform or Schematics templates, enabling review, repeatability, and rollback of environment changes.

Releasing a change to a small slice of traffic or users first, watching error and latency signals, then expanding the rollout or rolling back.

Running two identical environments and switching traffic from the current one to the new one, allowing fast rollback by switching traffic back.

A managed Kubernetes offering where IBM operates the control plane while workers run in customer VPC or classic infrastructure, with integrated logging, monitoring, and IAM.

A serverless platform that runs containers, jobs, and functions, scales to zero, and handles HTTP routing so teams can deploy without managing clusters.

A logical container for IBM Cloud resources that supports access control and billing organization. IAM policies can be scoped to a resource group.

An isolated software-defined network in IBM Cloud with its own address ranges, subnets, security groups, and routing, connected to other networks through gateways.

An IBM Cloud service that connects VPCs, classic infrastructure, and on-premises networks through a single hub, simplifying routing compared with many point-to-point connections.

A dedicated private network connection between an on-premises site and IBM Cloud, avoiding the public internet and offering more predictable latency and bandwidth.

IBM's managed DNS, DDoS protection, web application firewall, and global load balancing offering, providing a security and traffic front door for applications.

The IBM Cloud system that authenticates users and controls authorization through access groups, roles, and policies scoped to accounts, resource groups, and individual resources.

A non-human IBM Cloud identity with its own API keys and IAM policies, used by applications and automation instead of personal user credentials.

A service for storing, rotating, and auditing credentials such as API keys and passwords, so applications fetch secrets at runtime instead of embedding them in code.

A service that records account-level API activity and security-relevant events, such as logins and resource changes, for auditing and compliance investigations.

Automatically adding or removing instances, pods, or workers based on metrics such as CPU or request rate, to match capacity to demand while controlling cost.

Forecasting demand and provisioning compute, storage, and network headroom so services meet SLOs during peaks without over-provisioning steadily.

A hard account or resource limit set by the provider, such as maximum instances per region, that can block scaling if not monitored and raised in advance.