The DevOps Checklist

Building a collaborative, learning-oriented culture where teams share ownership and work towards common goals.

• We prioritize work according to business objectives and customer value. Why it matters: DevOps was born from the friction between Development (focused on change) and Operations (focused on stability). Alignment means everyone optimizes for the same outcomes.
  
  Key terms:
  • OKRs (Objectives & Key Results) — Goal-setting framework connecting team work to company strategy
  • Value Stream — The sequence of activities to deliver value to customers
  • Flow Efficiency — Ratio of active work time to total lead time Read more
  • Culture
• Teams self-organize and volunteer for tasks based on skills and interest. Why it matters: Autonomy is a key driver of intrinsic motivation (see Daniel Pink's "Drive"). Self-selecting work leads to better outcomes and higher engagement.
  
  Key terms:
  • Autonomy — Freedom to decide how to accomplish goals
  • Mastery — Desire to improve skills
  • Purpose — Connection to meaningful outcomes
  • Pull-based work — Team members pull tasks when ready vs. being assigned Read more
  • Culture
• Teams have clear objectives aligned with company vision and can explain how their work contributes. Why it matters: When teams understand the "why" behind their work, they make better decisions autonomously and stay motivated.
  
  Key terms:
  • North Star Metric — Single metric that best captures core value delivered to customers
  • Strategy Deployment (Hoshin Kanri) — Cascading goals from vision to team objectives
  • Impact Mapping — Connecting deliverables to business goals Read more
  • Culture
  • Measurement
• We focus on sustainable pace over heroics and crunch time. Why it matters: Burnout leads to turnover, mistakes, and technical debt. Sustainable velocity is faster long-term than sprints followed by exhaustion.
  
  Key terms:
  • Sustainable pace — Work rate that can be maintained indefinitely without burnout
  • Technical debt — Future cost of shortcuts taken today
  • Toil — Manual, repetitive work that should be automated Read more
  • Culture
• We optimize for Mean Time to Recovery (MTTR) over Mean Time Between Failures (MTBF). Why it matters: In complex systems, failures are inevitable. The ability to detect, respond, and recover quickly is more valuable than preventing all failures.
  
  Key terms:
  • MTTR — Mean Time to Recovery: average time to restore service
  • MTBF — Mean Time Between Failures: average time between incidents
  • Game Days — Planned exercises simulating failures (Netflix's practice)
  • Chaos Engineering — Deliberately injecting failures to build resilience Read more
  • Culture
  • Measurement
• DevOps is a shared responsibility, not a specific role or team. Why it matters: Creating a "DevOps team" often creates another silo. DevOps is about breaking down walls, not building new ones.
  
  Anti-patterns to avoid:
  • "DevOps Engineer" as a new silo between Dev and Ops
  • DevOps team that owns all pipelines and infrastructure
  • "Throw it over the wall" to the DevOps team
  
  Better approach: Embed DevOps capabilities in every team. Use Platform Engineering to provide self-service infrastructure. Read more
  • Culture
• Engineering is seen as a competitive advantage, not a cost center. Why it matters: Organizations that view IT as a cost focus on minimizing spend. Those that see it as competitive advantage invest in capabilities that drive differentiation.
  
  Signs of cost-center thinking:
  • Outsourcing core capabilities
  • Measuring success by budget reduction
  • Treating developers as interchangeable resources
  
  Signs of competitive advantage thinking:
  • Investing in developer experience
  • Building internal platforms
  • Measuring business outcomes Read more
  • Culture
• We practice blameless postmortems and treat failures as learning opportunities. Why it matters: Blame creates fear. Fear prevents people from reporting issues, taking risks, or being honest about mistakes. This leads to hidden problems and repeated failures.
  
  Key terms:
  • Blameless postmortem — Analysis focused on systems and processes, not individuals
  • Psychological safety — Team climate where people feel safe to take risks
  • Just Culture — Distinguishing between honest mistakes and negligence
  • Learning organization — Organization skilled at creating, acquiring, and transferring knowledge Read more
  • Culture
  • Sharing
• Teams are organized around products/services, not projects or functions. Why it matters: Project teams disband after delivery, losing context. Product teams maintain ownership, accumulate expertise, and are accountable for outcomes.
  
  Key terms:
  • Conway's Law — Systems mirror organization communication structures
  • Inverse Conway Maneuver — Organize teams to produce desired architecture
  • Two-Pizza Teams — Small teams (6-10 people) that can be fed by two pizzas
  • Stream-aligned teams — Teams aligned to a single flow of work (Team Topologies) Read more
  • Culture
• "You build it, you run it" — teams own their services in production. Why it matters: When developers are paged at 3 AM for their code, they write more reliable software. Ownership creates accountability.
  
  Key terms:
  • Full-cycle developers — Engineers responsible from design through production support
  • On-call rotation — Team members take turns being available for incidents
  • Service ownership — Team responsible for a service's reliability and evolution
  • Operational excellence — Systematic approach to running reliable services Read more
  • Culture

Breaking down silos through transparent communication, shared knowledge, and collaborative practices.

• Operations is involved in development planning, and developers participate in operational decisions. Why it matters: Early involvement prevents "works on my machine" surprises. Ops brings production reality to design discussions.
  
  Practices:
  • Ops attends sprint planning and backlog refinement
  • Developers participate in incident response
  • Shared on-call rotations across Dev and Ops
  • Architecture Decision Records (ADRs) reviewed by both groups Read more
  • Sharing
  • Culture
• We use ChatOps — team chat integrated with alerts, deployments, and operational tasks. Why it matters: ChatOps creates shared context. Everyone sees what's happening, can learn from others, and the chat log becomes documentation.
  
  Key terms:
  • ChatOps — Conversation-driven operations using chat tools
  • Bot commands — Triggering deployments, queries, and actions via chat
  • Observable workflow — Activities visible to the whole team
  
  Tools: Slack/Teams with integrations, Hubot, custom bots Read more
  • Sharing
• Dashboards showing system health, deployments, and metrics are accessible to everyone. Why it matters: Transparency enables autonomy. When everyone can see system state, they can make informed decisions without waiting for "the ops person."
  
  What to display:
  • Deployment status and history
  • DORA metrics (see Measurement section)
  • Current incidents and alerts
  • System health indicators (SLIs/SLOs)
  • Feature flag states
  
  Tools: Grafana, Datadog, New Relic, custom dashboards Read more
  • Sharing
  • Measurement
• Documentation is version-controlled, searchable, and maintained alongside code. Why it matters: Outdated wikis are worse than no documentation — they mislead. Documentation-as-code keeps docs accurate and discoverable.
  
  Key terms:
  • Docs-as-code — Treating documentation like source code (version control, review, CI)
  • README-driven development — Write the README first to clarify requirements
  • Architecture Decision Records (ADRs) — Documenting why decisions were made
  
  Tools: Git, Markdown, MkDocs, Docusaurus, Notion Read more
  • Sharing
• Knowledge is shared through pair programming, mob programming, or regular tech talks. Why it matters: Single points of knowledge failure (SPOF) are as dangerous as single points of infrastructure failure. Knowledge sharing prevents bus factor issues.
  
  Key terms:
  • Bus factor — Number of people who could leave before project fails
  • Pair programming — Two programmers at one workstation
  • Mob/Ensemble programming — Whole team at one computer
  • Brown bag sessions — Informal learning during lunch Read more
  • Sharing
  • Culture
• We have internal developer portals or service catalogs for discovering and understanding systems. Why it matters: In microservices architectures, understanding what exists and how to use it is critical. Service catalogs reduce cognitive load.
  
  Key terms:
  • Internal Developer Portal (IDP) — Unified interface for developer tools and services
  • Service catalog — Registry of all services with ownership and documentation
  • API catalog — Discoverable APIs with specs and examples
  
  Tools: Backstage (Spotify), Port, OpsLevel, Cortex Read more
  • Sharing
• Runbooks and playbooks exist for common operational procedures and incidents. Why it matters: During incidents, stress impairs judgment. Runbooks provide tested procedures that anyone can follow, reducing mean time to recovery.
  
  Key terms:
  • Runbook — Step-by-step guide for routine operations
  • Playbook — Guide for handling specific incident types
  • Runbook automation — Scripted runbooks that can execute automatically
  
  Best practices: Keep runbooks in version control, test them regularly, link from alerts Read more
  • Sharing

Automating repetitive tasks, building reliable pipelines, and enabling fast, safe deployments.

• All code changes go through automated CI pipeline (build, test, static analysis). Why it matters: Automated CI catches issues early when they're cheap to fix. Every commit gets validated consistently, regardless of who made it.
  
  Key terms:
  • Continuous Integration (CI) — Merging code changes frequently with automated validation
  • Build — Compiling code and creating deployable artifacts
  • Static analysis — Analyzing code without executing it (linting, type checking)
  
  Tools: GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure DevOps Read more
  • Automation
• Deployments are automated and can be triggered by developers without ops involvement. Why it matters: Manual deployments are slow, error-prone, and create bottlenecks. Self-service deployment empowers teams and speeds delivery.
  
  Key terms:
  • Continuous Delivery (CD) — Code is always deployable; deployment is a business decision
  • Continuous Deployment — Every passing commit deploys automatically
  • Push-button deployment — Single action to deploy to any environment
  
  Tools: Argo CD, Flux, Spinnaker, Octopus Deploy Read more
  • Automation
• Infrastructure is defined as code (IaC) and version controlled. Why it matters: Infrastructure as Code enables reproducibility, auditability, and disaster recovery. "ClickOps" leads to snowflake servers and configuration drift.
  
  Key terms:
  • Infrastructure as Code (IaC) — Managing infrastructure through machine-readable files
  • Declarative IaC — Describing desired state (Terraform, CloudFormation)
  • Imperative IaC — Describing steps to achieve state (Ansible, scripts)
  • GitOps — Using Git as single source of truth for infrastructure
  
  Tools: Terraform, Pulumi, AWS CDK, Crossplane, Ansible Read more
  • Automation
• Configuration is separated from code and managed through environment variables or config services. Why it matters: The same artifact should be deployable to any environment. Configuration separation enables this and prevents secrets in code.
  
  Key terms:
  • 12-Factor App — Methodology including config in environment
  • Config service — Centralized configuration management (Consul, etcd)
  • Feature flags — Runtime configuration for feature rollout
  
  Tools: HashiCorp Vault, AWS Secrets Manager, LaunchDarkly, ConfigCat Read more
  • Automation
• Deployments use immutable artifacts — same artifact in all environments. Why it matters: Building per environment introduces variability. Immutable artifacts ensure what's tested is what's deployed.
  
  Key terms:
  • Immutable artifact — Built once, deployed everywhere unchanged
  • Container image — Immutable package of application and dependencies
  • Image registry — Storage for container images
  • Promotion — Moving same artifact through environments
  
  Anti-pattern: Building different artifacts for dev, staging, production Read more
  • Automation
• We use progressive delivery techniques (canary, blue-green, feature flags). Why it matters: Big-bang deployments are risky. Progressive delivery limits blast radius and enables quick rollback.
  
  Key terms:
  • Blue-green deployment — Two identical environments, switch traffic between them
  • Canary deployment — Gradual rollout to increasing percentage of users
  • Feature flags — Toggle features on/off without deployment
  • Dark launching — Deploy code but don't activate for users
  
  Tools: Argo Rollouts, Flagger, LaunchDarkly, Split Read more
  • Automation
• Rollbacks are automated and can be executed in minutes, not hours. Why it matters: The ability to quickly undo a bad deployment reduces risk of deploying. Teams deploy more confidently when rollback is easy.
  
  Key terms:
  • Rollback — Reverting to previous known-good version
  • Roll forward — Fixing issues with a new deployment instead of reverting
  • Automatic rollback — System reverts on health check failure
  
  Best practice: Keep N previous versions deployable. Test rollbacks regularly. Read more
  • Automation
• Developers can spin up production-like environments on demand. Why it matters: Waiting for environments creates delays. Self-service environments accelerate development and testing.
  
  Key terms:
  • Ephemeral environments — Temporary environments created and destroyed automatically
  • Preview environments — Per-PR/branch environments for testing
  • Production parity — Dev environment mirrors production closely
  
  Tools: Docker Compose, Kubernetes namespaces, Vercel previews, Render Read more
  • Automation
• We practice trunk-based development with short-lived branches. Why it matters: Long-lived branches lead to painful merges and integration problems. Trunk-based development enables continuous integration.
  
  Key terms:
  • Trunk-based development — All developers commit to main/trunk frequently
  • Feature branches — Short-lived (< 1 day) branches for changes
  • Branch by abstraction — Using code to toggle incomplete features
  
  Anti-patterns: GitFlow for web apps, branches lasting weeks, release branches Read more
  • Automation

Building confidence through comprehensive automated testing and quality practices.

• We have automated unit tests with meaningful coverage. Why it matters: Unit tests provide fast feedback and document expected behavior. They're the foundation of the test pyramid.
  
  Key terms:
  • Unit test — Tests individual units of code in isolation
  • Test coverage — Percentage of code exercised by tests
  • Test pyramid — Many unit tests, fewer integration tests, fewest E2E tests
  
  Note: Coverage % is a poor goal. Focus on testing critical paths and edge cases. Read more
  • Testing
• Integration tests verify that components work together correctly. Why it matters: Unit tests pass but the system fails — integration tests catch issues at component boundaries.
  
  Key terms:
  • Integration test — Tests interaction between components
  • Contract testing — Verifying API contracts between services
  • Consumer-driven contracts — Consumers define expected behavior
  
  Tools: Pact, Spring Cloud Contract, Testcontainers Read more
  • Testing
• End-to-end tests cover critical user journeys. Why it matters: E2E tests verify the system works from the user's perspective. They catch issues that unit/integration tests miss.
  
  Key terms:
  • E2E test — Tests complete user flows through the real system
  • Critical path — Most important user journeys (login, checkout, etc.)
  • Smoke test — Quick tests verifying basic functionality
  
  Tools: Playwright, Cypress, Selenium, Puppeteer
  
  Warning: E2E tests are slow and flaky. Keep the suite focused on critical paths. Read more
  • Testing
• Tests run automatically on every commit/PR and block merging on failure. Why it matters: Tests that don't run automatically get ignored. Blocking merge on failure prevents broken code from reaching main.
  
  Key terms:
  • CI gate — Required checks before merge
  • Branch protection — Rules preventing direct commits to main
  • Required status checks — CI jobs that must pass
  
  Best practice: Fast tests in CI, slower tests can run post-merge Read more
  • Testing
  • Automation
• We test with production-like data (anonymized/synthetic if needed). Why it matters: Issues often appear with real data patterns — scale, edge cases, encoding. Testing with fake data misses these.
  
  Key terms:
  • Data masking — Hiding sensitive data while preserving patterns
  • Synthetic data — Generated data mimicking production characteristics
  • Production sampling — Subset of real anonymized data
  
  Tools: Faker libraries, Tonic, Delphix, custom masking scripts Read more
  • Testing
• Performance and load testing is part of the delivery pipeline. Why it matters: Performance issues in production are costly. Catching them before release prevents outages and bad user experience.
  
  Key terms:
  • Load testing — Testing under expected load
  • Stress testing — Testing beyond expected load to find breaking points
  • Soak testing — Testing under load for extended periods
  • Performance regression — New code making things slower
  
  Tools: k6, Gatling, Locust, JMeter, Artillery Read more
  • Testing
• We practice Chaos Engineering to test system resilience. Why it matters: You can't know how systems fail without testing failure. Chaos Engineering builds confidence in resilience.
  
  Key terms:
  • Chaos Engineering — Experimenting on systems to build confidence in capability to withstand turbulent conditions
  • Blast radius — Scope of impact from an experiment
  • Steady state hypothesis — Expected normal behavior to verify
  
  Tools: Chaos Monkey, Gremlin, Litmus, AWS Fault Injection Simulator Read more
  • Testing
• Code reviews are required for all changes. Why it matters: Code review catches bugs, spreads knowledge, maintains standards, and provides mentorship opportunities.
  
  Key terms:
  • Pull request (PR) — Request to merge changes with review
  • Code review — Peer examination of code changes
  • LGTM — "Looks Good To Me" — approval
  
  Best practices:
  • Small, focused PRs (< 400 lines)
  • Review within 24 hours
  • Use automated checks for style/formatting Read more
  • Testing

Understanding system behavior through metrics, logging, and tracing — and using data to drive decisions.

• We track DORA metrics: Deployment Frequency, Lead Time, MTTR, Change Failure Rate. Why it matters: DORA metrics are the gold standard for measuring DevOps performance, validated by years of research.
  
  Key terms:
  • Deployment Frequency — How often code deploys to production
  • Lead Time for Changes — Time from commit to production
  • Mean Time to Recovery (MTTR) — Time to recover from failures
  • Change Failure Rate — Percentage of deployments causing failures
  
  Elite performers: Deploy multiple times/day, lead time < 1 hour, MTTR < 1 hour, CFR < 15%
  
  Tools: DORA metrics plugins, Sleuth, LinearB, Faros AI Read more
  • Measurement
• We have SLIs, SLOs, and error budgets for critical services. Why it matters: SLOs balance reliability investment with feature velocity. Error budgets give teams a "reliability budget" to spend on innovation.
  
  Key terms:
  • SLI (Service Level Indicator) — Metric measuring service quality (latency, availability)
  • SLO (Service Level Objective) — Target value for an SLI (99.9% availability)
  • SLA (Service Level Agreement) — Contract with consequences for missing SLO
  • Error budget — Allowed unreliability (100% - SLO = error budget)
  
  Example: 99.9% SLO = 43.8 minutes/month error budget Read more
  • Measurement
• Applications emit structured logs that are centrally collected and searchable. Why it matters: SSH-ing into servers to grep logs doesn't scale. Centralized, structured logging enables debugging across distributed systems.
  
  Key terms:
  • Structured logging — Logs as structured data (JSON) not plain text
  • Log aggregation — Collecting logs from all sources centrally
  • Correlation ID — Identifier to trace requests across services
  
  Tools: ELK Stack, Loki + Grafana, Datadog, Splunk, CloudWatch Logs Read more
  • Measurement
• We use distributed tracing to understand request flows across services. Why it matters: In microservices, a single user request touches many services. Tracing shows the complete picture and identifies bottlenecks.
  
  Key terms:
  • Distributed tracing — Tracking requests across service boundaries
  • Span — A single operation within a trace
  • Trace — Complete request journey through all services
  • OpenTelemetry — Standard for traces, metrics, and logs
  
  Tools: Jaeger, Zipkin, Datadog APM, New Relic, Honeycomb Read more
  • Measurement
• Alerts are actionable, routed to the right team, and have runbooks attached. Why it matters: Alert fatigue kills on-call engineers and causes real incidents to be ignored. Every alert should require human action.
  
  Key terms:
  • Alert fatigue — Desensitization from too many alerts
  • Actionable alert — Alert that requires and enables human action
  • Paging — Urgent alerts requiring immediate attention
  • On-call rotation — Scheduled responsibility for responding to pages
  
  Tools: PagerDuty, Opsgenie, VictorOps, Grafana OnCall Read more
  • Measurement
• We measure and optimize developer experience and productivity. Why it matters: Developer productivity compounds. Investing in DX multiplies across every developer and every day.
  
  Key terms:
  • Developer Experience (DX) — How easy and pleasant it is to develop
  • SPACE metrics — Satisfaction, Performance, Activity, Collaboration, Efficiency
  • Time to first commit — Onboarding speed metric
  • Cognitive load — Mental effort required to work in codebase
  
  What to measure: Build times, PR cycle time, onboarding time, developer satisfaction surveys Read more
  • Measurement
• Business metrics are connected to technical changes (deployment correlation). Why it matters: Understanding how deployments affect business metrics (conversion, revenue, engagement) shows the real impact of engineering work.
  
  Key terms:
  • Deployment markers — Annotating metrics with deployment timestamps
  • A/B testing — Comparing variants with controlled experiments
  • Feature experimentation — Measuring impact of feature changes
  
  Tools: Amplitude, Mixpanel, Statsig, Eppo, custom dashboards Read more
  • Measurement

Integrating security into every stage of the development lifecycle, not as an afterthought.

• Security scanning (SAST, DAST, SCA) is integrated into CI/CD pipeline. Why it matters: Finding vulnerabilities before production is orders of magnitude cheaper than finding them after breach.
  
  Key terms:
  • SAST (Static Application Security Testing) — Analyzing source code for vulnerabilities
  • DAST (Dynamic Application Security Testing) — Testing running application
  • SCA (Software Composition Analysis) — Scanning dependencies for known vulnerabilities
  • Shift-left security — Moving security earlier in development
  
  Tools: Snyk, Checkmarx, SonarQube, Semgrep, Trivy, OWASP ZAP Read more
  • Security
  • Automation
• Secrets are never stored in code — we use secrets management. Why it matters: Secrets in git history are exposed forever. Even "removed" secrets persist in git history.
  
  Key terms:
  • Secrets management — Secure storage and access to sensitive data
  • Secret rotation — Regularly changing credentials
  • Dynamic secrets — Short-lived credentials generated on demand
  • Secret scanning — Detecting secrets accidentally committed
  
  Tools: HashiCorp Vault, AWS Secrets Manager, 1Password, Doppler Read more
  • Security
• Container images are scanned for vulnerabilities before deployment. Why it matters: Base images often contain vulnerabilities. Scanning ensures you're not deploying known security issues.
  
  Key terms:
  • Container scanning — Analyzing container images for vulnerabilities
  • CVE (Common Vulnerabilities and Exposures) — Standardized vulnerability identifiers
  • Base image — Foundation image others are built from
  • Minimal images — Distroless or Alpine images with smaller attack surface
  
  Tools: Trivy, Snyk Container, Clair, Anchore, AWS ECR scanning Read more
  • Security
• We follow least-privilege access for all systems and services. Why it matters: Excessive permissions increase blast radius of breaches. Least privilege limits damage from compromised credentials.
  
  Key terms:
  • Least privilege — Minimum permissions needed to perform a task
  • RBAC (Role-Based Access Control) — Permissions based on roles
  • Just-in-time access — Temporary elevated permissions
  • Zero trust — Never trust, always verify
  
  Tools: AWS IAM, Azure AD, Okta, Teleport Read more
  • Security
• We have an incident response plan and practice it regularly. Why it matters: During a real incident is not the time to figure out the response process. Practice builds muscle memory.
  
  Key terms:
  • Incident response plan — Documented procedure for handling security incidents
  • Tabletop exercise — Walking through incident scenarios
  • War games — Simulated attacks to test response
  • Incident commander — Person coordinating response
  
  Best practice: Run tabletop exercises quarterly, update plan based on learnings Read more
  • Security
• Security requirements are part of Definition of Done for features. Why it matters: Security bolted on at the end is expensive and often inadequate. Security by design is more effective.
  
  Key terms:
  • Definition of Done (DoD) — Criteria that must be met for work to be complete
  • Security champions — Team members advocating for security
  • Threat modeling — Identifying potential threats during design
  • OWASP Top 10 — Most critical web security risks
  
  DoD examples: No high/critical vulnerabilities, authentication reviewed, inputs validated Read more
  • Security
• All infrastructure changes require approval and create audit trails. Why it matters: Compliance requires knowing who changed what and when. Audit trails enable investigation and accountability.
  
  Key terms:
  • Audit trail — Record of who did what and when
  • Change management — Process for controlling changes
  • GitOps — Git as audit log for infrastructure changes
  • Four-eyes principle — Requiring approval from another person
  
  Tools: Git history, CloudTrail, Azure Activity Log, Kubernetes audit logs Read more
  • Security

Building platforms that enable developer productivity and self-service capabilities.

• We have an Internal Developer Platform (IDP) enabling self-service. Why it matters: Platform Engineering reduces cognitive load on developers. Self-service removes bottlenecks and ticket queues.
  
  Key terms:
  • Internal Developer Platform (IDP) — Self-service layer for developer needs
  • Platform Engineering — Discipline of building and maintaining IDPs
  • Golden paths — Paved roads for common tasks
  • Platform as a Product — Treating internal platform like a product with users
  
  Tools: Backstage, Port, Humanitec, custom platforms Read more
  • Automation
• Teams can provision databases, queues, and other services without tickets. Why it matters: Waiting for infrastructure creates delays and frustration. Self-service provisioning accelerates development.
  
  Key terms:
  • Self-service provisioning — Teams can create resources without external approval
  • Service catalog — Menu of available services and how to request them
  • Guardrails — Automated policies preventing dangerous configurations
  
  Implementation: Terraform modules, Kubernetes operators, cloud APIs with IAM Read more
  • Automation
• We use containerization (Docker/Kubernetes) for consistent environments. Why it matters: Containers eliminate "works on my machine" by packaging application with dependencies. Kubernetes provides orchestration at scale.
  
  Key terms:
  • Container — Lightweight, portable application package
  • Kubernetes (K8s) — Container orchestration platform
  • Pod — Smallest deployable unit in Kubernetes
  • Helm — Package manager for Kubernetes
  
  Alternatives: AWS ECS, Google Cloud Run, Nomad, serverless Read more
  • Automation
• Infrastructure is multi-region/multi-AZ for high availability. Why it matters: Single points of failure cause outages. Geographic distribution provides resilience against regional failures.
  
  Key terms:
  • Availability Zone (AZ) — Isolated data center within a region
  • Multi-AZ — Deploying across multiple AZs
  • Multi-region — Deploying across geographic regions
  • Active-active — All regions serving traffic
  • Active-passive — Standby region for failover Read more
  • Automation
• We have disaster recovery plans tested at least annually. Why it matters: Untested DR plans often fail when needed. Regular testing reveals gaps before real disasters.
  
  Key terms:
  • RTO (Recovery Time Objective) — Maximum acceptable downtime
  • RPO (Recovery Point Objective) — Maximum acceptable data loss
  • DR drill — Practice running disaster recovery procedures
  • Failover — Switching to backup systems
  
  Best practice: Document DR procedures, test quarterly, update after incidents Read more
  • Automation
• Cost visibility is available to teams, and we optimize cloud spend. Why it matters: Cloud costs can spiral without visibility. Teams making decisions should understand cost implications.
  
  Key terms:
  • FinOps — Financial operations for cloud cost management
  • Cost allocation — Attributing costs to teams/projects
  • Right-sizing — Matching resources to actual usage
  • Reserved capacity — Pre-purchasing for discounts
  
  Tools: AWS Cost Explorer, Kubecost, Spot.io, CloudHealth Read more
  • Automation
  • Measurement

Building a learning organization that continuously improves processes and capabilities.

• Teams have dedicated time for learning, experimentation, and tech debt reduction. Why it matters: Without dedicated time, learning and improvement get deprioritized for feature work. This leads to stagnation.
  
  Key terms:
  • 20% time — Google's policy of dedicating time to side projects
  • Hack days/weeks — Dedicated periods for experimentation
  • Tech debt sprints — Sprints focused on paying down debt
  • Learning budget — Time/money allocated for training Read more
  • Culture
• We run regular retrospectives and act on improvement items. Why it matters: Retrospectives without action are theater. The value comes from implementing improvements.
  
  Key terms:
  • Retrospective — Meeting to reflect on what went well/poorly
  • Kaizen — Continuous incremental improvement
  • Action items — Specific improvements with owners
  
  Best practices:
  • Limit action items to 2-3 per retro
  • Review previous actions at next retro
  • Vary retro formats to prevent staleness Read more
  • Culture
  • Sharing
• Teams share learnings and best practices across the organization. Why it matters: Without cross-team sharing, each team solves the same problems. Sharing multiplies the value of learnings.
  
  Practices:
  • Internal tech blogs
  • Communities of practice
  • Lunch and learns
  • Internal conferences
  • Demo days
  
  Key term: Community of Practice (CoP) — Group sharing interest in a topic who learn together Read more
  • Culture
  • Sharing
• New team members can make their first production commit within the first week. Why it matters: Fast onboarding indicates good documentation, simple tooling, and healthy codebase. It's a canary for developer experience.
  
  Key terms:
  • Time to first commit — Onboarding speed metric
  • Onboarding docs — Guide for new team members
  • Starter tasks — Simple issues for newcomers
  
  Best practices:
  • Scripted dev environment setup
  • Good first issue tags
  • Onboarding buddy system Read more
  • Culture
• We regularly assess our DevOps maturity and set improvement goals. Why it matters: What gets measured gets managed. Regular assessment creates accountability for improvement.
  
  Approaches:
  • Annual DORA assessment
  • Quarterly checklist reviews (like this one!)
  • External maturity assessments
  • Team self-assessments
  
  Resources: DORA State of DevOps Report, Accelerate book, DevOps Capability Catalog Read more
  • Culture
  • Measurement
• Leadership actively supports and invests in DevOps transformation. Why it matters: DevOps transformation requires organizational change. Without executive support, efforts stall at team boundaries.
  
  Signs of support:
  • Budget for tooling and training
  • Time allocated for improvement work
  • Executive sponsorship of initiatives
  • Metrics in leadership dashboards
  • Recognition of DevOps achievements
  
  Key insight: Transformation is 20% tools, 80% culture and organizational change Read more
  • Culture