EXIN DevOps Professional key terms

The organizing model of DevOps principles: optimize flow of work from development to operations, amplify fast feedback loops in both directions, and embed continual experimentation and learning into daily work.

A cultural and professional movement combining practices and tools that shorten the distance between development and operations, delivering value to customers faster, safer, and more reliably.

The end-to-end sequence of activities required to convert a customer request into delivered value, including wait time, handoffs, and rework, not just the work being actively performed.

A visual analysis technique that charts each step and its queue in a value stream to expose bottlenecks, handoffs, and percentage of time spent waiting versus working.

The elapsed clock time from when a customer request is accepted to when it is delivered, including all queueing and waiting, and the metric most visible to customers.

The portion of lead time during which work is actively being performed on an item; comparing it with lead time reveals how much delay is caused by queues.

The number of items started but not yet finished at a given point in a workflow; limiting it reduces multitasking, queue growth, and lead time.

In theory of constraints, the single step in a value stream that limits overall throughput; improving anything else before it produces no increase in delivered output.

A pull-based work management method using a visualized board, explicit WIP limits, and flow measurement to make bottlenecks and queueing visible and to smooth delivery.

A discipline in which every change is kept in a deployable state and can be released to production on demand through an automated, repeatable pipeline.

A practice where developers merge small changes into a shared mainline frequently, each merge triggering automated build and test to surface integration defects quickly.

An automated sequence of build, test, and release stages that every change passes through, giving fast feedback on quality and providing a repeatable path to production.

A branching pattern in which developers integrate to a single shared branch at least daily, using short-lived branches or feature flags rather than long-lived divergent branches.

A configuration switch that enables or disables functionality at runtime, allowing incomplete code to ship dark and releases to be decoupled from deployment.

The use of scripted, repeatable checks, especially at unit and acceptance level, so that quality feedback arrives in minutes without manual regression effort.

Managing servers, networks, and platform configuration through versioned definition files that are applied by tooling, making environments reproducible, reviewable, and auditable.

Tooling and practices that define and enforce the desired state of hosts and software, detecting and correcting drift from that declared state automatically.

An approach where servers or containers are never patched in place; instead a new image is built and deployed, and the old instance is replaced and destroyed.

How often an organization successfully releases to production; a core delivery-throughput metric that rises when batch sizes shrink and the pipeline is reliable.

The proportion of production changes that result in degraded service and require remediation such as a hotfix or rollback; a stability indicator paired with deployment frequency.

The average elapsed time from detection of a service incident to restoration of normal service, reflecting how quickly an organization detects, diagnoses, and recovers.

A structured review after an incident that assumes people acted reasonably given their information, focusing on system conditions and countermeasures rather than individual fault.

A management stance that distinguishes honest mistakes, at-risk behavior, and reckless conduct, encouraging incident reporting without punishing people for surfacing problems.

A shared belief that raising concerns, admitting errors, and asking questions will not lead to humiliation or punishment, enabling fast feedback and learning.

Shared norms and behaviors in which development and operations collaborate around shared goals, ownership extends to running software in production, and trust replaces blame.

An organizational boundary where a team optimizes its own local goals and hands work over the wall, producing queues, blame, and conflicting incentives across the delivery chain.

The third Way: institutionalizing experimentation, treating accidents as learning opportunities, and pushing knowledge from local discoveries into the wider organization.

The practice of continuous small improvements made by the people doing the work, rather than relying solely on periodic large change programs imposed from above.

A planned exercise that deliberately injects failure, such as killing a server or severing a dependency, to rehearse response and validate resilience in a safe setting.

The disciplined practice of running controlled experiments on a production-like system to discover weaknesses before they cause unplanned outages.

The degree to which a system's internal state can be inferred from its outputs, typically through correlated logs, metrics, and traces, enabling fast diagnosis of incidents.

The automated collection and transmission of runtime data such as metrics, logs, and traces from running systems to monitoring and analysis platforms.

A mechanism by which information about the effect of an action returns quickly to the person or system that acted, enabling correction before problems compound.

Releasing two variants to different user segments and comparing outcomes statistically, so product decisions rest on observed behavior rather than opinion.

A mechanism, borrowed from lean manufacturing, that lets any worker stop the line when a defect is detected, so problems are fixed immediately rather than passed downstream.

The authority and obligation of any team member to halt work when a quality or safety problem appears, prioritizing root-cause resolution over output volume.

An engineering discipline that applies software engineering to operations problems, using service level objectives, error budgets, and automation to balance reliability with change.

The amount of unreliability a service may exhibit, derived from its service level objective, which teams spend on releases and experiments and which triggers a change freeze when exhausted.

A target range for a measured reliability indicator, such as the proportion of requests served under a latency threshold, used to judge whether service is acceptable.

Manual, repetitive, automatable operational work that scales linearly with service growth and provides no lasting value, which SRE teams deliberately limit.