Managed IT
Nobody should be scared
to reboot a server.
Physical or virtual, Windows or Linux, in your building or in a cloud account, every server gets upgraded, patched and maintained by us. Patches roll out in rings, so the update that breaks something breaks the test box first.
- Windows and Linux, on anythingWhat’s in scopeWatching
- Hypervisors and the hosts under themWhat’s in scopeWatching
- Patch rings you can roll backWhat’s in scopeWatching
- Capacity, before it runs outWhat’s in scopeWatching
- Life after end of supportWhat’s in scopeWatching
- A build anyone can repeatWhat’s in scopeWatching
Foothills Digital—Sentrello Premier Partner
- AWS
- Azure
- Google Cloud
- DigitalOcean
- On-premises Linux
- On-premises Windows
Every one of our people holds active certifications on the platforms they work on.
Sentrello is our only partnership. On the clouds, it's our people who hold the certifications. We don't claim a partner tier, and we'll keep saying so until that changes.
Where this usually starts
Load-bearing by accident
Somebody set it up for one job. Three more jobs moved in. Then the person who built it left, and took the notes with them.
- One box has years of uptime, and that number should worry you more than it impresses you.
- Patches go on when someone remembers, which tends to be the week the vulnerability makes the news.
- The hypervisor host is full, so every new VM starts a negotiation over which old one has to go.
- Its operating system left support years ago, and the app on it refuses to run anywhere else.
- Nobody knows what’s on that disk, so nobody dares delete anything from it.
What we do instead
We make every server boring
Boring is the goal. Built from a written definition, patched on a schedule you signed off, monitored for the things that actually fail, and documented well enough that any of our engineers could rebuild it from scratch. Patches hit a test ring, then a canary, then everything else, and each ring has a rollback we’ve actually run. That server everyone was afraid of? It gets rebooted. On a Tuesday, on purpose, with a snapshot taken first.
How it works
How we look after your servers
The reboot is the dull bit. Everything before it is what makes it dull.
List what’s running, and why
Every host, VM and cloud instance, with its operating system, its patch level, what it runs and who’d notice if it stopped. The estate is nearly always bigger than the list you gave us.
Monitor it, and capture it as code
Disk, memory, CPU, services, certificate expiry, backup results, and the log lines that turn up right before a failure. Each server’s build gets written down as configuration, so drift from what it should be shows up on a screen.
Patch in rings, with a way back
Test servers first, then one production canary, then the rest, on a cadence you approved. Every ring gets a snapshot before it starts. A patch that breaks the canary never reaches the ring behind it.
Script away the repeat offenders
A log that fills, a service that hangs after an update, a certificate that lapses. Each gets a scripted fix with an agreed trigger, so the response doesn’t wait for somebody to wake up. By the third time it happens, nobody notices at all.
Upgrade and retire on a plan
End-of-life systems get a date and a route off, well before the vendor stops shipping updates. Capacity gets reviewed before the host fills. The box in the cupboard becomes a VM, maybe a cloud instance later, and the application keeps running the whole way.
What’s in scope
Windows and Linux, on anything
Physical hosts, virtual machines and cloud instances, in your server room, a colo rack, or an AWS, Azure, Google Cloud or DigitalOcean account. One toolset and one runbook cover the lot, worked by engineers certified on each platform.
Hypervisors and the hosts under them
The virtualisation layer is a server too. Host patching, cluster balancing, storage, and a failover we actually test, so losing a host means a migration rather than an outage.
Patch rings you can roll back
Test, canary, production, each one snapshotted first. You set the schedule. We keep the discipline.
Capacity, before it runs out
Disk, memory, CPU and license counts tracked against how fast they’re growing, so the host that’ll be full by spring shows up on the plan in autumn.
Life after end of support
Every OS version’s end date goes on the calendar with a route off it. Where an app only runs on the old one, we isolate it and protect it while we work on the exit.
A build anyone can repeat
Each server exists as a definition in your repository, with what it runs and why noted beside it. Losing the hardware is a nuisance. Losing the knowledge of how it was built was always the real disaster.
Related
Data Backup & Disaster Recovery (BDR)
Automated backups, one copy nobody can delete, and a recovery plan we’ve actually rehearsed. Whether the files copied was never the real question. Will the business open on Monday?
Cloud Migration & Management
AWS, Azure, Google Cloud or DigitalOcean: we move your workloads across, then run them there day to day. Accounts, sizing, tags and access get done properly from the start, so next month’s invoice doesn’t make anyone gasp.
Network Management
Your LAN, your WAN and your Wi-Fi, watched and configured as one system, right down to the circuit into the building. So when the office shouts that the internet’s gone, we already know which port it really was.
How many servers, and where do they live?
A rough count of hosts and VMs, the Windows and Linux split, where they sit, and the one you’re quietly afraid of.
Tell us and we’ll say what we’d patch first, and which box is closer to the end of its life than anyone’s admitted.
- What we arePlan, create, launch, maintain
- What we areSentrello Premier Partner
- What we areEvery quote written for you