Role
Systems administrator
What do you not know about your systems until something stops working? Usually which of them have no current backup, which run on a version with no support, and who actually knows how to rebuild them from scratch.
Intro call
Four questions we would start with
What do you not know about your systems until something goes down?
Most often that the backup had been running for months but nobody ever checked whether anything can be restored from it. An untested backup is not a backup, it is a file.
What is left behind by an administrator who leaves the company?
If it is passwords and documentation, a great deal. If it is passwords, almost nothing - because the configuration lived in their head and left with them.
Which kind of ticket comes back most often?
Usually two or three of them, repeating for years and solved from scratch every time. Nobody has counted them, because each one on its own looks like a trifle.
Where does the information go that a server is filling up?
If nowhere, you will find out about it at the moment it stops accepting data, which is the worst possible one.
We take over the watching and the routine, you keep the decisions about infrastructure
Monitoring the state of things, watching backups and updates, keeping the configuration documented and handling repeat tickets can be taken off the desk. The decisions about what to change and when stay with the administrator.
- The backup is verified, not only taken. - A test restore is a planned activity, not something done for the first time on the day of the outage.
- The state of a system speaks for itself. - Space, load, certificates, versions - with a signal before the threshold, not after it has been crossed.
- The configuration is written down outside the administrator's head. - Not in order to replace them, but so that their holiday stops being an operational risk.
Scope
What can be taken off systems maintenance
Twenty-one example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to what you run.
State and availability
- Monitoring service availability from one place
- A signal when a resource approaches its threshold
- Pointing out services with no monitoring at all
- A notification about an expiring certificate
- A summary of outages by service and cause
Backups and restores
- Checking that backups ran to schedule
- A signal when a backup did not complete correctly
- A schedule of test restores (decision on scope: the administrator)
- A register of restore results
- Pointing out systems with no backup policy assigned (assessment: the administrator)
Updates and versions
- An inventory of systems with versions and support end dates
- A signal when a version is going out of vendor support
- A summary of pending updates by severity
- A proposed maintenance window against the load (decision: the administrator)
Configuration documentation
- A description of the configuration generated from the state of the system (verification: the administrator)
- A register of configuration changes with the author and the date
- Pointing out systems with no documentation at all
- The procedure for rebuilding a system from scratch (content: the administrator)
Repeat tickets
- A summary of tickets by kind and frequency
- Pointing out tickets resolved by the same step every time
- A proposal to remove the cause for good (decision: the administrator)
A day's work
Today
- You find out about a full disk when the service stops working
- Backups run, but nobody has checked whether anything can be restored from them
- Your versions and support dates are in a spreadsheet from a year ago
- You remember the configuration, so it is not written down anywhere
- You solve the same ticket once again with the same step
- You agree the maintenance window by email with several departments
With AI assistance
- A resource approaching its threshold reports itself before the outage
- A failed backup and the result of a test restore are both visible
- A version going out of vendor support signals itself in advance
- The configuration description is generated from the state of the system, you verify it
- Repeat tickets are counted, so you can see what is worth removing for good
- The maintenance window is proposed against the actual load
- Recoverability after an outage
the backup is evidence rather than an assumption
test restores are a planned activity
- Current versions
fewer systems outside vendor support
support dates are in the inventory and flagged
- Warning before failures
some outages never happen at all
resource thresholds warn before they are crossed
- Knowledge of the configuration
the administrator's holiday stops being a risk
the configuration is described outside their memory
We start with backups, because it is the one area where a mistake cannot be undone.
- Step 1
Backups and test restores
Checking they ran, a signal for a failed backup, the first test restore. This usually already shows which systems have no cover.
- Step 2
State and thresholds
Availability, space, load, certificates - with a warning before the threshold.
- Step 3
The version inventory
What you have, on which version, and how long the vendor supports it.
- Step 4
Documentation and repeat tickets
The configuration description from the state of the system, and the summary of recurring tickets. Last, because it needs the inventory to be in order.
Common questions
Questions that come up at the first meeting
Does this mean fewer administrators are needed?
In most companies there is one administrator handling more than they should - which is where the debt in updates and backups comes from in the first place. Taking the watching off the desk does not shrink the team, it finally allows the work that has been put off for months. Usually it turns out there is more work than it seemed, not less.
How is this different from what a platform team does?
A platform team builds the road a change travels to production on. An administrator maintains what already stands there. In smaller companies the same person does both, and then the first loses to the second, because maintenance is always more urgent.
Does this fall under the AI Act?
Systems maintenance is not a high-risk use. The line runs at log data, which can point to the activity of particular people: it serves diagnostics and security, not the assessment of working time - using it the second way would be employee monitoring and would need a separate legal basis.
Still have a question that is not here? Book a call
Next step
When did you last restore anything from a backup?
We will show you what systems maintenance looks like when the backup is verified and a resource approaching its threshold speaks up before the outage.