EXIN DevOps Master key terms

A cultural and professional movement that removes barriers between software development and IT operations, emphasizing shared ownership, automation, measurement, and continuous feedback so that value reaches users quickly and reliably.

A five-part reference model for assessing DevOps readiness: Culture, Automation, Lean, Measurement, and Sharing. It is used as a diagnostic checklist when planning an adoption journey rather than as a prescriptive standard.

The end-to-end sequence of activities that turns a customer request into delivered value, including wait time, handoffs, and rework. Mapping it exposes where lead time is consumed outside actual work.

A Lean technique that visualizes each step, queue, and decision in a value stream, annotates cycle and wait times, and identifies waste. In DevOps it typically precedes automation so effort targets the real constraint.

The elapsed time from a customer request or change being raised until it is running in production. It is a primary flow metric because it reflects the whole system, not just coding speed.

The time a work item spends actively being processed from start to finish of a defined stage, excluding time waiting in queues. Teams use it to forecast throughput and spot bottlenecks.

The smooth, uninterrupted movement of work through the delivery system with minimal batching and queueing. Improving flow reduces lead time and makes delivery more predictable without adding staff.

A cap on the number of items allowed in a workflow stage at once. Limiting work in progress exposes bottlenecks, shortens queues, and encourages finishing work before starting more.

A visual pull-based method for managing work using a board of columns representing stages, with explicit limits on work in progress. It is often the first step when introducing DevOps into an operations team.

Any activity that consumes effort or time without adding customer value, such as waiting, handoffs, rework, partially done work, and unnecessary approvals. Lean DevOps adoption starts by identifying and removing it.

The principle that a system's throughput is limited by its single tightest bottleneck, so improvement effort should focus there first. Widening non-constraints does not raise overall delivery capacity.

A structured review after an incident that focuses on systemic causes and contributing conditions rather than individual fault. Its goal is learning and prevention, which requires psychological safety to work.

A working environment where people can report mistakes and near misses openly because the response targets process and system causes, not punishment. It underpins fast detection and honest incident analysis.

The shared belief that raising concerns, admitting uncertainty, or reporting failure will not lead to humiliation or retaliation. Teams with it surface problems earlier, which shortens feedback loops.

An organization that continuously improves by turning experience into shared knowledge through experimentation, review, and documentation. In DevOps it is expressed through communities of practice and deliberate knowledge sharing.

A phased, prioritized plan describing which practices, tooling, and cultural changes an organization will introduce, in what order, with which success measures and owners. It sequences change to match business goals and current maturity.

A staged reference describing increasing capability levels, used to assess where an organization stands and what to improve next. It should guide direction, not become a compliance checklist or a scoreboard.

The structured approach to helping people adopt new ways of working, addressing motivation, skills, incentives, and resistance. Tooling changes fail without it, so it is planned alongside technical work.

The smallest release that delivers real value and generates validated learning from actual users. It is a learning instrument for deciding what to build next, not merely a reduced-scope release.

An ordered list of desired outcomes, features, and technical work, refined continuously and prioritized by value and risk. Items stay small enough to complete within a short iteration or flow step.

A short, user-centered description of a need, typically stating role, goal, and benefit, plus acceptance criteria. It is a placeholder for a conversation rather than a complete specification.

An agreed checklist describing what must be true before work counts as complete, such as tests passing, documentation updated, and deployability confirmed. It makes quality expectations explicit and consistent across the team.

A constraint or quality attribute such as performance, availability, security, or recoverability, rather than a behavior. These requirements drive architecture and operations design and must be testable.

Just enough intentional technical structure to support near-term features without repeated redesign, while leaving room to evolve. Too little runway slows delivery; too much creates unused complexity.

An architectural style decomposing a system into independently deployable services organized around business capabilities and communicating over well-defined interfaces. It enables autonomous teams but raises operational complexity.

A system that records changes to files over time so any version can be retrieved, compared, or restored. Everything needed to build and deploy, including configuration and scripts, should be kept under it.

