↓ Skip to main content
Oh My Ops | DevOps Guides, stacks & tools for engineers

Production Readiness Review

You are about to put something in production, or it is already there and nobody has looked at it properly. The team knows there are gaps. Nobody has the clear stretch of weeks it would take to find out which ones matter.

That is the job.

What it is
#

A fixed-scope review of one Kubernetes cluster and the infrastructure around it, against the 74-point checklist I publish openly. Read-only access, with nothing that can write. You know the price and the date before we start, and neither moves afterwards.

It answers one question: what breaks first, and what does that cost you. Not “here are 40 findings sorted by severity label” — a scanner does that in ten minutes and I run one myself on day one.

What you get
#

A report where every finding names its consequence. Not “PodDisruptionBudget is recommended” but “losing one node takes checkout offline for about four minutes, because these three pods share it and the budget lets all of them go at once.” Findings you cannot act on are not findings.

A plan in three buckets — fix before launch, fix in the first month, and live with it deliberately. The third bucket matters as much as the first: knowing what you have chosen not to fix is the difference between accepted risk and a surprise.

An appendix with every one of the 74 items and its verdict — passed, failed, or unverified because the access could not answer it. This is the part that shows the work: you can see exactly what was looked at, not just what was found.

A walkthrough of up to ninety minutes, live or fully written up if the time zones don’t work. I am not in your time zone and I am not going to pretend otherwise.

What it costs
#

$1,500 and twelve working days for the scope below — one cluster, up to 40 workloads. Invoiced on delivery, nothing up front.

Both numbers are attached to that scope, not to the service. A bigger environment takes longer and costs more, and I would rather work that out with you on the first call than discover it on day five. A second cluster is not double, though: a good half of the list is asked once about the whole organisation, not once per cluster.

$1,500 is an introductory rate while I build up case studies for this specific service; it will be $3,000 once I have them.

You get ten working days after delivery to say the work does not match what we agreed, and I fix it. If bank charges eat into the transfer, they are on your side up to $75, so the amount that reaches me is the amount we agreed.

What access is needed
#

Read-only, and that is not a formality:

  • kubeconfig with a read-only role
  • read access to the cloud account (or an export of the relevant configuration)
  • read access to the infrastructure repository
  • two or three hours of an engineer’s time, spread across the review

No write access to anything — not the cluster, not the repository. No credential that can change anything. No deploys from me. If your security process needs a specific role definition, I will send one to hand to whoever approves it, and it will not include reading your secrets.

This is the point of the whole format. You are letting a stranger look at your infrastructure, and the honest way to lower that risk is to make sure I cannot change anything that is running.

One honest caveat about the word “read-only”.

Some of the list cannot be answered from an API. Whether a backup has ever been restored, how long a rollback actually took, who could rebuild the system if one person left — these come from talking to your team, which is what those two or three hours are for. Items nobody can answer get marked as unverified rather than guessed at. If the time does not materialise at all, those items stay unverified and the work is still billable — I cannot invent the answers.

What gets examined
#

The full list is the public checklist — 74 items across eight areas:

  • Failure behaviour — probes that mean what they say, disruption budgets that don’t block drains, what actually happens when you lose a node or a zone
  • Resources and load — requests against measured consumption, throttling, headroom for losing a zone
  • Data and recovery — not “are backups configured” but “have you ever restored one”, and what your real RPO and RTO turn out to be
  • Security — RBAC, security contexts, network policies, secrets in git history, image provenance
  • Observability — which alerts wake a human, how many of them are false, whether the dashboard answers “what is broken” in five minutes
  • Releases and rollback — whether rollback has ever been performed, and what a failed migration mid-deploy would do
  • Cost — the gap between requests and actual use, idle resources, the obvious overspend
  • Operational maturity — runbooks, bus factor, whether postmortems get read

Of those 74 items, 59 are things no scanner can answer. That is the work.

What is not included
#

  • Implementing or fixing anything — I find and prioritise, you decide and apply
  • Load and performance testing
  • Application code review
  • Penetration testing or anything that tries to break in rather than look
  • Re-checking your fixes afterwards, which is a separate and much shorter conversation
  • Compliance certification, and I am not an auditor

Scope limit: one cluster, up to 40 workloads — the scope the price and the twelve days are quoted against. Larger than that and we agree a new figure for both before anything starts, or in the first week if it only becomes visible once I am in.

When this is not worth buying
#

  • You run fewer than five services on a managed platform and have had no incidents. There is nothing here for you yet.
  • You already have someone who owns reliability and has walked this list. You would be buying a second opinion, which is a different and cheaper purchase.
  • You want someone to run production. This is a review, not an on-call rotation, and I have a full-time job in a distant time zone.

I would rather lose the sale now than halfway through.

What usually comes next
#

Most readiness findings have the same root cause: infrastructure assembled by hand, so nobody can reproduce it and every fix is a fresh manual change. If that turns out to be your situation, the sensible follow-up is bringing the infrastructure into Terraform properly — but that conversation belongs after the review, when we both know the actual scope.

How to start
#

Email hello@ohmyops.dev with three things:

  1. What runs in the cluster, roughly how many workloads, and which cloud
  2. What worries you most — the thing you would name first if production went down tonight
  3. Whether there is a date driving this (a launch, an audit, a customer asking questions)

I will reply with either a start date or an honest reason this is not a fit.

If you would rather check the list yourself first, it is right here and costs nothing.