DevOps checklist

Start with a customer problem. Order feature, maintenance and reliability work by the outcome the team expects to improve.

DORA: Continuous delivery / DORA: Transformational leadership

The team decides how to organize delivery. People volunteer for work that fits their skills or learning goals, while making ownership and capacity visible.

DORA: Generative organizational culture / DORA: Loosely coupled teams

Ask people to explain the connection. A team should be able to name its intended outcome and describe how that outcome supports the wider business.

DORA: Continuous delivery / DORA: Transformational leadership

Review overtime and recurring emergency work. Leave capacity for maintenance, recovery and rest instead of building delivery plans around repeated personal sacrifices.

DORA: Continuous delivery

Measure the time needed to restore service. Use it to guide improvements in detection, response and recovery, alongside work that prevents failures.

DORA: Generative organizational culture / Google SRE Workbook: Incident Response

Review who handles delivery and operational decisions. Development, operations and security share responsibility, with specialists providing support where needed.

DORA: Generative organizational culture / Google SRE Workbook: Postmortem Culture

Look beyond the operating budget. Funding decisions consider how engineering helps the business serve customers, adapt the product and maintain capabilities it depends on.

DORA: Continuous delivery / DORA: Transformational leadership

Reconstruct what people knew at the time. Review system behavior and working conditions, then assign improvements that address the contributing causes.

DORA: Generative organizational culture / Google SRE Workbook: Postmortem Culture

Check who remains responsible after a milestone. Teams keep the context and authority needed to maintain and improve their product or service beyond an individual project.

DORA: Generative organizational culture / DORA: Loosely coupled teams

Name the team responsible for each service. Its responsibilities include deployment, monitoring, incident participation and ongoing improvement, with an agreed support rota.

DORA: Generative organizational culture / Google SRE Workbook: Incident Response

Bring operational requirements into planning and design. Developers also contribute to production decisions and incident response, so both groups work from the same constraints.

DORA: Generative organizational culture / Google SRE Workbook: Postmortem Culture

Check the chat integrations people actually use. Alerts, deployment updates and authorized operational commands should provide shared context, with access controls for actions.

DORA: Generative organizational culture / Google SRE Workbook: Postmortem Culture

Make the current state easy to find. People involved in delivery can view service health, deployment history and relevant metrics within their access permissions.

DORA: Monitoring and observability

Find the instructions for a recent change. Their revision history and review process should make it clear who maintains them and whether they match the running system.

DORA: Documentation quality / DORA: Version control

Look for knowledge moving between people. Pairing, group programming or technical sessions should help colleagues understand systems beyond the parts they usually maintain.

DORA: Learning culture

Pick a service outside your own team. You should be able to find its owner, purpose, interfaces and documentation through a maintained internal entry point.

CNCF: Platforms White Paper / DORA: Flexible infrastructure

Try following a guide without its author. Include prerequisites, steps, checks and escalation contacts, then test the instructions when systems or procedures change.

DORA: Version control / Google SRE Workbook: Incident Response

Inspect the continuous integration pipeline. Each change should trigger the relevant build, automated tests and checks that inspect code without running the application.

DORA: Continuous integration / DORA: Test automation

Check who can initiate a deployment. Authorized developers should be able to use a repeatable pipeline that enforces the required approvals without manual execution by operations.

DORA: Deployment automation / DORA: Flexible infrastructure

Inspect how an environment is created or changed. Infrastructure definitions should be stored in version control, reviewed and applied through a repeatable process.

DORA: Version control / The Twelve-Factor App: Config

Change a deployment setting without editing source code. Use environment variables or a configuration service, and retrieve credentials through controlled secrets management.

DORA: Version control / The Twelve-Factor App: Config

Compare the artifact identifiers in testing and production. Promote the tested package unchanged, while supplying the appropriate configuration for each environment.

DORA: Deployment automation / DORA: Flexible infrastructure

Choose a rollout suited to the service. Options include releasing to a small audience first, switching between environments or controlling feature access with flags. Check health before expanding exposure.

Google SRE Workbook: Canarying Releases

Time a rollback exercise. Keep a known working version available and check data compatibility, so reversing an application release does not leave the service unusable.

Google SRE Workbook: Canarying Releases

Try creating an environment from documented automation. Match the production characteristics relevant to the test, protect sensitive data and remove temporary resources when finished.

DORA: Deployment automation / DORA: Flexible infrastructure

Review the age of active branches. Break work into small changes, merge frequently into the shared main branch and keep incomplete features safely disabled when necessary.

DORA: Trunk-based development

Review what the tests would catch. Test individual units in isolation, including failure cases; use coverage reports to investigate gaps without treating a percentage as proof of quality.

DORA: Test automation

Test the boundaries your application depends on. Include relevant database interactions, service interfaces and API contracts, with checks for expected responses and failures.

DORA: Test automation

Choose journeys whose failure would affect customers. Run them through the assembled system and maintain the tests so failures prompt investigation.

DORA: Test automation

Check the repository's merge rules. Tests should run for each commit or proposed change, and required failing checks should prevent merging into the main branch.

DORA: Continuous integration / DORA: Test automation

Include realistic shapes, volumes and difficult cases. Use synthetic or appropriately anonymized data, and verify that test access does not expose production secrets or personal information.

DORA: Test data management

Test against expected demand and agreed limits. Run suitable load checks in the delivery pipeline and investigate regressions before approving a release.

DORA: Test automation

