SysOps

WHAT IT IS SysOps is the administration of running systems: keeping operating systems and packages patched, managing configuration so that a machine's state is known rather than remembered, watching capacity, taking host-level backups, and being able to restore. **Not this:** SysOps is not InfraOps: it administers the systems that are already running — patching, configuration, capacity and recovery — rather than defining and provisioning the estate they belong to. WHY IT EXISTS Systems drift. A server configured correctly two years ago has since been touched by several people under pressure, and the difference between its documented and actual state is where incidents come from. Patching is the other half: the overwhelming majority of exploited vulnerabilities have had a patch available, so the operational question is never "is there a fix" but "how long do we take to apply it". Neither of these is glamorous, and both are load-bearing. WHEN TO USE IT It applies wherever you run systems you are responsible for — including the single virtual machine somebody spun up for a side project and the appliance nobody logs into. Managed services reduce the surface but rarely eliminate it, which is the honest version of the /noops argument. WHO OWNS IT A systems or infrastructure team owns the fleet, the patch cadence and the configuration baseline. Application owners own the configuration specific to their service. Security owns the patch policy and the exceptions register, overlapping /secops. The unowned machine is the recurring theme of this discipline: every estate has one, and it is usually the one in the incident. WHAT GOOD LOOKS LIKE Every host is inventoried and has an owner, including the forgotten ones. Patching runs on a stated cadence with a measured lag from release to deployment, and exceptions are recorded with a reason and a date. Configuration is managed declaratively so that state is reproducible, and manual changes are detected as drift. Capacity has headroom that somebody chose. Backups exist at the right granularity and — the item that separates real practice from paperwork — restores are tested on a schedule, not assumed. HOW TO IMPLEMENT Inventory first, because you cannot patch what you have forgotten. Establish the patch cadence and measure the lag; the number is usually worse than the policy. Move configuration into a declarative tool so drift becomes visible, and resist the temptation to fix drift by hand without changing the definition. Set capacity thresholds with an owner. Then test a restore, end to end, and time it — an untested backup is a belief. The estate-level view belongs to /infraops and the host-level telemetry to /observability-engineering. HOW TO ASSESS YOURSELF Ask how many hosts you run and compare that number with the inventory. Ask how long ago the oldest unpatched critical vulnerability was published. Ask when a restore was last performed from backup rather than discussed. Take the scored self-assessment at /assess and plan the gaps with /roadmaps.