Common Anti-Patterns

Anti-patterns are repeated shapes of failure. Name them early so teams can discuss risk without blaming individuals.

Platform anti-patterns

Adopting Kubernetes before there is a clear need for shared orchestration, policy, or platform primitives.

Better: use managed containers, PaaS, or serverless until the operating model justifies cluster ownership.

Every safe action requires a platform team ticket.

Better: provide self-service workflows with guardrails, documentation, and observable ownership.

The paved road exists, but teams bypass it because it does not match real workflows.

Better: pilot with real teams, measure friction, and fund improvements.

Deployments depend on humans copying values, clicking buttons, or rebuilding artifacts.

Better: promote immutable artifacts through automated, audited gates.

The team believes rollback exists but has not tested it.

Better: define rollback, disablement, and forward-fix paths before launch.

Quality gates are ignored because they fail for unrelated reasons.

Better: fix flakiness aggressively or move checks to the stage where they produce useful signal.

Alerts fire for symptoms nobody needs to wake up for.

Better: alert on user impact, SLO burn, and actionable failure modes.

Runbooks exist but have not been tested by responders.

Better: exercise runbooks during readiness reviews and incidents.

Temporary risk acceptances never expire.

Better: require owners, expiry dates, compensating controls, and review.