Rescue engagements

Rescues have a characteristic failure mode: the team is under pressure, so they start changing things, and six weeks later nobody can tell you whether the system is better or just different.

We do it in three phases, in this order, and we do not skip the first two.

Phase one — stabilise

Nothing gets redesigned. We stop the bleeding: the alert that pages for the wrong reason gets fixed, the deploy that takes forty minutes gets a fast path, the queue that silently drops work gets a dead-letter log.

The goal is a system that behaves predictably enough to be changed. You can measure this phase — the count of incidents per week should fall before anything else moves.

Phase two — understand

Before proposing anything, we build a model of the system that is actually running: what talks to what, where the data really lives, which paths are load-bearing and which are dead code nobody has traced yet.

The deliverable is boring and valuable: a diagram that is true, a list of the top five risks in order, and an estimate attached to each of the ways out.

Phase three — decide

Now — and only now — do the options appear:

• Repair: the smallest set of changes that removes the top risks.
• Strangle: put the new implementation alongside the old and migrate path by path, keeping the system running throughout.
• Rewrite: occasionally correct, and only with a written reason why the other two lose. Usually because the model itself, not the code, is wrong.

What we do not do

We do not rewrite in phase one. We do not keep a rescue running indefinitely — a rescue with no end date is a retainer wearing a different hat, and you should be told which one you are buying.

What you get at the end

A system that is either fixed or honestly described, with the reasoning written down. Even if you decide not to proceed with us, the diagnosis is yours to keep.