This glossary defines the DevOps, site reliability engineering, FinOps and software supply chain terms that come up when teams build, run and pay for production systems. Each definition starts with what the term is, stays short enough to quote, and links to the InfraZen guide that goes deeper where one exists.
The terms are grouped into five categories: delivery, infrastructure and platforms, reliability and observability, cloud cost and FinOps, and security and supply chain. Where one of our guides already defines a term, the wording here matches it, so the site says one thing. Everything else follows primary sources: the CNCF Cloud Native Glossary, the Site Reliability Engineering books, DORA, the FinOps Foundation, NIST and the SLSA specification, listed at the end of the page.
Delivery
How code gets from a commit to production, and the metrics that show whether that path is fast and safe.
DevOps
DevOps is the practice of running software development and software operations as one continuous workflow instead of two separate teams. The engineers who write the code are responsible for building, deploying and running it in production.
CI/CD
CI/CD is the pairing of continuous integration with continuous delivery or deployment: every commit builds, every build runs tests, and every passing build can be deployed automatically. It is the delivery backbone that most other DevOps practices depend on.
Continuous integration (CI)
Continuous integration (CI) is the practice of merging code changes into a shared mainline as often as possible, with every change built and tested automatically. It ends with a tested, versioned artifact that is ready for a continuous delivery system to deploy.
Continuous delivery (CD)
Continuous delivery (CD) is the practice of keeping every change that passes the pipeline releasable, deploying it automatically to a test or acceptance environment, so a production release becomes a routine, low-risk decision with a tested way to roll back.
Continuous deployment
Continuous deployment is continuous delivery with the final manual step removed: every change that passes the automated pipeline goes to production without a human approval. It depends on strong automated tests, progressive rollouts and fast rollback.
Trunk-based development
Trunk-based development is a branching model in which developers merge small batches of work into one shared branch, the trunk, at least once a day. Branches live for hours rather than weeks, and there are no code freezes or long integration phases.
Feature flags
Feature flags are runtime switches that change what a system does without changing or redeploying code. Also called feature toggles, they let teams ship code dark, release it to a subset of users first, and turn a misbehaving feature off in seconds.
Canary release
A canary release is a deployment strategy that sends a small share of live traffic to a new version first, watches its errors and latency, then shifts the rest of the traffic over in stages, rolling back quickly if the new version misbehaves.
Blue-green deployment
Blue-green deployment is a release strategy that keeps two production environments: blue serves live traffic while green receives the new version. After testing, traffic switches to green, usually at the load balancer, and switching back to blue is the rollback.
DORA metrics
DORA metrics are the software delivery performance measures published by DORA, the DevOps Research and Assessment program. The current set has five: deployment frequency, change lead time, change fail rate, failed deployment recovery time and deployment rework rate.
Deployment frequency
Deployment frequency is the number of deployments to production over a given period, or the time between them. It is one of the DORA throughput metrics, and a rising frequency usually means changes are shipping in smaller, safer batches.
Change lead time
Change lead time is the time it takes a change to go from being committed to version control to running in production. Also called lead time for changes, it is a DORA throughput metric that exposes queues, manual approval gates and slow pipelines.
Change fail rate
Change fail rate is the ratio of deployments that need immediate intervention after reaching production, such as a rollback or a hotfix. Often called change failure rate, it is one of the DORA instability metrics and balances speed against stability.
Failed deployment recovery time
Failed deployment recovery time is the time it takes to recover from a deployment that fails and needs immediate intervention. It replaced mean time to recover in the DORA model, narrowing recovery to failures caused by changes rather than every kind of outage.
Deployment rework rate
Deployment rework rate is the ratio of deployments that are unplanned and happen because of an incident in production. The fifth and newest DORA metric, it sits alongside change fail rate as a measure of how unstable delivery is.
Artifact
An artifact is the versioned output of a build, such as a container image, package or binary, that is tested once and then promoted unchanged through each environment. Building once and promoting the same artifact keeps what was tested identical to what ships.
Pipeline
A pipeline is the automated sequence of stages every change passes through on its way to production, typically build, test, security scan and deploy. A CI/CD pipeline turns delivery into a repeatable, auditable process instead of a manual checklist.
Infrastructure & platforms
How infrastructure is declared, reconciled and packaged, and the platforms teams build on top of it.
Infrastructure as code (IaC)
Infrastructure as code (IaC) is the practice of defining servers, networks, databases and other cloud resources in version-controlled files and letting automation create and change them. It makes environments reproducible, reviewable and auditable instead of built by hand.
Terraform
Terraform is an infrastructure-as-code tool that lets you define cloud and on-premises resources in human-readable configuration files. It generates a plan of the changes needed to match that configuration, then applies them through providers that call each platform's API.
Configuration drift
Configuration drift is the gap that opens when live infrastructure no longer matches its declared, version-controlled definition, usually after manual console or command-line changes made in a hurry. Drift makes environments unpredictable and quietly undoes changes that went through review.
GitOps
GitOps is an operating model where the desired state of your entire system lives in version control, and software agents continuously reconcile the running infrastructure to match what is committed to Git. Deployments become pull requests and rollbacks become reverts.
Reconciliation loop
A reconciliation loop is a control loop that continuously compares a system's actual state with its declared desired state and acts to close any gap. Kubernetes controllers and GitOps agents both work this way, which is why they repair drift without a human.
Argo CD
Argo CD is a declarative GitOps continuous delivery tool for Kubernetes. It models each deployment as an Application object, shows live-versus-desired differences in a web interface, and syncs clusters to what is committed in Git, with multi-tenant access control built in.
Flux
Flux is a set of continuous and progressive delivery tools for Kubernetes, built as composable controllers that keep clusters in sync with Git and other sources. It has no mandatory user interface and suits teams that want everything declared as Kubernetes resources.
Helm
Helm is the package manager for Kubernetes. It bundles an application's Kubernetes manifests into a versioned, parameterized chart, so even a complex application can be installed, upgraded and rolled back as a single unit. Helm is a graduated CNCF project.
Container
A container is a lightweight, portable package that bundles an application with its dependencies so it runs the same on a laptop, in CI and in production. Containers share the host operating system's kernel, which makes them faster to start than virtual machines.
Kubernetes
Kubernetes is an open-source system for automating the deployment, scaling and operation of containerized applications across a fleet of machines. You declare the desired state, and its control loops keep reality matching it. It is often shortened to K8s.
Pod
A pod is the smallest deployable unit in Kubernetes: one or more containers that share a network address, storage and lifecycle, and are always scheduled together on the same node. Pods are usually created and replaced by higher-level objects such as Deployments.
Node
A node is a worker machine in a Kubernetes cluster, either a virtual machine or a physical server, that runs pods. Each node is managed by the control plane and runs a kubelet agent, a container runtime and a network proxy.
Cluster autoscaler
A cluster autoscaler is a Kubernetes component that adds nodes when pods cannot be scheduled for lack of capacity, and removes underused nodes to cut cost. The project named Cluster Autoscaler does this by adding and removing nodes in node groups you define in advance.
Karpenter
Karpenter is an open-source Kubernetes node autoscaler that launches right-sized nodes just in time for pods that cannot be scheduled, without predefined node groups. It also consolidates workloads, removing underused nodes or replacing them with cheaper ones.
Microservices
Microservices are an architecture in which an application is built as a set of small, independently deployable services, each owning one business capability and talking to the others over the network. Teams ship independently, at the price of more operational complexity.
Platform engineering
Platform engineering is the discipline of building an internal product, the internal developer platform, that gives product teams a self-service, paved path to build, ship and run software without becoming experts in the infrastructure stack underneath.
Internal developer platform (IDP)
An internal developer platform (IDP) is the curated, self-service layer between developers and infrastructure: templates, provisioning, pipelines and guardrails that take an engineer from an empty repository to a monitored production service without filing a ticket.
Golden path
A golden path is a single, opinionated, well-supported way to do a common task, such as creating a new service, with the pipeline, observability and security defaults already wired in. Sometimes called a paved road, it is the best-supported route, not the only one.
Landing zone
A landing zone is a pre-built, multi-account cloud foundation that sets up identity, networking, security, logging and billing structure before any workload arrives. Workload teams then deploy into accounts that inherit those guardrails, usually provisioned through infrastructure as code.
Service mesh
A service mesh is an infrastructure layer that manages traffic between services and adds reliability, observability and security features, such as retries, mutual TLS and per-request metrics, uniformly across every service without code changes, typically through sidecar proxies.
Reliability & observability
How reliability targets are set and defended, and the telemetry that makes them measurable.
Site reliability engineering (SRE)
Site reliability engineering (SRE) is the engineering practice of running production systems with explicit numerical reliability targets, an error budget that gates risk-taking, and a discipline of eliminating repetitive operational work by writing code instead of doing it manually.
Service level indicator (SLI)
A service level indicator (SLI) is a carefully defined, quantitative measure of some aspect of the service users receive, such as the share of requests that succeed or finish within a latency threshold. SLIs are the measurements that SLOs set targets for.
Service level objective (SLO)
A service level objective (SLO) is a target value for a service level indicator over a time window, for example 99.9% of checkout requests succeeding within 800ms over a rolling 28 days. It states how reliable a service needs to be.
Service level agreement (SLA)
A service level agreement (SLA) is an explicit or implicit contract with users that includes consequences, such as service credits, for meeting or missing the SLOs it contains. Internal SLOs are usually set tighter than the SLA, so teams are warned before a breach.
Error budget
An error budget is the amount of unreliability an SLO allows: one minus the SLO, so a 99.9% target leaves a 0.1% budget, roughly 43 minutes a month. While budget remains, teams can take risks; once it is spent, reliability work comes first.
Burn rate
Burn rate is how fast, relative to the SLO, a service is consuming its error budget. A burn rate of 1 spends exactly the whole budget by the end of the SLO window, so alerting on high burn rates pages people only for real threats.
Toil
Toil is operational work that is manual, repetitive, automatable, tactical, devoid of enduring value, and that grows linearly as a service grows. SRE practice caps it, classically at half of an engineer's time, and spends the rest on automation that removes it.
Postmortem
A postmortem is a written record of an incident: its impact, the actions taken to mitigate it, the root causes and the follow-up actions that prevent a repeat. Blameless postmortems look for systemic causes rather than individual fault, so people report problems honestly.
On-call
On-call is the rotation in which engineers take turns being available to respond to production alerts within an agreed response time, then triage, mitigate and escalate incidents. Sustainable on-call needs enough people in the rotation and alerts that fire only when users are affected.
Mean time to acknowledge (MTTA)
Mean time to acknowledge (MTTA) is the average time between an alert firing and a responder acknowledging it and starting work. It measures how quickly the on-call process reacts, separately from how long the fix takes, and a rising MTTA often signals alert fatigue.
Mean time to recovery (MTTR)
Mean time to recovery (MTTR) is the average time from an incident starting, or being detected, until service is restored for users; the R is also read as restore, repair or resolve. Because teams define the start and end differently, compare MTTR only within one team.
Runbook
A runbook is a written, step-by-step procedure for diagnosing and handling a specific alert or operational task, so whoever is on call can respond quickly and consistently. Good runbooks are linked from the alert itself and updated after every incident that exposes a gap.
Observability
Observability is the ability to understand a system's internal state from the data it emits externally, its logs, metrics and traces, so you can answer new questions about its behavior without shipping new code to ask them.
Monitoring
Monitoring is collecting, processing, aggregating and displaying real-time quantitative data about a system, such as request counts, error counts and latency, and alerting on conditions defined in advance. It answers known questions and is a subset of observability, not a rival to it.
OpenTelemetry (OTel)
OpenTelemetry (OTel) is an open-source, vendor-neutral observability framework for generating, collecting and exporting telemetry such as traces, metrics and logs. Instrumenting once against it lets teams switch observability backends without rewriting code. It is a graduated CNCF project.
Prometheus
Prometheus is an open-source monitoring and alerting toolkit that collects and stores metrics as time series, each identified by a metric name and key-value labels, and queries them with its own language, PromQL. It joined the CNCF in 2016.
Golden signals
The golden signals are latency, traffic, errors and saturation: how long requests take, how much demand the system serves, what fraction of requests fail, and how close it is to capacity. The Site Reliability Engineering book says: if you can measure only four metrics, focus on these.
RED method
The RED method is a monitoring checklist for request-driven services: track the rate of requests, the errors among them, and the duration each request takes. It gives every service the same basic dashboard and describes what users of that service experience.
USE method
The USE method is a checklist for analyzing resources: for every resource, such as a CPU, a disk or a connection pool, check its utilization, saturation and errors. It suits infrastructure and capacity questions, while the RED method describes the request path.
Cardinality
Cardinality is the number of unique values a field can take: HTTP status code is low cardinality, user ID is high. In metrics systems every unique label combination becomes a separate time series, so high-cardinality labels drive cost and can overload the database.
Distributed tracing
Distributed tracing is recording the path of a single request as it moves through every service it touches, as a trace made of timed spans, one per unit of work. It shows where latency accumulates and which dependency failed in a distributed system.
Cloud cost & FinOps
How cloud spend is attributed, discounted and governed.
FinOps
FinOps is an operational framework and cultural practice that maximizes the business value of technology, enables timely data-driven decision making and creates financial accountability through collaboration between engineering, finance and business teams.
Cost allocation
Cost allocation is assigning cloud cost and usage to the teams, products and customers responsible for it, using accounts, tags, labels and other metadata, plus agreed rules for splitting shared costs. It is the foundation for showback, chargeback and unit economics.
Tagging
Tagging is attaching key-value metadata, such as owner, environment, cost center and product, to cloud resources so their cost and usage can be allocated, filtered and governed. Tags only hold up when a policy defines them and the pipeline rejects untagged infrastructure.
Showback
Showback is reporting cloud costs to the teams responsible for them without formally billing their budgets. It builds cost awareness and accountability at any level of detail, from a whole business unit down to a single service, and usually comes before chargeback.
Chargeback
Chargeback is formally billing allocated cloud costs back to the budgets of the teams, products or business units that incurred them, through the organization's accounting system. It differs from showback only in that formality, and it needs trustworthy cost allocation first.
Unit economics
Unit economics is relating technology spend to the value it creates by measuring cost per unit of business output, such as cost per customer, per transaction, per request or per token. It shows whether rising spend reflects growth or waste.
Rightsizing
Rightsizing is matching the size of cloud resources, such as instance types or container resource requests, to what workloads actually use, based on observed utilization. It should come before buying commitments, so a discount on waste is not locked in.
Savings Plans
Savings Plans are a commitment-based discount: you commit to a consistent amount of compute spend for one or three years and pay lower rates that, in their most flexible form, apply across instance families, sizes and regions as your architecture changes.
Reserved Instances
Reserved Instances are a billing discount, not physical servers: you commit to a specific instance configuration, such as type and region, for one or three years, and matching usage is billed below on-demand prices. They are less flexible than Savings Plans.
Committed use discounts
Committed use discounts are lower prices granted in exchange for committing to a minimum level of resource usage, or a minimum amount of spend, for one or three years. Resource-based commitments cover specific capacity; spend-based ones cover eligible services.
Spot instances
Spot instances are spare cloud capacity sold at a steep discount to on-demand prices, which the provider can reclaim at short notice when it needs the capacity back. They suit fault-tolerant, interruptible work such as batch jobs, CI runners and stateless replicas.
Commitment coverage
Commitment coverage is the share of eligible usage or spend billed at committed-discount rates, from Savings Plans, Reserved Instances or committed use discounts, instead of on-demand prices. Too little leaves savings unclaimed; chasing full coverage risks paying for unused commitments.
Cost anomaly detection
Cost anomaly detection is automatically flagging spend that differs, usually upward, from normal historical or expected levels, and alerting the owning team within hours rather than at month-end. It catches sudden spikes well but can miss slow, steady drift.
FOCUS
FOCUS is the FinOps Open Cost and Usage Specification, an open specification that normalizes billing data from cloud, SaaS, AI, data center and other technology vendors into one common format, so costs from different providers can be compared and combined.
Egress
Egress is data transferred out of a cloud provider's network or region, whether to the internet or to another region. Providers typically bill it per gigabyte while inbound traffic is usually free, so chatty or cross-region designs can make data transfer a major line item.
NAT gateway charges
NAT gateway charges are the fees a managed NAT gateway incurs for both the time it runs and every gigabyte it processes. Because private-subnet traffic to the internet and to cloud services can route through it, they often grow into a surprisingly large line item.
Security & supply chain
How security is built into the pipeline, and how teams prove what they ship is what they built.
DevSecOps
DevSecOps is the practice of integrating security into every stage of the DevOps lifecycle, from the first commit to production runtime, making it a shared responsibility of every engineer rather than a gate a separate team enforces at the end.
Shift left
Shift left is moving security and quality checks earlier in the delivery timeline, into the editor, the pull request and continuous integration, where problems are cheapest to fix. Done well, it moves fast, accurate feedback to developers, not the whole security workload.
Static application security testing (SAST)
Static application security testing (SAST) is automated analysis of source code without running it, flagging dangerous patterns such as SQL built by string concatenation, unsanitized input reaching a shell, or weak cryptography. It runs in seconds on every pull request.
Dynamic application security testing (DAST)
Dynamic application security testing (DAST) is testing the running application from the outside, like an automated penetration tester probing a deployed environment such as staging for injection and broken authentication. It finds exploitable issues that static analysis cannot see.
Software composition analysis (SCA)
Software composition analysis (SCA) is the automated inventory of an application's open-source dependencies, including transitive ones, checked against vulnerability databases. Because most applications are largely third-party code, a critical flaw often sits several dependency levels deep.
Secret scanning
Secret scanning is automatically detecting hardcoded credentials, such as API keys, passwords and tokens, before they reach a repository, and searching git history for secrets already committed. Any secret it finds should be revoked and rotated, not just deleted.
Software bill of materials (SBOM)
A software bill of materials (SBOM) is a machine-readable inventory of every component and dependency in a piece of software, in a standard format such as CycloneDX or SPDX. When a new vulnerability is disclosed, it tells you in minutes whether you are affected.
SLSA
SLSA is Supply-chain Levels for Software Artifacts, a security framework: a checklist of standards and controls, organized into levels, that prevents tampering and improves the integrity of software. Its build levels center on verifiable provenance showing how an artifact was built.
Artifact signing
Artifact signing is attaching a cryptographic signature to a build output, such as a container image or package, so anyone deploying it can verify who built it and that it has not changed since. Admission policies can then refuse anything unsigned.
OIDC federation
OIDC federation is letting a workload, such as a CI job, prove its identity with a short-lived OpenID Connect token and receive temporary cloud credentials in exchange. It removes the long-lived access keys that pipelines used to store as secrets, and that attackers target.
Policy as code
Policy as code is writing security, compliance and operational rules as version-controlled, executable policy that the pipeline or cluster enforces automatically, such as no containers running as root, no public storage and no unscanned deploys. The policy is reviewed like any other code.
Cloud security posture management (CSPM)
Cloud security posture management (CSPM) is the continuous assessment of cloud accounts and resources against security standards to find misconfigurations, such as public storage or overly broad access, and prioritize them for fixing. It shows the security state of the whole estate.
Least privilege
Least privilege is the security principle that every user, service and process gets only the minimum access it needs to perform its function, and nothing more. In cloud and CI/CD terms, that means narrowly scoped roles, short-lived credentials and no standing admin access.