ca-fdops key terms

A collaborative approach where 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 technique that charts every step from idea to customer delivery, showing wait times and handoffs so teams can find and remove the biggest delays in their delivery process.

The total elapsed time from when work is requested or committed until it reaches the customer, including queue and wait time, not just active work time.

A structured review after an incident that focuses on system and process causes rather than punishing individuals, producing action items so similar failures are less likely to recur.

Repetitive, manual operational work that scales linearly with service growth and provides little lasting value, which automation should reduce so engineers can focus on improvement.

A branching practice where developers commit small changes frequently to a single shared mainline, using short-lived branches and feature flags instead of long-running divergent branches.

A request to merge changes from one branch into another, providing a place for automated checks, peer review, and discussion before the code becomes part of the shared mainline.

A state where two sets of changes touch the same lines of a file and the version control system cannot combine them automatically, requiring a person to choose the final result.

A recorded snapshot of changes in a version control repository, identified by a unique hash and linked to a parent commit, forming the history used for review and rollback.

An operating model where the desired state of infrastructure and applications is stored declaratively in Git, and an automated controller continuously reconciles live systems to match that repository.

A practice where developers merge changes into a shared mainline often, and each merge triggers automated build and test steps so integration problems surface quickly.

The immutable output produced by a build, such as a container image or package, that is versioned and promoted through environments rather than rebuilt at each stage.

An automated sequence of stages, such as build, test, scan, and deploy, that moves a code change from commit toward production with consistent, repeatable checks at each step.

Using scripts and frameworks to run unit, integration, and other checks without manual effort, giving fast and repeatable feedback on every change in the pipeline.

A practice where every validated change is kept in a deployable state and can be released to production at any time, with the final release decision often made by a human.

An extension of continuous delivery where every change that passes all automated checks is released to production automatically, with no manual approval step.

A release technique that runs two identical environments and switches traffic from the old version to the new one, allowing fast rollback by switching traffic back.

A release strategy that sends a small share of live traffic to a new version first, monitors health and error rates, then gradually increases exposure if results look good.

Restoring a previously known-good version of an application or configuration after a failed change, ideally as an automated and fast operation rather than a manual rebuild.

A configuration switch in code that turns functionality on or off at runtime for selected users, letting teams deploy code without immediately exposing it to everyone.

A delivery metric counting how often an organization successfully releases to production, where higher frequency usually signals smaller batches and lower release risk.

Managing servers, networks, and platform resources through versioned machine-readable definition files instead of manual console actions, so environments are reproducible, reviewable, and consistent.

Describing the desired end state of a system, such as three running instances, and letting a tool determine the actions needed, rather than scripting each step explicitly.

A property where applying the same operation multiple times produces the same result as applying it once, which makes configuration runs safe to repeat after partial failures.

The gradual divergence between the documented or coded desired state of an environment and its actual state, often caused by manual hotfixes and ad hoc changes.

A model where servers or containers are never patched in place; instead a new versioned instance replaces the old one, reducing drift and making rollbacks predictable.

An isolated process packaged with its own filesystem and dependencies that shares the host operating system kernel, giving consistent runtime behavior across environments with low overhead.

A read-only, layered template containing an application and its dependencies, built once and used to start containers, identified by a tag or digest for traceability.

A service that stores and distributes container images by name and tag, acting as the source from which orchestration platforms pull images to run workloads.

Automated scheduling and management of many containers, covering placement, scaling, networking, health checks, and restarts so operators declare intent rather than manage hosts individually.

An open-source container orchestration platform that reconciles declared resources such as Deployments and Services against observed cluster state, providing scheduling, scaling, and self-healing.

A cloud division of duties where the provider secures the underlying physical and virtual infrastructure while the customer secures their data, identities, configurations, and applications.

A cloud offering where the provider handles provisioning, patching, scaling, and backups for a component such as a database or queue, leaving the customer to configure and use it.

Automatically adjusting the number of running instances or resource capacity based on measured demand or a schedule, keeping performance acceptable while controlling cost.

A component that distributes incoming requests across multiple backend instances, improving availability and enabling techniques such as blue-green and canary traffic shifting.

A target range for a measured reliability indicator, such as 99.9 percent successful requests over 30 days, used to judge whether service health is acceptable.

A quantitative measure of service behavior, such as request latency or error ratio, that is compared against an objective to determine whether reliability targets are being met.

The allowed amount of unreliability implied by an objective, for example 0.1 percent of a month, which teams spend on riskier releases and freeze when exhausted.

The degree to which a system's internal state can be inferred from its outputs, typically by correlating metrics, logs, and traces to answer novel questions without new code.

Recording a single request's path across multiple services using shared trace identifiers and spans, so teams can locate latency and failures in complex call chains.

The desensitization that occurs when monitoring generates too many low-value or duplicate alerts, causing responders to ignore or delay reaction to genuine incidents.

A documented, step-by-step procedure for handling a specific operational task or alert, kept current so responders can act quickly and consistently under pressure.

A defined ranking of how much an incident affects users and the business, used to set response urgency, escalation paths, and communication cadence.

The share of production changes that cause a degraded service or require remediation such as a rollback or hotfix, indicating release quality and test effectiveness.

Granting identities only the permissions needed for their specific task and no more, limiting the blast radius if credentials leak or a component is compromised.

Storing and distributing credentials such as passwords, tokens, and keys in a controlled vault with access auditing and rotation, instead of hardcoding them in code or images.

Automated analysis of source code or compiled binaries for insecure patterns without running the program, often embedded in the pipeline to catch issues before merge.

Scanning third-party libraries and dependencies for known vulnerabilities and license issues, producing a bill of materials so teams can patch or replace risky components.

An authorization model that assigns permissions to roles and then binds users or service accounts to those roles, simplifying administration and audit of who can do what.