Ten practice areas, and what each one actually delivers.
These are not separable in practice. A backup regime is only as good as
the monitoring that notices it stopped; an access layer is only as good as
the directory behind it. They are listed apart because that is how they
get scoped, not because they get built that way.
Most estates are not under-instrumented. They are full of alerts nobody reads, hosts that stopped reporting without anyone noticing, and thresholds that exist only inside a database. The work is designing collection that fits the equipment, then making the problem list mean something again.
Collection method chosen per device class rather than applied uniformly
Retention and rollup sized so history stays affordable at scale
Proxy topology for remote sites and constrained links
Standing-problem audit with every false positive traced to cause
Trigger dependencies so one fault raises one alert, not forty
Metrics, logs and traces correlated instead of living in three tools
Monitoring and control planes are the things you need working during an incident, which is exactly when they are most likely to be the casualty. Clustered servers with automatic failover, replicated databases, and a floating address so collectors follow the active node instead of going dark with it.
Native clustering with tested, documented failover
Database replication with a deliberate promotion procedure
Failover verified end to end — primary stopped, behaviour observed
Collector follow-through checked, which is the part usually missed
Documented recovery time, measured rather than estimated
Zabbix HA PostgreSQL TimescaleDB MariaDB keepalived Corosync
Design and operation of Proxmox VE estates from a single node to a multi-node cluster: guest layout, storage topology, resource limits that actually hold, and a naming and inventory discipline that keeps a hundred guests legible.
Node and cluster design sized to real workload, not to a spec sheet
LXC and KVM chosen per workload with the trade-off written down
ZFS pool layout, ARC tuning and scrub scheduling
Capacity headroom tracked as a metric with a threshold, not a feeling
Disk-failure and pool-rebuild procedures rehearsed before they are needed
Templates and provisioning automation so a new guest is repeatable
Proxmox VE LXC KVM / QEMU ZFS cloud-init Ceph-ready layouts
Backup design where the deliverable is a demonstrated restore, not a green job list. Retention modelled against how far back you would realistically need to go, deduplicated storage sized for it, and verification jobs that read the data rather than trusting the index.
Retention and pruning modelled against real recovery requirements
Deduplicated, incremental backup with garbage collection scheduled
Verify jobs that read blocks back, not just check the catalogue
Documented restore procedure, performed at least once on real data
Off-box and offsite copy with the failure domain written down
Capacity alerting before the datastore fills, not after jobs start failing
Segmentation, routing and name resolution that stay predictable.
Network design and troubleshooting across the layers that break in practice: VLAN segmentation and inter-VLAN policy, multi-site overlay routing, and DNS and DHCP that agree with each other and with the inventory.
VLAN segmentation with an explicit inter-VLAN policy, default deny
Multi-site WireGuard mesh with jump-host access and no inbound rules
Authoritative internal DNS with forward and reverse records audited
DHCP reservations reconciled against monitoring and inventory
802.1X and RADIUS authentication for wired and wireless
Packet-level troubleshooting when the logs have stopped being useful
WireGuard UniFi Technitium DNS Pi-hole FreeRADIUS nftables SNMP ntopng
Sites and applications hosted on infrastructure you can inspect.
Hosting for static sites, dynamic applications and internal tools — from the origin server up through TLS, reverse proxy and edge caching. Built to be boring: hardened origins, atomic deploys, and a rollback that is one command rather than a rebuild.
Static and application hosting with atomic, reversible deploys
Reverse proxy and automatic TLS across many hostnames
Zero-inbound publishing through an outbound tunnel — no port forwards
Origin hardening: no directory listings, no stray backups, correct headers
Cache strategy split between immutable assets and revalidated HTML
Styled error pages and a health endpoint that means something
Staging that mirrors production closely enough to be worth having
Single sign-on and access control across an estate that grew one service at a time. A central directory as the source of identity, an OIDC provider in front of everything, and multi-factor authentication that applies to the admin interfaces as well as the pretty ones.
Central directory with group membership driving authorisation
OIDC single sign-on in front of services that have no auth of their own
Multi-factor enforced on administrative interfaces
Default-deny access policy with documented, reviewable exceptions
Credential management and rotation with a real place secrets live
Security event monitoring and log retention for after-the-fact answers
Secret scanning in CI so a key cannot reach a public repository
Mail that arrives, and that you can prove arrived.
Self-hosted and hybrid mail: transport, mailbox storage, filtering and — the part that decides whether any of it works — deliverability. SPF, DKIM and DMARC aligned and monitored, with a relay path chosen so alert mail is not the first thing a receiver drops.
Postfix and Dovecot with LDAP-backed mailboxes and aliases
SPF, DKIM and DMARC published, aligned and monitored for failures
Spam and policy filtering tuned against real corpus, not defaults
Submission, relay and smarthost paths chosen per class of mail
Webmail and client access with TLS enforced
Alert mail treated as its own deliverability problem, because it is
Useful models on your own hardware, and a gateway in front.
Local inference for teams that cannot or will not send their data to a vendor. Small and mid-sized open models served on your GPUs, with a private chat interface, retrieval over your own documents, and an OpenAI-compatible gateway so existing tooling points at it without being rewritten.
Model selection and quantisation matched to the GPU you actually have
Private chat UI with per-user accounts behind the estate's single sign-on
Retrieval over internal documents and runbooks, scoped by permission
OpenAI-compatible endpoint so existing clients need no code change
Provider pooling and routing across local and hosted models by cost
GPU utilisation, VRAM and queue depth monitored like any other resource
Operational guardrails: request limits, audit logging, no silent egress
Configuration you can diff, and a wall you can read.
The layer that keeps the rest honest: configuration in version control with a promotion path, CI that gates changes before they reach production, drift detection between what you think you run and what you run, and operations displays built on live data.
Templates and configuration under version control with idempotent import
A test instance that cannot page anyone or overload production
CI pipelines that lint, test and secret-scan before anything ships
Self-hosted runners for jobs that need a route into a private network
Drift reconciliation between inventory and what is actually monitored
API automation for bulk operations, audits and reporting
Wall displays driven by live APIs that degrade legibly when a source dies
Runbooks written for the person on call at 3am, not for the author
Most work starts as an assessment, because it is the cheapest way to find out whether the expensive thing is necessary.
Assessment
Days
A read of what you are running and what is currently untrue about it. Ends in a written findings list ordered by what it costs to fix versus what it costs to leave.
Fits when: You inherited an estate, or you suspect the dashboards are lying.
Build
Weeks
Design and delivery of a defined system — a monitoring estate, an access layer, a backup regime, a hosting platform — including the documentation and the handover.
Fits when: You know what you need and want it built once, properly.
Remediation
Weeks
Targeted work on a system that exists but is not trusted: alert noise, silent gaps, failed restores, an access layer nobody can reason about.
Fits when: It technically works and nobody believes it.
Ongoing
Retained
Continuous operation and improvement, with change history, scheduled verification of the things that must not quietly break, and someone to call.
Fits when: You need the estate to keep being true after the project ends.