CDOS key terms

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 faster.

A technique that charts every step from a customer request to delivered value, measuring wait and work time at each stage to expose where flow stalls and where to improve.

The total elapsed time from when a change is committed to when it runs in production. It is a core delivery metric because it captures queueing and handoff delays, not just coding speed.

How often an organization successfully releases to production. Frequent small releases correlate with smaller risk per change, faster feedback, and easier rollback than infrequent large batches.

The share of production changes that cause degraded service and require remediation such as a rollback, hotfix, or emergency patch. It measures the quality of the delivery pipeline.

A branching model where developers commit small changes to a single shared mainline at least daily, using short-lived branches and feature flags to hide unfinished work.

A state where two branches modify the same lines of a file and the version control system cannot reconcile them automatically, requiring a human to choose the final content.

A proposal to merge changes from one branch into another that supports review, automated checks, and discussion before integration, creating an auditable record of who approved what.

A repository setting that blocks direct pushes to important branches and can require passing status checks, reviews, and up-to-date branches before a merge is allowed.

A commit whose authorship is cryptographically verified, typically with a GPG or SSH key, so reviewers and automation can trust that the stated author actually produced the change.

The immutable output of a build, such as a compiled binary, container image, or package, stored in a repository and promoted through environments without being rebuilt.

A versioned store for build outputs and dependencies, such as a package registry or image registry, that supports retention policies, access control, and retrieval by digest.

Defining build, test, and deploy steps in a version-controlled file rather than configuring them in a user interface, so the pipeline is reviewed, tested, and reproduced like application code.

A guideline for test investment: many fast unit tests at the base, fewer integration tests in the middle, and a small number of slow end-to-end tests at the top.

A shallow, fast check that a deployed build starts and its critical paths respond, used to reject obviously broken artifacts before running deeper test suites.

A practice where every validated change is kept in a deployable state and can be released to production on demand through an automated, repeatable process.

The property that running an operation repeatedly produces the same end state as running it once, which makes retries safe and configuration runs predictable.

The declared target configuration of a system. A configuration management tool compares actual state to this declaration and converges the system toward it.

Periodically comparing live infrastructure against its declared configuration to find manual or out-of-band changes, then reporting or reconciling the differences.

An approach where servers or containers are never patched in place; instead a new image is built and replaces the old one, eliminating configuration drift and making rollback a redeploy.

A packaged, layered filesystem plus metadata that contains an application and its dependencies, identified by a content digest and runnable by a container runtime.

The smallest deployable unit in Kubernetes, wrapping one or more tightly coupled containers that share a network namespace, storage volumes, and a scheduling lifecycle.

A Kubernetes controller that adjusts the number of pod replicas based on observed metrics such as CPU utilization or custom signals, within configured minimum and maximum bounds.

A periodic check that tells Kubernetes whether a container can serve traffic. Failing pods are removed from service endpoints without being restarted.

Managing servers, networks, and platform resources through versioned definition files applied by tooling, so environments are reproducible, reviewable, and consistent across accounts.

Granting identities only the permissions needed for their specific task and no more, which limits blast radius when credentials leak or automation misbehaves.

Storing and distributing credentials, tokens, and keys in a dedicated encrypted system with rotation, audit logging, and scoped access, rather than in source code or plain environment files.

Running two identical environments and switching traffic from the live one to the newly deployed one after validation, enabling near-instant rollback by switching back.

Sending a small slice of production traffic to a new version while monitoring error rates and latency, then gradually increasing exposure or reverting if signals degrade.

A runtime switch that enables or disables functionality without redeploying, allowing decoupling of release from deployment and fast disabling of a faulty path.

Restoring the previously known-good version or configuration after a failed change, ideally automated and fast enough that recovery time stays within agreed targets.

The amount of unreliability a service may accumulate within a period, derived from its service level objective, used to balance release velocity against stability work.

A measurable target for a reliability or performance indicator, such as the percentage of requests served under a latency threshold, used to judge whether service is acceptable.

Recording a single request's path across services with shared trace and span identifiers, so engineers can attribute latency and errors to a specific component.

Emitting log records as machine-parsable key-value or JSON data with consistent fields, enabling reliable filtering, aggregation, and correlation instead of fragile text parsing.

Desensitization caused by too many low-value or noisy alerts, leading responders to ignore or delay action on signals that genuinely matter.

The person who coordinates response during an incident, owns decisions and communication, and delegates technical work rather than debugging personally.

The full set of code, dependencies, build systems, and registries that produce a released artifact; securing it means verifying provenance and scanning each link.