A server runs fine until the day nobody has looked at it for a year.
Most small business systems run on one or two Linux machines. They work, so nobody opens them. Then a certificate expires on a Sunday, or the disk fills with log files, or the last person holding the key leaves.
Server management is the unglamorous arrangement that keeps any of that from becoming a crisis. It is mostly a short list of small things done on a schedule.
Server management means somebody is answerable for the machine your application runs on. Patches get applied, certificates renew before they expire, disk and memory are watched, and backups are restored elsewhere to prove they work. There is a written record of who holds which key, and a named person to ring at night.
Where it earns its place.
The list that actually gets done
- Security patches on the operating system and the packages
- SSL certificates renewed before anybody notices them
- Backups held off the machine, and a restore tested into a spare environment
- Disk, memory and load watched, with an alert that reaches a person
- Logs collected in one place and rotated before they fill the disk
- Root and SSH keys recorded, and removed when somebody leaves
What we run on
Plain Ubuntu with Nginx, usually with the application in Docker, on whichever cloud you already pay for.
- AWS, Azure, Google Cloud and DigitalOcean
- One virtual machine, where the system is small enough to want one
- Separate development, staging and production servers
- A managed database where the monthly cost buys back real work
- Cloudflare in front for DNS and traffic protection
What happens when something breaks
- Alert
- Acknowledge
- Diagnose
- Fix or roll back
- Write it down
- An alert that reaches a person, not a channel nobody reads
- A way back to the previous release when a deployment caused it
- The database restored from last night if it comes to that
- A short note afterwards on what happened and what changed
We do not staff a night desk, and we would rather say so than let you assume one. Cover and response times are agreed in writing before they are needed.
Taking over a server somebody else set up
Common, and usually the first thing we are asked to do.
- Finding out what is really running on the machine
- Getting the access out of one person’s laptop
- Checking whether a backup exists and whether it restores
- Writing down the parts nobody documented
- A list of what to fix now and what can wait
When you do not need us for this
- You have a system administrator who is already doing it
- The application sits on a managed platform that patches itself
- A static site on a CDN, where there is no server to manage
- Nobody in the business will act on an alert at eleven at night
The last one matters most. Monitoring with nobody to act on it is a record of when things broke, not a way of keeping them working.
When this is the right choice.
- The application matters to the business and runs on your own server
- Nobody in-house is answerable for patches and backups today
- The person who set it up has left, or is a vendor who stopped replying
- The access and the keys need to belong to the company rather than an individual
- Several environments exist and they have quietly drifted apart
When it is not.
- A business with its own system administrator, unless you want a second pair of eyes on the backups
- An application on a managed platform where the provider already handles the machine
- A brochure website on shared hosting, where the host does this for the price you already pay
- A team that will not agree who may approve a change at midnight
Questions we are asked about it.
Do you host it, or do we?
The cloud account stays in your name and you pay the provider directly. We hold access in order to work on it. Nothing you depend on ends up locked inside our account if we stop working together.
What do you need to take over an existing server?
Access, and an hour with whoever set it up if they are still reachable. If they are not, we work it out from the machine itself, which takes longer but is ordinarily possible.
How often are backups tested?
On a schedule we agree, by restoring into a separate environment and opening the application. A backup nobody has restored is a belief rather than a backup.
What if the server goes down at night?
That depends on the cover you have asked for, which we put in writing rather than imply. The alerts are automatic. A person answering at three in the morning is an arrangement with a cost, and you should choose it knowingly.
Can you move us to a different cloud?
Yes, and it is less dramatic than it sounds once the application is already in Docker. We rehearse the whole move on a copy before anybody touches the live system.
Will this make the application faster?
Sometimes, where the machine is the limit. More often the application or its database queries are the limit, and a bigger server simply costs more each month for the same problem.
Services that use it.
What it sits with.
Not sure Server management is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private