A branching approach where developers integrate small changes into a single shared mainline frequently, using short-lived branches if any. It reduces merge pain and keeps the mainline continuously releasable.

The practice of merging all working copies into a shared mainline several times a day, with each merge verified by an automated build and test run. It surfaces integration defects within minutes.

An automated sequence that compiles, tests, packages, and verifies a change as it moves toward release, failing fast at the earliest stage. It provides consistent, repeatable evidence of quality.

Using scripts and tooling to execute tests without manual intervention, typically layered across unit, integration, and acceptance levels. It makes fast, repeatable verification possible and is a prerequisite for frequent releases.

A guideline for test portfolios: many fast, isolated unit tests at the base, fewer integration tests in the middle, and few slow end-to-end tests at the top. It keeps feedback fast and maintenance cost low.

A discipline in which software is always in a deployable state, with every change passing automated verification and a push-button release to production. Deployment remains a business decision, not a technical hurdle.

An extension of continuous delivery in which every change that passes automated verification is released to production automatically, without a human gate. It requires strong monitoring and fast rollback capability.

The end-to-end automated path a change travels from commit to production, including build, test, and release stages with quality gates. It is the mechanism that makes delivery repeatable and auditable.

Managing servers, networks, and platform configuration through versioned machine-readable definition files rather than manual setup. It makes environments reproducible, reviewable, and consistent across stages.

The practice of defining and enforcing the desired state of systems and their settings automatically, so drift is detected and corrected. It keeps environments consistent and reduces configuration-related failures.

An approach where servers or containers are never modified after deployment; changes are made by replacing them with newly built instances. It eliminates configuration drift and simplifies rollback.

A lightweight, isolated runtime package bundling an application with its dependencies so it runs consistently across environments. Containers speed deployment and support immutable, replaceable units of software.

Keeping development, test, and production environments sufficiently similar in configuration and dependencies that behavior observed earlier predicts production behavior. Gaps here cause the classic works-on-my-machine failure.

A runtime switch that enables or disables functionality without redeploying code. It decouples deployment from release, supports gradual rollout, and lets incomplete work ship safely behind a flag.

A gradual rollout in which a new version is exposed to a small subset of traffic first, with monitoring, before wider release. It limits blast radius and provides real-world evidence before full adoption.

Running two identical production environments and switching traffic from the live one to the newly prepared one. It enables near-instant rollback by switching traffic back if problems appear.

Restoring the previous known-good version or configuration after a failed change. Fast, tested rollback reduces the risk of releasing and is a design requirement, not an afterthought.

The ability to infer a system's internal state from its outputs, principally logs, metrics, and traces. Good observability lets teams diagnose novel problems without shipping new code to investigate.

Collecting and alerting on known signals such as availability, latency, error rate, and resource usage against thresholds. It answers predefined questions, whereas observability supports open-ended investigation.

A carefully defined quantitative measure of service behavior, such as the proportion of requests served under a latency threshold. It is the raw measurement from which objectives and agreements are derived.

A target range for a service level indicator, for example 99.9 percent of requests succeeding over a rolling 30-day window. It expresses reliability goals in terms users and engineers can act on.

The amount of unreliability a service level objective permits within a period, derived as one minus the objective. Spending it deliberately balances release velocity against stability and guides release decisions.

The defined process for detecting, declaring, responding to, communicating about, and resolving service disruptions, including roles and escalation paths. Clear process shortens outages and reduces confusion under pressure.

Desensitization caused by too many noisy or low-value alerts, leading responders to ignore or miss genuine ones. Reducing alert volume and tying alerts to actionable symptoms restores trust in monitoring.

The accumulated cost of shortcuts and deferred improvements that make future change slower or riskier. It is managed deliberately by making it visible and allocating regular capacity to repay it.

Automatically adjusting compute capacity to match observed demand, scaling out under load and in when idle. It supports elasticity and cost control but requires health checks and sensible thresholds.

Deliberately injecting controlled failures into a system to verify that resilience mechanisms work as expected. Experiments are hypothesis-driven and bounded so they build confidence rather than cause real incidents.