EXIN DevOps Master cheat sheet

DevOps is a cultural and organizational movement that emphasizes collaboration between development and operations, breaking down silos, and sharing responsibility for the entire service lifecycle.

The Three Ways of DevOps: (1) Flow (accelerate delivery from Dev to Ops to customer), (2) Feedback (amplify feedback loops), (3) Continual Learning and Experimentation (foster a learning culture).

CALMS framework: Culture, Automation, Lean, Measurement, Sharing. Used to assess DevOps readiness and guide adoption.

DevOps adoption maturity models typically progress through stages: initial, repeatable, defined, managed, optimizing. No single official model exists; organizations tailor assessments.

Key adoption metrics: deployment frequency, lead time for changes, change failure rate, mean time to restore (MTTR). These are the four key metrics from Accelerate/DORA research.

Cultural enablers: blameless postmortems, psychological safety, cross-functional teams, shared goals and incentives, and leadership support.

Common adoption anti-patterns: creating a separate DevOps team (silo), automating without cultural change, focusing only on tools, and ignoring measurement.

Value stream mapping is used to identify waste and bottlenecks in the delivery process; it is a fundamental Lean technique applied in DevOps adoption.

Agile planning uses iterative cycles (sprints) with prioritized backlogs; DevOps extends this by integrating operations and security requirements early (shift-left).

Definition of Done (DoD) must include operational criteria: automated tests pass, security scans clean, monitoring configured, and deployment pipeline validated.

Non-functional requirements (NFRs) such as performance, security, scalability, and reliability must be captured as user stories with acceptance criteria and validated continuously.

Infrastructure as Code (IaC) design: treat infrastructure configurations as versioned code, with idempotent provisioning, peer review, and automated testing.

Microservices design principles: single responsibility, bounded context, decentralized data management, API contracts, and independent deployability.

Twelve-Factor App methodology guides cloud-native design: codebase, dependencies, config, backing services, build/release/run, processes, port binding, concurrency, disposability, dev/prod parity, logs, admin processes.

Continuous delivery pipelines are designed as code (pipeline as code) and versioned alongside application code; stages typically include build, test, security scan, deploy to staging, and production.

Release planning includes feature toggles, blue-green deployment, and canary releases to reduce risk; rollback strategies must be defined before deployment.

Trunk-based development: developers commit to a single shared branch frequently (at least daily), using short-lived feature branches and feature flags to hide incomplete work.

Continuous Integration (CI) requires automated build and test on every commit; a failing build is treated as a stop-the-line event.

Continuous Delivery (CD) ensures the software is always in a deployable state; Continuous Deployment automatically releases every change that passes tests to production.

Deployment patterns: blue-green (switch traffic between two identical environments), canary (route a small percentage of traffic to new version), rolling update (incrementally replace instances).

Automated testing pyramid: unit tests (fast, many), service/API tests (medium), UI/end-to-end tests (slow, few). Test automation is a prerequisite for CD.

Version control everything: application code, infrastructure code, configuration, pipeline definitions, and database migration scripts.

Database changes in DevOps: use migration scripts, backward-compatible schema changes, and decouple database deployment from application deployment.

Security in the pipeline (DevSecOps): static application security testing (SAST), dynamic analysis (DAST), dependency scanning, and secrets management integrated into CI/CD.

Observability relies on three pillars: logs, metrics, and traces. Instrument applications to emit these signals; use centralized platforms for analysis.

Service Level Indicators (SLIs) are quantitative measures (e.g., latency, error rate). Service Level Objectives (SLOs) are target ranges for SLIs. Service Level Agreements (SLAs) are contracts with consequences.

Error budgets: the acceptable amount of unreliability (1 - SLO). When the budget is exhausted, prioritize reliability work over new features.

Incident management: define severity levels, on-call rotations, runbooks, and a blameless postmortem process that identifies root causes and action items.

Auto-scaling and elastic infrastructure: scale horizontally (add instances) or vertically (increase resources); use metrics-based triggers and define scaling policies with cool-down periods.

Capacity planning uses historical data and load testing to forecast resource needs; chaos engineering experiments validate resilience under failure conditions.

Configuration management and immutable infrastructure: replace servers rather than mutate them; use tools like Terraform, Ansible, or Kubernetes to maintain desired state.

Continuous monitoring includes application performance monitoring (APM), infrastructure monitoring, and business KPIs; alerting should be actionable and tied to SLOs.