Adoption checklist
A phase-by-phase checklist that distills this course into concrete, checkable steps — from blameless on-call readiness through trunk-based CI/CD, infrastructure as code, and golden-signal monitoring. This is a plain checklist: checking a box is a visual aid for your own use only, nothing is saved server-side or persisted across visits.
☺ Explain it like I'm 10
Before a road trip you check the tires, the gas, and the spare — not because a form makes you, but because skipping one turns a small problem into a breakdown on the highway. This page is that same pre-trip check, but for shipping software: is someone on call, does every merge get tested automatically, is the environment built from code instead of memory, and will anyone notice if it breaks at 2 a.m.?
① Culture & Process readiness
Blameless postmortem process is documented, and the team has run at least one practice postmortem on a past incident Each service has a single team accountable for both building and running it — "you build it, you run it" On-call rotation is defined with named primary and secondary responders and a documented escalation path Paging tool (e.g. PagerDuty, Opsgenie) is configured and tested with a live fire drill, not just set up on paper Runbooks exist for the highest-traffic and highest-risk services, stored where the on-call engineer can find them at 2 a.m. Dev and Ops are measured against the same shared metrics (e.g. deployment frequency, MTTR) rather than opposing ones A no-blame incident review template is agreed and used consistently, kept separate from performance review Production access policy is defined — who can deploy, who can read secrets, and how access is requested and revoked ② Delivery Pipeline readiness
Branching strategy is trunk-based: feature branches live less than a day and merge directly to main Incomplete work ships behind feature flags instead of sitting on a long-lived branch CI triggers automatically on every merge to main (and ideally every pull request), not on a manual button press CI runs build, lint, and unit tests on every trigger, with results visible to the whole team Automated tests must pass before a deploy proceeds — no "deploy now, test later" path exists in the pipeline config Flaky tests are tracked and fixed or quarantined, not silently rerun until green Build artifacts (containers, packages) are built exactly once per commit and stored in an artifact repository (e.g. Artifactory, ECR, GitHub Packages) The same artifact that passed CI is promoted unchanged through staging and production — no environment rebuilds from source ③ Infrastructure readiness
Every environment — dev, staging, production — is provisioned from the same IaC codebase (e.g. Terraform, CloudFormation, Pulumi), not clicked together by hand IaC state is stored remotely with locking, and changes go through code review before apply A drift-detection check runs regularly so undocumented manual changes to live infrastructure get caught Configuration management (e.g. Ansible, Chef, Puppet, or an immutable-image pipeline) applies consistent config to every running host — no one-off SSH sessions Secrets are managed through a secrets manager (e.g. Vault, AWS Secrets Manager), never hardcoded in IaC or config files If running containers, an orchestrator (Kubernetes, ECS) is in place with resource requests/limits and health checks defined for every service Container images build from a minimal, scanned base image and are rebuilt on a schedule to pick up security patches ④ Operations readiness
The four golden signals — latency, traffic, errors, saturation — are instrumented and visible on a dashboard for every production service Alerts are wired to the golden-signal dashboards and page a human only for symptoms that need immediate action, not for noise Incident severity levels (e.g. SEV1–SEV4) are defined with concrete criteria for each, not left to judgment in the moment Incident roles — incident commander, communications lead, scribe — are defined and assigned before the first real incident, not invented during one A postmortem is required within a set window (e.g. 48 hours) after every SEV1/SEV2 incident, with tracked action items All four DORA metrics — deployment frequency, lead time for changes, change failure rate, mean time to recovery — are being measured, not just discussed DORA metrics are reviewed on a regular cadence (e.g. monthly) and tied to at least one concrete improvement action