Operations & maintenance

Maintenance is more than answering tickets. Updating, decommissioning and testing restores need their own time in the contract, or they never happen. The hard part is keeping responsibility joined up when it is split across several parties.

Who does what when something stops working?

An alert goes off. Who receives it, who decides how serious it is, and who has the access to do something about it? That can be three people at three parties, and all three belong in the contract. Responsibility splits into three layers, and the boundaries between them should be written down.

• The application. The code, its dependencies, releases and the flows the business relies on. More under application management.
• The infrastructure. The cloud provider looks after the hardware and, depending on the service, parts of the backups. But you, or whoever you give the job to, choose how long backups are kept, who has access and what should happen when something breaks. We can take that on: cloud and infrastructure.
• The business. What may change, when a release may go out, how long an outage is acceptable and which data must not be lost. We cannot make those decisions for you, but we can give you what you need to make them.

What a handover takes

Before we take responsibility for a system, we want to know what we are taking responsibility for: who owns access to code, environments and accounts, how a release is done, which flows the business cannot do without and when someone last actually restored a backup. If documentation or tests are missing, that is often the first piece of work.

Bring what you know about the system: who built it, who has access, when something last broke and how it was fixed. Get in touch with what you have, and we will start there.