Regaining control of a Kubernetes platform before a critical release

The real problem

The platform was working. That was precisely what made the situation dangerous: no obvious outage forced the organisation to address the grey areas.

Ahead of a fixed business release, product and platform teams could describe clusters, components and alerts. But several essential questions had no clear answer: who decides whether a risk is acceptable, who acts when a shared component becomes a failure point, and who owns the go/no-go decision?

The primary risk was therefore not purely technical. It sat at the boundary between architecture, operations and accountability.

What we found

Existing observability could expose symptoms, but it did not always connect those symptoms to an owner and a decision.

At the same time, the platform backlog kept accumulating features. Adding another cluster capability would have increased the technical surface without solving the most urgent problem: ambiguity about responsibility during change and incident response.

Our intervention

We reduced the problem to three objects:

1. the decisions required to authorise the release;
2. the failure modes that could invalidate those decisions;
3. the expected owner for each action and trade-off.

That mapping separated platform responsibilities from product service objectives and turned grey areas into a responsibility matrix, a decision log and a prioritised remediation backlog.

The trade-off

The important decision was not to add another tool or Kubernetes capability.

It was to slow part of the platform feature work temporarily and address ownership gaps that were increasing release risk.

What changed

Teams gained a shared language for discussing change risk. Release criteria became explicit, and platform work was reordered around the decisions and responsibilities that needed to be secured first.

The platform was not rebuilt. The decision system around it became clearer.

What we learned

On a shared platform, technical capability without explicit ownership can increase complexity faster than it increases reliability.

Before adding a feature, a more basic question must be answerable: who makes the decision when that feature becomes critical?