Expert Services

Two reviews

Most useful consulting work on infrastructure happens at two moments: before a change that could break production, and after something broke. These are those two, scoped deliberately narrowly.

Both are fixed-scope and end with a document. Neither includes ongoing availability, emergency response, or access to your production systems — see what is not included.

---

Infrastructure Change Review

Who it is for. A team about to make a change to production infrastructure that is hard to reverse — an OpenStack or Kubernetes upgrade, a Terraform change with a large blast radius, a storage or network migration, a control-plane reconfiguration.

The problem it addresses. Change plans are usually reviewed by the people who wrote them. The failure modes that matter are the ones nobody on the team has hit before, and they are rarely in the plan — not because the plan is careless, but because you cannot write a step for a failure you have not seen. A review by someone who has seen them is cheaper than the incident.

What you supply.

• The change plan or runbook as it currently stands, however rough
• Architecture description: what the system is, what depends on it, what the topology looks like
• Versions of the relevant components
• What you believe the risky steps are, and what you are unsure about
• Any rollback position you already have

Prose, diagrams, and redacted excerpts. Not credentials, not access, not production dumps.

What you receive.

• An annotated assessment of the plan, step by step, naming for each risky step the specific failure it could produce
• Prioritised findings, each stating the scenario it prevents rather than a generic severity label
• Gaps in the rollback position — the steps after which rollback changes character, and what that would cost
• Validation missing from the plan: what you would need to observe to know a step actually worked
• A recommended sequence, where the order of operations materially changes the risk

Scope limits.

• A review of a plan, not authorship of one, and not execution of it
• One system and one change. A second change is a second review
• Written against the versions and topology you describe. If those are wrong, the review is wrong
• No production access, and none is requested

How scoping works. You describe the change. We reply with what we would need and what the review would and would not cover, and a price. You approve a written scope before anything starts. If the change is too large to review usefully in one pass, we will say so and propose a smaller first scope rather than accepting the whole thing.

Request an Infrastructure Change Review

---

Incident and Reliability Review

Who it is for. A team that has had an incident — or a pattern of them — and wants the contributing factors identified properly rather than the nearest cause written down and closed.

The problem it addresses. Postmortems written by the people who fixed the incident tend to stop at the thing that was changed to make it stop. That is the trigger, not the cause, and it is why the same class of incident recurs with a different trigger. Separating those needs someone who was not in the room at 3am.

What you supply.

• The incident timeline as you have it, however incomplete
• Redacted evidence: relevant log excerpts, dashboards, alert history, the commands that were run
• The existing postmortem, if there is one
• What monitoring and runbooks existed at the time
• Architecture context for the systems involved

What you receive.

• A reconstructed timeline separating what happened from when you learned it — the gap between those two is usually where the time went
• Contributing factors distinguished from the trigger, each with the evidence for it
• Observability gaps: specifically what you would have needed to see, and where
• Runbook gaps: the decisions made from memory that should have been written down
• Prioritised remediation, ordered by how much of the incident class each item removes
• Where the evidence does not support a conclusion, that said plainly rather than filled in

Scope limits.

• Blameless and about the system. Not an assessment of individuals, and not usable as one
• Bounded by the evidence you can share. Missing evidence becomes a stated unknown
• Analysis and recommendations; implementing them is separate work
• Not an audit, a compliance artefact, or an expert opinion for a dispute

How scoping works. You describe the incident and what evidence exists. We reply with what the review could establish from it, what it could not, and a price. If the evidence is too thin to reach useful conclusions, we will tell you that instead of taking the work.

Request an Incident and Reliability Review

---

What we work on

The reviews above are applied to these systems. Depth varies, and we will tell you where it is shallower.

• OpenStack — architecture, Kolla-Ansible deployment, upgrade planning, production troubleshooting
• Kubernetes — cluster operations, workload reliability, scheduling and resource problems
• Terraform and infrastructure as code — module structure, state strategy, blast-radius reduction
• Observability — instrumentation strategy, alert design that does not page for nothing
• Linux and the services underneath — the message bus, database, and load balancer layer that most incidents actually live in
• AI infrastructure — accelerator platform design, interconnect and storage architecture, capacity planning

Other work

Beyond the two reviews, hands-on work — an upgrade, a migration, a performance investigation — is possible, scoped against a defined outcome and a validation that proves it. It is quoted separately because it is not a review, and it is the kind of work we are most likely to decline if a review would serve you better.

How this works in practice

Engagements start with a conversation about what you are trying to achieve and what state the system is actually in — not a proposal. If we are not the right people for it, we will say so. If the problem is smaller than an engagement, we will tell you that too.

Work is done against a written scope with a defined deliverable. Where an engagement involves changes to production, the plan includes validation and rollback before anything is executed, the same way our runbooks do.

What is not included

Neither review includes any of the following, and none of it is available as an undefined add-on:

• Ongoing or unlimited support. Both reviews are fixed-scope and end with a document.
• Emergency or on-call response. There is no response-time commitment, because none is staffed. If you are in an incident now, these reviews are the wrong thing to buy.
• Access to your production systems. Reviews work from what you describe and share. We do not ask for credentials, and you should not send them.
• Implementation of the recommendations. That is separate, scoped work.
• Staff augmentation for open-ended periods.
• Work we are not qualified for, taken because it is adjacent.
• Recommendations that require buying something we have a commercial relationship with — there are none.

Get in touch

Tell us what you are trying to achieve, what the current state is, and what the constraint is — time, budget, risk tolerance, or a date you have to hit.

Request a scoped review — or see contact for corrections, security reports, and everything else.