Practice & Reference · Glossary
Glossary
Every term this course leans on without stopping to define it mid-lesson, gathered into one alphabetical, searchable page — branching models, deployment strategies, the DORA metrics, Kubernetes objects, and the vocabulary of on-call and incident response.
☺ Explain it like I'm 10
If a lesson uses a word you don't recognize — GitOps, MTTR, sidecar — it's defined here in one or two sentences, not buried three paragraphs into a page you've already left. Search the box below or scan the list; nothing here assumes you already know the acronym.
Artifact promotionMoving one immutable, already-built artifact through successive environments — dev, staging, production — unchanged, rather than rebuilding it at each stage, so what's tested in staging is provably the same binary or image that reaches production.
Artifact repositoryA versioned store for build outputs — compiled binaries, packages, container images — that a pipeline publishes to after a successful build and that later deployment stages pull from. Artifactory, Nexus, and a container registry are common examples.
Blameless cultureTreating an incident's cause as a systems and process failure rather than an individual's mistake, so people report and diagnose honestly instead of covering up. A precondition for postmortems that surface real root cause instead of a scapegoat.
Blue-green deploymentA deployment strategy that runs two identical production environments, "blue" (currently live) and "green" (the new version). Once green passes checks, a router or load balancer cuts all traffic over at once, and blue stays warm as an instant rollback target.
CALMSAn acronym for the five pillars this course keeps returning to: Culture, Automation, Lean, Measurement, and Sharing. Extended by Jez Humble and Damon Edwards from the earlier CAMS coinage by Patrick Debois and Andrew Clay Shafer.
Canary releaseA deployment strategy that routes a small percentage of production traffic to the new version while the rest keeps serving the old one, so a regression is caught while it can only harm a fraction of users, before traffic is ramped up or rolled back.
Change failure rateA DORA metric: the percentage of deployments to production that result in a degraded service and require remediation — a hotfix, rollback, or patch.
Chaos engineeringDeliberately injecting failure into a production or production-like system — killing an instance, adding network latency — to verify the system degrades and recovers the way it's assumed to, before a real failure proves the assumption wrong.
ChatOpsRunning operational commands — deploys, rollbacks, incident actions — from a chat platform like Slack via a bot, so the command and its result are visible to the whole team in real time instead of hidden in one engineer's terminal.
Configuration driftThe gradual divergence between a system's actual running configuration and its documented or declared configuration, typically caused by untracked manual changes. The core problem immutable infrastructure and configuration management both exist to eliminate.
ContainerA lightweight, portable unit that packages an application with its dependencies and shares the host machine's OS kernel, so it starts in milliseconds and behaves the same on a laptop, a CI runner, and a production host. Docker popularized the format.
Continuous DeliveryExtending Continuous Integration so that every change that passes the pipeline produces a release candidate that is always in a deployable state. A human still decides when to push the button and release it to production.
Continuous DeploymentExtending Continuous Delivery one step further: every change that passes the pipeline is released to production automatically, with no manual approval gate.
Continuous IntegrationThe practice of merging every developer's changes into a shared trunk multiple times a day, with an automated build and test suite running on each merge so integration problems surface within minutes rather than weeks.
Conway's LawMelvin Conway's 1968 observation that any system an organization designs mirrors that organization's own communication structure. In DevOps it explains why cross-functional, autonomous teams tend to produce loosely coupled services, while siloed org charts tend to produce siloed, tightly coupled ones.
Declarative vs. imperativeTwo ways to express a desired change: declarative states the end goal ("three replicas should exist") and lets a tool figure out how to get there; imperative states the exact steps to run in order. Most modern IaC and orchestration tools default to declarative.
Deployment frequencyA DORA metric: how often an organization successfully releases to production. Elite performers deploy on demand, multiple times a day; low performers deploy less than once a month.
DORA metricsThe four software delivery performance metrics identified by Google's DevOps Research and Assessment team: deployment frequency, lead time for changes, change failure rate, and time to restore service. See measuring success.
Error budgetThe maximum amount of unreliability a service is allowed before it breaches its SLO, expressed as 100% minus the SLO. As long as budget remains, teams can ship features and take risk; once it's exhausted, the team shifts focus to reliability work instead of new features.
Feature flagA runtime switch that turns a code path on or off without a redeploy, decoupling code deployment from feature release. Lets a team ship dark, test in production, and roll back a bad feature by flipping a flag instead of reverting a deploy.
GitFlowA branching model with parallel long-lived branches — develop, main, feature, release, and hotfix — built for scheduled, versioned releases. Its overhead is a poor fit for teams that deploy continuously.
GitHub FlowA lightweight branching model: branch from main for any change, open a pull request, review, merge, deploy. Simpler than GitFlow and closer to trunk-based development, with no separate release or hotfix branch types.
GitOpsAn operating model that uses a Git repository as the single source of truth for declarative infrastructure and application state. An agent such as Argo CD or Flux continuously reconciles the live system to match what's committed, and every change ships as a pull request.
Golden pathA supported, opinionated, well-documented way to accomplish a common task — spin up a new service, add a database — that a platform team builds and maintains. Teams can go around it, but the golden path is the one route guaranteed to work and get help when it breaks.
Golden signals (the four)Google's SRE-book shortlist of the four metrics worth watching on nearly any user-facing service: latency, traffic, errors, and saturation. A useful minimum viable dashboard for a new service.
IdempotencyThe property of an operation that produces the same end state no matter how many times it's applied. Configuration management tools rely on it so re-running a playbook or manifest against an already-correct system is a safe no-op, not a repeated side effect.
Immutable infrastructureAn approach where servers or containers are never patched or modified in place. A new image is built from the desired state and the old instance is replaced outright, eliminating configuration drift by construction.
Incident commanderThe person who takes charge of coordinating an active incident response — assigning roles, making calls under uncertainty, communicating status — so responders can focus on diagnosis and mitigation instead of coordination.
Infrastructure as Code (IaC)Defining and provisioning infrastructure through versioned, declarative or imperative text files — Terraform, CloudFormation, Ansible — instead of manual console clicks, so infrastructure changes get the same review, diff, and rollback discipline as application code.
Kubernetes DeploymentA Kubernetes object that manages a set of identical Pods via a ReplicaSet, handling rolling updates, rollbacks, and scaling declaratively. You describe the desired Pod count and image version; the controller reconciles reality to match.
Kubernetes PodThe smallest deployable unit in Kubernetes: one or more tightly coupled containers that share networking and storage and are always scheduled onto the same node together.
Kubernetes ServiceA stable network endpoint — a fixed IP and DNS name — that load-balances traffic across a changing set of Pods, so callers don't need to track individual Pod IPs as Pods are created, destroyed, and rescheduled.
Lead time for changesA DORA metric: the time from a code commit to that code running in production. Elite performers measure it in under an hour; low performers in months.
Liveness probeA Kubernetes health check that determines whether a container is still functioning. A container that fails its liveness probe is killed and restarted by the kubelet, on the assumption that a restart is more likely to fix it than leaving it running.
MonitoringWatching a predefined set of metrics and thresholds and alerting when they're crossed. Answers known questions ("is CPU above 90%?") but, unlike observability, doesn't help you investigate a failure mode nobody thought to dashboard in advance.
MonorepoA single version-control repository holding the source for many, often all, of an organization's projects and services. Simplifies cross-project changes and shared tooling at the cost of needing more sophisticated build and CI tooling to scale.
MTTD (mean time to detect)The average time between a problem actually starting and someone or something noticing it. A low MTTD depends on good monitoring and alerting, and directly caps how low MTTR can go, since you can't fix what you haven't detected.
MTTR (mean time to restore)The average time from an incident starting to service being restored. DORA now labels the equivalent concept "time to restore service" in its own reporting, but MTTR remains the common shorthand across the industry.
NoOpsThe claim that automation and managed cloud services can eliminate the need for an operations function entirely. Treated on this platform as a myth — automation removes toil, not the responsibility of someone owning production when it breaks.
ObservabilityThe property of a system that lets you infer its internal state from the signals it emits — logs, metrics, and traces — well enough to answer novel questions about failures you didn't anticipate when you instrumented it. Contrast with monitoring.
On-callA rotation in which one engineer is designated to be reachable and responsible for responding to production alerts and incidents during a defined shift, typically carrying a pager or phone alert for that window.
OrchestrationAutomated scheduling, scaling, networking, and self-healing of a fleet of containers across a cluster of machines, so operators declare desired state instead of manually placing every container. Kubernetes is the dominant orchestrator.
Pipeline as codeDefining a CI/CD pipeline's stages and steps in a version-controlled file — a Jenkinsfile, a GitHub Actions YAML workflow — that lives alongside the application code, rather than configuring the pipeline by hand through a UI.
Platform engineeringA discipline that builds and operates an internal developer platform — self-service tooling, golden paths, paved roads — so product teams can ship without becoming experts in Kubernetes, networking, or CI internals themselves.
PolyrepoSplitting an organization's projects across many separate version-control repositories, one or a few per service. Gives each team more autonomy and independent versioning at the cost of harder cross-repo changes and dependency coordination.
PostmortemA written analysis produced after an incident, covering what happened, its impact, the timeline, the root cause or causes, and follow-up action items. The primary artifact through which an organization turns an outage into a lasting fix.
Readiness probeA Kubernetes health check that determines whether a container is ready to receive traffic. A Pod that fails its readiness probe is removed from a Service's load-balancing pool until it passes again, but is not restarted.
RollbackReverting a system to its previous known-good version after a release causes a problem. How fast and how safely a team can roll back is a major factor in how much risk they can tolerate taking with each deploy.
RunbookA documented, step-by-step procedure for handling a specific operational task or known failure mode — restarting a stuck queue consumer, failing over a database — written so whoever is on call can execute it correctly under pressure without having built the system themselves.
SBOM (software bill of materials)A structured, machine-readable inventory of every component, library, and dependency in a shipped artifact, used to answer "are we affected by this CVE" quickly, and increasingly required by supply-chain security regulation.
Self-healingA system's ability to detect that a component has failed and automatically take corrective action — restarting a crashed container, rescheduling a Pod off a dead node — without a human paging in.
Semantic versioning (SemVer)A version-numbering scheme, MAJOR.MINOR.PATCH, where MAJOR increments on a breaking change, MINOR on a backward-compatible feature addition, and PATCH on a backward-compatible bug fix, so consumers can tell from the number alone whether an upgrade is safe.
Service meshAn infrastructure layer, such as Istio or Linkerd, that injects a sidecar proxy next to every service instance to handle service-to-service traffic — retries, mutual TLS, load balancing, observability — uniformly, without each application implementing it itself.
Shift-leftMoving a concern — testing, security scanning, cost review — earlier in the development lifecycle, so problems are caught while they're still cheap to fix instead of after they reach production.
Sidecar patternDeploying a helper container alongside a main application container in the same Pod to handle a cross-cutting concern — logging, proxying, TLS termination — without modifying the main container's code.
Time to restore serviceA DORA metric, and the successor name for what the DORA research originally called MTTR: how long it takes to restore service after a production incident or failed change.
ToilManual, repetitive, automatable operational work that scales linearly with service size and produces no lasting engineering value. The SRE discipline treats toil as something to be measured and driven down, not accepted as the cost of running things.
Trunk-based developmentA branching model where developers commit small, frequent changes directly to a single shared trunk, or very short-lived feature branches merged within a day, avoiding the long-lived branches and painful merges of GitFlow.
War roomA dedicated space, physical or virtual, where responders coordinate during a live incident. Increasingly a persistent chat channel plus a bridge call rather than a literal room.