Operations and support: what happens to an application after you launch it

An application you cannot see is not deployed — it is abandoned. The difference between those two states is not in the code, but in whether you hear about a problem or your customer does.

The project is handed over, the invoice goes out, and for most suppliers that is the end. The application, meanwhile, lives on: its database grows, dependencies shift, certificates expire, and sooner or later somebody makes a change that breaks something. Operations is what decides whether that gets handled calmly or in a panic.

Monitoring is about a question, not charts

The point of monitoring is not a handsome wall display. It is being able to answer one question: is it working for users right now?

Surprisingly simple things suffice — as long as they are genuinely watched:

• Error rate and speed on the paths that matter. Not the average, which hides that a tenth of people wait eight seconds for a page. What matters is how the slowest slice of visits is doing.
• Is everything still running? Not just the web server, but queues and scheduled jobs too. A dead worker does not show immediately — it shows a day later, when nobody's email went out.
• Is anything running out? Disk space, database connections, certificate validity. These are outages you can see weeks ahead.

And one rule holds: an alert nobody can act on should be deleted. Three notifications a day that nobody handles reliably train a team to ignore the fourth one, which mattered.

A backup that has never been restored is not a backup

This is the most common silent hole in operations. Backups run, the log says "OK", and on the day they are needed it turns out an empty database has been backed up for years, or that a restore takes twelve hours.

So backups come with a regular trial restore — not a check that a file exists, but an actual restore into a separate environment and a look at whether the data in it makes sense. Two numbers need to be stated as well: how much data you can afford to lose and how long a return to service may take. How often you back up, and what it costs, follows from those.

Availability: what can be promised and what cannot

An agreed availability target is useful, but only when the rest is said alongside it. The percentage on its own means nothing until it is clear what counts as downtime, over what window it is measured, and what happens when it is missed.

Equally important is what nobody can promise: the availability of third-party services. When a payment gateway or a carrier's API goes down, the application should survive it with a comprehensible message — but it cannot guarantee it.

That is why we talk with clients about agreed availability and response times by severity, rather than one number in a contract.

Shipping changes is part of operations

Most outages do not come out of nowhere. They come with a change. Which is why operations and the way you deploy cannot be separated:

• Deployment is automated and identical every time — not manual, and not dependent on who is on duty.
• Database changes have to be backwards compatible, or you cannot roll back without losing data.
• Going back to the previous version has to have been rehearsed, not merely documented. A rollback first attempted during an incident usually does not work.

What we do

We deploy applications in containers, so they run the same with us, with you, or with another provider — and moving is a deployment rather than a rewrite. Operations means monitoring with alerts, backups with a proven restore, agreed availability and response times, and changes shipped through automation.

We can also operate something we did not build — that starts with an audit, so we know what we are taking on. If you want to know what this would mean for your application, get in touch.