The Zen of DevOps

Be able to break non-production systems #

Non-production environments are needed for safe experimentation and fast delivery.

Any challenge identified and resolved in non-production is one less risk to worry about on production.

Be able to break non-production systems only #

Non-production environments must be representative enough to catch issues.

Testing and observability need to be sufficient to catch issues.

Isolation and guardrails should prevent accidentally breaking production.

Promotion procedures need to be robust enough to avoid introducing issues on production.

Design for more than one #

More than one instance allows horizontal scaling and provides resilience.

More than one concurrent version allows rolling updates and canary releases.

More than one deployment requires parametrizing the right things.

More than one of anything requires automation.

Design for more than one, to stay ahead of scaling and resilience needs.

Design for more than once #

Hidden dependencies often only appear during disaster recovery or scaling.

More than once allows upgrades to be repeatedly tested.

Make rebuilding a habit, not a project. Weak spots surface when repetition is cheap.

If you can’t rebuild, you can’t recover from disaster.

Favor changes that make you faster over those that slow you down #

Friction compounds over time, while improvements pay recurring dividends.

Prioritize work that reduces drag and simplifies future changes over quick fixes.

Beautiful is better than ugly #

Clean, readable code invites contribution and reduces cognitive load.

Enforce consistent style and structure to make maintenance easier for everyone.

Explicit is better than implicit #

Hidden logic, while solving a need, can be hard to reason about.

Configuration values might be deliberately chosen, even though they are defaults.

Implicit behavior hides important details and can lead to misunderstandings.

Consciously choose what to expose and what to hide, guiding future changes.

Simple is better than complex #

Simple designs are easier to understand, maintain, and scale.

Accept required components, but keep their implementation as simple as possible.

Prefer removing problems over adding solutions.

Complex is better than complicated #

Ignoring complexity can lead to complicated problems.

Address essential complexity, while keeping accidental complexity to a minimum.

Avoid masking essential complexity with artificial simplicity.

Errors should never pass silently #

Make errors something that can be observed, diagnosed, and addressed.

If something unexpected is encountered, don’t ignore it.

Blameless culture and post-mortems help turn errors into learning opportunities.

Unless explicitly silenced #

When not addressing an error, make the decision to defer it explicit.

When accepting a certain risk, make that decision explicit.

In the face of ambiguity, refuse the temptation to guess #

If guessing at the cause of a problem, try to reproduce and find the root cause.

If guessing at the purpose of a component or piece of configuration, improve the design or documentation.

If guessing what the effect of a change will be, seek ways to remove the guessing. Don’t rely on luck.

Become a fire-preventer instead of a fire-fighter.

There should be one - and preferably only one - obvious way to do it #

Multiple approaches lead to fragmentation, confusion and cognitive load.

Limit options through clear design, documentation, and standardized examples.

Follow common patterns and conventions to make it easier for others to understand and contribute.

If the implementation is hard to explain, it's a bad idea #

If a design is difficult to explain, it is likely flawed.

If the need for a design is difficult to explain, it might not be needed at all.

If the implementation is easy to explain, it may be a good idea #

Even if a design is easy to explain, underlying assumptions might not be accurate, or change over time.