DevOps Foundation cheat sheet

DevOps combines a cultural philosophy, practices and tools that increase an organization's ability to deliver applications and services at high velocity while improving reliability.

The term was popularized in 2009 by Patrick Debois and Andrew Clay Shafer; the first DevOpsDays was held in Ghent, Belgium in October 2009.

CALMS model dimensions: Culture, Automation, Lean, Measurement, Sharing - used to assess adoption across both human and technical dimensions.

The Three Ways (Gene Kim): (1) flow of work left to right, (2) fast feedback right to left, (3) continual experimentation and learning.

Primary target outcomes: faster time to market, higher deployment frequency, shorter lead time, lower change failure rate, faster time to restore service.

DevOps is not a job title or a single tool; creating a named 'DevOps team' typically reintroduces the silo it was meant to remove.

Agile focuses on development flow and iterative planning; DevOps extends the same thinking through delivery, operations and production feedback.

SRE (originating at Google) is an implementation of DevOps using service level objectives, error budgets and toil reduction.

The 'wall of confusion' is the classic symptom of separated development and operations, where work is thrown over the wall as a handoff.

Westrum typology: pathological (power-oriented, information withheld), bureaucratic (rule-oriented, departments protected), generative (mission-oriented, information shared); generative cultures correlate with higher delivery performance.

Generative culture indicators: high cooperation, messengers are trained rather than shot, and failure leads to inquiry rather than blame.

Blameless postmortem assumes people acted rationally given the information available and targets systemic causes instead of individual punishment.

'You build it, you run it' (Werner Vogels) assigns operational responsibility to the team that wrote the code.

Psychological safety (Amy Edmondson) is a shared belief that asking questions, reporting errors and raising concerns will not lead to punishment or humiliation.

Development and operations must share one set of goals; conflicting incentives (change versus stability) recreate the wall of confusion.

Small, cross-functional, autonomous teams (the two-pizza heuristic, roughly 6-10 people) reduce handoffs and communication overhead.

Culture is reinforced by incentives, metrics and leadership modeling; tooling alone does not change behavior.

Blameless cultures usually surface more reported incidents, not fewer, because reporting is not punished.

Little's Law: average work in progress = throughput × average cycle time; reducing WIP shortens lead time without adding capacity.

Lean waste categories (DOWNTIME): Defects, Overproduction, Waiting, Non-utilized talent, Transportation, Inventory, Motion, Extra processing.

Continuous delivery keeps every change in a deployable state; continuous deployment additionally releases every change that passes all automated gates.

Deployment pipeline order: commit → build → automated tests → provisioning → production; each stage fails fast and blocks promotion.

Trunk-based development merges small changes into a shared mainline at least daily; long-lived feature branches increase merge risk and delay feedback.

Feature flags decouple deployment (code in production) from release (code visible to users), enabling dark launches and instant kill switches.

Blue-green deployment switches traffic between two identical environments; canary release routes a small traffic percentage to the new version first.

Small batch size and single-piece flow reduce variability and shorten feedback time compared with batch-and-queue releases.

Value stream mapping measures total lead time and percent complete-and-accurate (%C/A) to expose the largest bottleneck in the flow.

Infrastructure as Code stores servers, networks and configuration as versioned files; declarative tools (Terraform, CloudFormation) describe the end state, imperative scripts describe the steps.

Immutable infrastructure replaces instances rather than mutating them, eliminating configuration drift and making rollback predictable.

Test pyramid proportions: many fast unit tests, fewer integration or service tests, and very few slow end-to-end UI tests.

Three pillars of observability are metrics, logs and distributed traces; OpenTelemetry standardizes how that telemetry is collected and exported.

CI runs on every commit: build, static analysis, unit tests and artifact publication - build once, deploy many times to identical environments.

Containers package an application with its dependencies using OS-level isolation; Kubernetes schedules, scales and heals containerized workloads.

Idempotent configuration management (Ansible, Puppet, Chef) converges hosts to a desired state, so repeated runs do not accumulate unintended changes.

DevSecOps shifts security left: SAST in the IDE and pipeline, DAST against running builds, dependency/SCA scanning, and secrets held in a vault rather than in code.

Self-service internal platforms with golden paths reduce the cognitive load on product teams and standardize compliant delivery.

DORA four key metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service.

Lead time for changes measures commit to running in production; cycle time typically measures start of work to done - definitions vary, so document them locally.

Change failure rate = deployments causing degraded service ÷ total deployments, expressed as a percentage.

Service level hierarchy: SLI is the measured indicator, SLO is the internal target for that indicator, SLA is the contractual commitment with consequences.

Error budget = 1 − SLO; a 99.9% monthly SLO permits about 43 minutes of downtime in a 30-day window.

Availability = uptime ÷ (uptime + downtime), stated over a defined measurement window.

MTTR = total downtime ÷ number of incidents; MTBF = total operating time ÷ number of failures.

Goodhart's Law: once a measure becomes a target it stops being a good measure, so metrics should be paired and reviewed for gaming.

Vanity metrics (total lines of code, raw page views) look favorable but do not change decisions; prefer outcome-based, actionable measures.

The Third Way: continual experimentation and risk-taking, shortened and amplified feedback loops, and repetition/practice to master skills.

PDCA (Plan-Do-Check-Act, the Deming cycle) is the base improvement loop; Kaizen is continuous incremental improvement performed by the people doing the work.

5 Whys drills from symptom to root cause by repeatedly asking why; an A3 is a one-page structured problem-solving and proposal document.

Retrospectives at the end of each iteration inspect process and must produce a small number of owned, tracked actions to change anything.

Blameless incident reviews are only effective if resulting action items are completed; track action completion rate as a learning measure.

Chaos engineering injects controlled failures (instance kills, latency, network loss) in production-like environments to validate resilience before real outages.

Inner source applies open-source practices internally: shared repositories, visible code, contribution guidelines and mandatory peer review.

Feedback loops shorten with production telemetry, chat-ops alerting and customer usage data feeding backlog prioritization.

Communities of practice and guilds spread knowledge horizontally; documented runbooks remove single-person dependencies.