Start with an explicit hypothesis. Set the permitted impact, monitoring and stop conditions before introducing a failure, then compare recovery behavior with the expectation.

Principles of Chaos Engineering

Inspect the review history and merge controls. A reviewer checks behavior, maintainability and risks; automated formatting and style checks support that review.

DORA: Streamlining change approval

Use consistent definitions for each service. Track deployment frequency, change lead time, recovery from failed deployments and the share of deployments requiring intervention. Review trends together.

DORA: Continuous delivery

Define service level indicators that reflect user experience. Set service level objectives and an error budget for an agreed period, then decide how budget consumption affects release and reliability work.

Google SRE Workbook: Implementing SLOs

Find an event across the relevant services. Logs should use consistent fields and request identifiers, with access, retention and redaction rules suited to the data.

DORA: Monitoring and observability / OpenTelemetry: Traces / Google SRE Workbook: Alerting on SLOs

Follow a request through the services it touches. Connected spans should show individual operations, their timing and where errors occur.

DORA: Monitoring and observability / OpenTelemetry: Traces / Google SRE Workbook: Alerting on SLOs

Check what action each alert requires. Route it to the responsible team, link the relevant runbook and reserve urgent paging for problems needing immediate attention.

DORA: Monitoring and observability / OpenTelemetry: Traces / Google SRE Workbook: Alerting on SLOs

Ask developers where work gets stuck. Combine their feedback with evidence such as build duration, review delays and onboarding effort, then check whether changes help.

DORA: Loosely coupled teams / DORA: Documentation quality / DORA: Continuous integration

Mark releases on relevant product dashboards. Review changes in customer behavior alongside deployments, and investigate other explanations before attributing an outcome to a release.

DORA: Monitoring systems to inform business decisions

Check all three types of scanning. Inspect source code with static analysis, dependencies with composition analysis and the running application with dynamic tests. Assign findings for triage.

OWASP SAMM: Secure Build / OWASP SAMM: Security Testing / OWASP: Docker Security Cheat Sheet / OWASP SAMM: Security Requirements

Review how applications receive credentials. Use controlled secret storage, limit access and scan repositories for accidental exposure; revoke or rotate exposed credentials.

OWASP: Secrets Management Cheat Sheet

Inspect the image that will actually be deployed. Scan its packages and dependencies, then handle findings under the team's release policy and update affected images.

OWASP SAMM: Secure Build / OWASP SAMM: Security Testing / OWASP: Docker Security Cheat Sheet / OWASP SAMM: Security Requirements

Compare granted permissions with actual responsibilities. Limit scope and duration where possible, review access when roles change and remove permissions that are no longer needed.

OWASP: Secrets Management Cheat Sheet

Walk through a plausible security incident. Confirm response roles, containment steps, communication routes and recovery checks, then update the plan using lessons from the exercise.

OWASP SAMM: Incident Management

Check the team's completion criteria. Include the security checks relevant to the feature, such as authorization, input handling and resolution of release-blocking findings.

OWASP SAMM: Secure Build / OWASP SAMM: Security Testing / OWASP: Docker Security Cheat Sheet / OWASP SAMM: Security Requirements

Trace a change from proposal to execution. Keep evidence of its author, approval, applied configuration and outcome, including emergency changes under an agreed exception process.

DORA: Streamlining change approval

Try a common development task through the platform. Document the supported route, make ownership clear and collect feedback from the teams using it.

CNCF: Platforms White Paper / DORA: Flexible infrastructure

Try requesting a database or message queue. Self-service workflows should apply agreed access, security and spending limits while making resource ownership clear.

CNCF: Platforms White Paper / DORA: Flexible infrastructure

Check how the application and its dependencies are packaged. Use versioned container images and verify configuration differences; orchestration choices should fit the workload.

Kubernetes documentation: Images

Review which infrastructure failures the service must withstand. Distribute it across the required zones or regions, account for shared dependencies and test the failover path.

AWS Well-Architected: Deploy the workload to multiple locations

Record the permitted downtime and data loss. Exercise restoration against those targets at least once a year, then update the recovery instructions and resolve gaps.

AWS Well-Architected: Test disaster recovery implementation

Connect usage and cost to the responsible team. Review unused resources, capacity and service choices while checking the effect of cost changes on reliability.

DORA: Flexible infrastructure

Look at the work people can actually schedule. Reserve time for developing skills, testing ideas and reducing maintenance burdens, with agreed outcomes for that work.

DORA: Learning culture / DORA: Documentation quality / Google SRE Workbook: Postmortem Culture

Revisit the actions from the previous discussion. Give each selected improvement an owner and review point, then check whether the change addressed the problem.

DORA: Learning culture / DORA: Documentation quality / Google SRE Workbook: Postmortem Culture

Make useful findings accessible across teams. Demonstrations, internal notes and shared practice groups should explain what was tried, the result and where it may apply.

DORA: Learning culture

Walk through the onboarding path. Provide working setup instructions, a suitable starter task and support so newcomers can contribute safely through the normal review and release process.

DORA: Learning culture / DORA: Documentation quality / Google SRE Workbook: Postmortem Culture

Keep a record of the previous review. Agree on improvements, owners and a review date, then compare evidence and outcomes when the team returns to the checklist.

DORA: Learning culture / DORA: Documentation quality / Google SRE Workbook: Postmortem Culture

Look for commitments beyond verbal support. Leaders allocate time and budget, help resolve obstacles between teams and review the outcomes of improvement work.

DORA: Transformational leadership