DevOps Glossary

The scope of impact if a component fails or a deployment goes wrong. Reducing blast radius is a core reliability principle: deploy incrementally (canary/blue-green), use separate accounts per environment, scope IAM permissions narrowly, and use circuit breakers to prevent cascading failures.

The discipline of deliberately injecting failures into a system in production (or production-like environments) to discover weaknesses before they cause unplanned outages. Popularised by Netflix's Chaos Monkey. Tools: Chaos Mesh, Gremlin, AWS Fault Injection Service.

The allowed amount of unreliability derived from an SLO. If your SLO is 99.9%, you have a 0.1% error budget — about 43 minutes of downtime per month. When the budget is exhausted, feature releases are paused until it refills.

Mean Time to Detect (MTTD) — average time from an incident starting to its detection. Mean Time to Recovery (MTTR) — average time from incident detection to full service restoration. Both are key incident management metrics; MTTD is improved by better alerting, MTTR by runbooks and on-call training.

A contractual commitment between a service provider and a customer, with financial consequences for breaches. SLAs are always less strict than internal SLOs — if your SLO is 99.9%, your SLA might be 99.5% to give you a buffer.

A quantitative measure of a service's behaviour that matters to users — e.g., the fraction of requests served in under 200 ms, or the percentage of successful login attempts. SLIs are the raw metrics that feed into SLOs.

A target value or range for an SLI over a time window. For example: 99.9% of requests return HTTP 2xx within 300 ms, measured over a rolling 28-day window. SLOs define what 'reliable enough' means for a service.

Manual, repetitive, automatable work that grows linearly with service scale and produces no lasting value — restarting a failing pod by hand every day, manually rotating credentials. SRE practice is to keep toil below 50% of engineer time.

A technique for tracking a request as it flows through multiple services in a distributed system. Each service adds a span with timing and metadata; spans are linked by a trace ID. OpenTelemetry is the CNCF standard for instrumentation; Jaeger and Tempo are common backends.

The ability to understand the internal state of a system by examining its external outputs: logs (discrete events), metrics (aggregated numerical measurements), and traces (request flows across services). Observability differs from monitoring — monitoring tells you when something is wrong, observability lets you ask arbitrary questions about why.

A release strategy using two identical production environments (Blue = current, Green = new). Traffic is switched all-at-once from Blue to Green after validation. Rollback is immediate — flip traffic back to Blue. Higher infrastructure cost than canary, but simpler to implement and reason about.

A progressive delivery strategy where a new version is released to a small percentage of traffic (1–5%) before a full rollout. Metrics are observed on the canary; if error rates or latency degrade, the rollout is automatically halted and rolled back.

An operational framework where Git is the single source of truth for both application code and infrastructure configuration. A GitOps operator (ArgoCD, Flux) continuously reconciles the cluster state toward what is declared in the Git repository, making the repository the audit log.

An approach where servers or containers are never modified after deployment. Instead of patching in place, a new image is built and the old instance is replaced. Eliminates configuration drift, simplifies rollback, and makes deployments reproducible.

A deployment strategy that keeps the service continuously available during an update. In Kubernetes this requires: a RollingUpdate strategy with maxSurge/maxUnavailable configured, a correctly tuned readiness probe, and a PodDisruptionBudget to prevent simultaneous termination of all pods.

The process of identifying differences between the declared state of infrastructure (in IaC code) and the actual state of cloud resources. Drift occurs from manual console changes or automated resource replacement. Detected by running terraform plan and comparing the output.

The property of an operation that produces the same result whether it is applied once or many times. Infrastructure operations should be idempotent — running terraform apply twice with unchanged code should result in no changes the second time.

Managing infrastructure — servers, networks, databases — through machine-readable configuration files version-controlled in Git, rather than manual console clicks. IaC enables reproducibility, auditability, and automated testing. Tools: Terraform, OpenTofu, Pulumi, AWS CDK.

A Kubernetes plugin that intercepts API server requests (after authentication/authorisation) to validate or mutate objects before they are persisted. Validating admission webhooks reject non-conforming manifests; mutating webhooks inject sidecars, set defaults, or add labels. OPA/Gatekeeper and Kyverno implement policy as admission controllers.

A Kubernetes extension mechanism that lets you define new resource types with custom schemas. Once a CRD is installed, you can create instances of the new type (Custom Resources) and manage them with kubectl like built-in resources. The foundation of the Operator pattern.

