JNCIS-DevOps key terms

A collaborative approach in which development and operations teams share responsibility for building, deploying, and running software, emphasizing automation, fast feedback, and continuous improvement over handoffs between siloed groups.

A model describing DevOps maturity through five dimensions: Culture, Automation, Lean, Measurement, and Sharing. It is used to assess where an organization stands and to guide improvement efforts beyond tooling alone.

A structured review after an incident that focuses on systemic causes and process gaps rather than punishing individuals, so people report details honestly and the organization learns and prevents recurrence.

A technique that diagrams every step from a customer request to delivered value, measuring waiting time and work time at each stage to expose waste and bottlenecks in the delivery process.

The total elapsed time from when a change is requested or committed until it is running in production. It is a core delivery metric and a common indicator of process efficiency.

How often an organization successfully releases changes to production. Along with lead time, change failure rate, and time to restore, it forms the four widely used software delivery performance metrics.

The percentage of production changes that cause degraded service and require remediation such as a rollback, hotfix, or incident response. It measures the quality and stability of the delivery pipeline.

The average time needed to recover service after an incident or failed change. It reflects operational resilience and response capability more than the frequency of failures themselves.

A practice where developers merge code changes into a shared mainline frequently, and each merge triggers an automated build and test run so integration defects surface quickly and cheaply.

A practice that keeps software in a state where it can be released to production at any time, using automated build, test, and deployment stages, while the actual release decision may remain manual.

An extension of continuous delivery in which every change that passes all automated gates is released to production automatically, with no manual approval step in the path.

An automated sequence of stages, such as checkout, compile, unit test, package, and deploy, that a change passes through. Each stage acts as a quality gate before the next begins.

A versioned store for build outputs such as packages, container images, and binaries, so that the exact artifact tested is the one deployed and can be retrieved for rollback or audit.

A branching model in which developers commit to a single shared mainline in small, frequent increments, using short-lived branches and feature flags to keep the trunk always releasable.

A configuration switch that enables or disables functionality at runtime without redeploying code, allowing progressive rollout, A/B testing, and rapid disabling of a faulty feature.

A release technique that runs two identical environments, directing traffic to one while the other is updated. After verification, traffic is switched, and rollback means switching back.

A release pattern that sends a small portion of live traffic to a new version first, monitors error rates and latency, then gradually increases traffic if health indicators remain acceptable.

The act of reverting a deployment to a previously known-good version or configuration when a new release misbehaves, ideally automated and fast to limit user impact.

The use of scripts and frameworks to execute tests such as unit, integration, and smoke tests without manual effort, providing fast, repeatable verification that gates pipeline stages.

Managing networks, servers, and cloud resources through machine-readable definition files stored in version control, so environments are reproducible, reviewable, and provisioned consistently rather than configured by hand.

A style of defining the desired end state of a system, such as a set of network interfaces or resources, and letting a tool determine the steps needed to reach it.

An approach that specifies the exact sequence of commands or steps to execute in order to reach a result, giving fine control but requiring the author to handle ordering and error conditions.

A property of an operation that produces the same result whether run once or many times. It lets automation safely reapply configuration without duplicating resources or causing unintended changes.

The gradual divergence between the actual state of systems and their intended defined state, caused by manual changes or ad hoc fixes. Detection and remediation are central goals of infrastructure automation.

The practice and tooling used to define, apply, and enforce consistent settings across servers and network devices, such as packages, services, and interface parameters, at scale.

A recurring process in which an automation tool compares the current state of a device or host against the declared target and corrects any differences, keeping systems converged over time.

Automated checks that validate infrastructure or network configuration before or after deployment, including syntax validation, policy checks, and post-deployment verification of reachability and state.

Expressing organizational and security rules as versioned, machine-enforced definitions that pipelines evaluate automatically, so compliance checks are consistent, auditable, and applied before changes reach production.

The ability to configure and control network devices and services through APIs and software rather than only manual CLI sessions, enabling automation, templating, and integration with orchestration systems.

A network management protocol that uses XML-encoded remote procedure calls over a secure transport to retrieve and edit device configuration in a structured, transactional way.

A data modeling language that defines the structure, types, and constraints of configuration and state data for network devices, commonly used with NETCONF and RESTCONF.

An HTTP-based interface exposing resources that clients manipulate with standard methods such as GET and POST, widely used to automate controllers, cloud platforms, and network devices.

The degree to which the internal state of a system can be inferred from its external outputs, typically logs, metrics, and traces, enabling teams to diagnose novel problems without shipping new code.

Numeric measurements collected over time, such as CPU utilization, interface error counts, or request latency, usually aggregated into time series for alerting and trend analysis.

A technique that follows a single request across services by propagating a shared trace identifier, revealing where latency and errors occur in a multi-service call path.

A target range for a measured service characteristic, such as 99.9 percent availability over 30 days, used to judge whether reliability is acceptable and to prioritize engineering work.

A precisely defined quantitative measure of service behavior, such as the proportion of successful requests or the fraction of requests served under a latency threshold, used to evaluate objectives.

The amount of unreliability an objective permits, calculated as one minus the target over a period. Spending it on releases is allowed; exhausting it triggers a reliability freeze.

Desensitization caused by too many low-value or duplicate alerts, leading responders to ignore or delay action on notifications, including ones that signal genuine outages.

The coordinated process of detecting, declaring, triaging, communicating about, and resolving service disruptions, with defined roles and escalation paths to reduce time to restore.

A model in which servers or devices are replaced with newly built instances rather than modified in place, eliminating configuration drift and making deployments predictable and reversible.