DevOps Engagement Builder

Every problem you tick pulls in a workstream. Each workstream carries its own deliverables, its own hours, and the service it belongs to. Tick two problems that need the same work and you get one workstream, not two — the plan describes the work, not your clicks.

Then the workstreams land in phases. That ordering is the part worth reading, and it matters more than the total at the top.

The four phases, and why they are in that order

Discovery comes first, and it is read-only. Nothing changes on your systems. It exists because scoping infrastructure work without looking at it is guessing, and both sides pay for that later. It ends with written findings you keep either way.

Stop the bleeding comes second. Anything where you are exposed right now goes here — no backups, shared logins, a server that has never been hardened. These jump the queue because everything after them is worth less while they are open.

Build is the main body of work, ordered by what removes the most risk per hour rather than by what is quickest to tick off.

Handover is last and it is not optional. The engagement ends with you able to run this without me. If that part is missing, what you bought was a dependency.

The hours are effort, not a price

Base hours describe one server, production only, with nothing existing to build on. Three inputs move them, and each one is printed beside your result with the exact multiplier it applied.

A multiplier only touches the work it genuinely affects. Handover does not get longer because you run twenty servers, so the server count does not touch it. Existing monitoring makes new monitoring cheaper, so it discounts that work and leaves the rest alone.

Everything is a range rather than a single figure. An effort estimate stated to the hour is a quote pretending to be arithmetic, and the honest answer to “how long” before discovery is a span. There is no price anywhere on this page, because what work costs depends on scope, and scope is what discovery settles.

Nothing here is measured

The tool never connects to anything. It reads ticked boxes and it could not verify one of them if it tried. So an optimistic answer produces an optimistic plan. Answer as your worst week would answer, not your best.

Deploys and change

Manual deploys. Every one is a chance to miss a step. Worse, manual releases get rare, and rare releases are big releases. Big releases are the risky ones, so the caution makes the problem it was protecting against.

No quick way back. You need a rollback exactly when you are least able to think clearly. If going back means a restore or a rebuild, the pressure is to fix forward instead — which is how a small fault becomes a long outage.

No staging. Staging is worth less than people claim and a great deal more than nothing. Its real value is that the deploy itself gets rehearsed, and the deploy is usually the part that breaks.

One person deploys. It looks like efficiency right up until they are on a plane. Documentation alone does not fix it. Somebody else has to do a real deploy while the first person watches.

Knowing it broke

Customers tell you first. Detection is the cheapest part of an outage to shorten and it is entirely within your control. It also spends goodwill you cannot buy back.

No alerts, or alerts nobody reads. These are the same problem. An alert stream nobody trusts is worse than none, because it hands out false confidence. Cutting noise matters as much as adding checks.

No history. Without logs and metrics from the moment of the fault, every incident review ends in a guess. Then the same bug gets fixed speculatively two or three times.

Surviving failure

One server. One failure domain. Everything stops at once and stays stopped until somebody rebuilds it, which is a very different shape of outage from things getting slow.

Backups nobody has restored. Backups fail quietly. The job reports success, the file gets written, and the missing table only appears on the day it is needed. A restore is the only proof.

No backup at all. The one item on this list where a single bad afternoon ends the business rather than interrupting it. It leads every plan it appears in.

Untimed recovery. An untimed plan is an estimate made under pressure, and it is always optimistic. Doing it once, calmly, turns it into a number — and that number is what everything else gets judged against.

Access and secrets

A shared login. It removes the two things an incident needs most: knowing who did what, and revoking one person without changing something everyone depends on. It is usually also the account that can delete the backups.

Secrets in the repository. Once a credential is in git history it stays there after the file is deleted. So rotating it matters more than removing it, and rotating is the half that gets skipped.

Never hardened. Defaults are public and the scanning is constant. Most of the work is a day. The update schedule is the half that keeps paying afterwards.

Unknown AWS access. Accounts collect permissions the way drawers collect cables. A role added for one deployment three years ago is still there, still trusted, and still able to do everything. You can check a single policy for free with the IAM Policy Checker.

The platform

It falls over. Restarting works, which is precisely why the cause survives for years. Tracing it is usually short work with a definite end.

Docker Compose in production. The defaults are built for a laptop. No restart policy, no resource limits, an unbounded log, a published database port — all invisible until the day they are not. The Compose checker will tell you which apply to you, free.

Moving to AWS, or half moved. Half-finished migrations are the expensive kind: two places to pay for, two to debug, and no clear owner of either. Start with the cost estimate, because that is the decision everything else hangs off.

WordPress. Most compromises are not clever. They are a known plugin version, a valid username the site published itself, and an unlimited number of password attempts. The WordPress Security Check reports all three.

Certificates, redirects and DNS. Recurring incidents here are almost always one small definite fault rather than a large vague one. That is why it is a line item and not a workstream.

Email not arriving. Usually an authentication record rather than anything about the server. The email checker names the broken record in about ten seconds.

Restore a backup this week

Pick the smallest database you have. Restore it into a scratch machine, check the row counts, and write down how long it took. That single number is worth more than any amount of discussion about backup policy, and most teams have never had it.

If the restore fails, you have just found that out on a Tuesday instead of during an outage. That is the entire point.

Give everyone their own login, then turn on MFA

This is usually an afternoon. Create an account per person, move everybody over, then disable the shared one rather than leaving it in place “just in case”. A shared account that still works is a shared account.

Rotate anything that has ever been in a repository

Deleting the file does not help, because git keeps history. So change the actual credentials: database passwords, API keys, tokens. Then move the values into environment variables or a secret store so it does not happen again.

Put one alert in place, not twelve

Start with the simplest useful question: is the site answering? One check, alerting to somewhere people already look. Get that trusted before adding anything else, because a noisy start teaches everyone to ignore the channel. You can use the free 14-day uptime trial here to cover this without installing anything.

Write the rebuild down while you are doing it

Next time you rebuild anything, keep a document open and record each step as you take it. Written afterwards, it is a summary. Written during, it is a runbook. The difference shows up the first time somebody else has to follow it.

Set restart policies and log limits on your containers

Two lines in a Compose file stop a dead container staying dead and stop one service filling the disk with logs. Both are defaults that should have been the other way round, and neither needs a project to fix.