A Kubernetes controller that automatically scales the number of pod replicas based on observed metrics (CPU utilisation, memory, or custom/external metrics via the Metrics API). HPA adjusts replicas between a configured min and max. It cannot scale to zero — use KEDA for that.

A Kubernetes pattern where a controller watches Custom Resources and drives the cluster toward a desired state encoded in the resource spec — automating the operational knowledge for a specific application (databases, message queues, certificates). cert-manager, Prometheus Operator, and Strimzi are examples.

A Kubernetes policy that limits the number of pods that can be simultaneously unavailable during voluntary disruptions (node drains, cluster upgrades). A PDB with minAvailable: 2 ensures at least 2 replicas stay running during a drain. Required for production workloads to prevent downtime during maintenance.

A resilience pattern that wraps calls to a downstream service and 'trips' (opens) after a threshold of failures, returning an error immediately instead of waiting for the timeout. After a cool-off period it allows a single test request through ('half-open'). Prevents cascading failures in distributed systems.

An architectural pattern that separates the read model (queries) from the write model (commands) of a service. Reads and writes use different data stores optimised for their access patterns. Often combined with Event Sourcing, where state is derived by replaying a log of immutable events rather than stored directly.

A system design where components communicate by producing and consuming events via a message broker (Kafka, RabbitMQ, AWS EventBridge). Producers emit events without knowing who consumes them; consumers react independently. Enables decoupling, scalability, and asynchronous workflows — at the cost of increased observability complexity.

A pattern for managing distributed transactions across microservices by breaking them into a sequence of local transactions, each publishing an event. If a step fails, compensating transactions undo prior steps. Two implementations: Choreography (event-driven, no central coordinator) and Orchestration (a central saga orchestrator drives the workflow).

An infrastructure layer for managing service-to-service (east-west) communication inside a cluster. Implemented as sidecar proxies (Envoy in Istio, linkerd-proxy in Linkerd) or eBPF programs (Cilium). Provides mTLS, traffic policy, retries, circuit breaking, and per-service observability without code changes.

A deployment pattern where a secondary container runs alongside the main application container in the same Kubernetes pod, sharing the same network namespace and storage volumes. Used for: log shipping, service mesh proxies (Envoy), secrets injection, and metrics collection — without modifying the application.

An extension of TLS where both the client and server present certificates, authenticating each other's identity — not just the server's. Used for service-to-service authentication in microservices. Service meshes automate mTLS issuance via short-lived certificates so application code remains unchanged.

A machine-readable inventory of all components, dependencies, and their versions in a software artifact. Required by US Executive Order 14028 for federal software supply chains. Generated by Syft; stored as SPDX or CycloneDX format; used by Grype for vulnerability matching against the full dependency tree.

Moving security and quality checks earlier in the development lifecycle — into the developer's local workflow and CI pipeline — rather than at a late-stage gate. Examples: running SAST in pre-commit hooks, scanning container images before push, and linting IaC for misconfigurations in PR checks.

A security framework (pronounced 'salsa') from Google and OpenSSF defining four levels of supply chain security. SLSA 1 requires a build script; SLSA 2 requires a hosted build service producing provenance; SLSA 3 requires a hardened build platform; SLSA 4 requires two-person review and hermetic builds. Most organisations target SLSA 2–3.

A Linux kernel technology that runs sandboxed programs inside the kernel without modifying kernel source or loading kernel modules. Used for high-performance networking (Cilium), deep observability without sidecars (Pixie, Tetragon), and runtime security enforcement (Falco, Tetragon). Eliminates the overhead of the sidecar proxy model.

A cloud financial management discipline and cultural practice where cross-functional teams collaborate to gain financial accountability for cloud spend. Based on the FinOps Foundation framework with three iterative phases: Inform (visibility), Optimize (reduce waste), Operate (govern and automate). Not a cost-cutting exercise — it's about maximising business value from cloud spend.

A paved, well-supported route for building and deploying services — opinionated defaults, templates, and tooling chosen by the platform team that represent the best-practice way to do something. Developers are free to deviate from the golden path, but they lose platform support when they do.

A self-service layer built on top of infrastructure tooling that allows developers to provision environments, deploy services, and manage configuration without filing tickets or waiting on the ops team. Implemented with tools like Backstage (service catalog), Crossplane (infrastructure APIs), and ArgoCD (GitOps deployment).

The discipline of building and maintaining internal developer platforms (IDPs) that abstract away infrastructure complexity and provide self-service capabilities to product teams. Platform engineers apply product thinking to internal tooling — reducing cognitive load so developers can focus on business logic.