NetOps

WHAT IT IS NetOps is the operation of network infrastructure as a dependable service: maintaining an accurate picture of topology and addressing, controlling change to routing and firewall policy, monitoring the paths traffic actually takes, planning capacity, and responding when connectivity is the failure. **Not this:** NetOps is not DevNetOps: it is the operation of the network itself — topology, change control, monitoring, capacity and response — rather than the practice of managing network configuration as code through automated pipelines. WHY IT EXISTS The network is the dependency every other system shares and the one least visible to the teams that depend on it. When it degrades, the symptom appears everywhere else first: applications time out, databases look slow, and several teams investigate their own systems in parallel while the cause sits between them. Network change carries unusual blast radius — a single routing or filtering change can disconnect an entire site — which is why change control matured here earlier than in most of software. WHEN TO USE IT It applies wherever you operate network infrastructure you are responsible for: physical estates, cloud network topology, or the interconnects between them. Cloud does not remove it; it renames it, and a badly designed cloud network is harder to see than a badly designed physical one. WHO OWNS IT A network team owns topology, addressing, routing and policy. Security jointly owns filtering policy, because a firewall rule is a security control and a connectivity control at once, which overlaps /secops. Application teams own declaring what connectivity they need — the recurring failure is application teams discovering their requirements during an incident. Where a site or facility is involved, facilities ownership matters too. WHAT GOOD LOOKS LIKE Topology and addressing are documented and current enough to be used during an incident rather than rebuilt from memory. Changes are reviewed, scheduled, and have a tested back-out — including the case where the change removes your own access to the device. Monitoring covers paths and end-to-end reachability, not only device health, because every device can be up while the path is broken. Capacity is planned against measured growth rather than replaced after saturation. Configuration is backed up and restorable. Segmentation is deliberate and documented rather than accumulated. HOW TO IMPLEMENT Start with the inventory and the topology diagram, and date it, because an undated diagram is a historical document. Establish change control with a written back-out for every change and an explicit answer to the out-of-band access question. Add path and reachability monitoring alongside device monitoring. Back up device configuration automatically and test a restore. Review segmentation and filtering policy against what applications actually need, removing the accumulated rules nobody can attribute. Automating this is the subject of /devnetops, and it is worth doing after the manual process is sound rather than before. HOW TO ASSESS YOURSELF Ask when the topology diagram was last accurate. Ask what happens if a change removes management access to a device mid-change. Ask whether monitoring would notice a path failure between two healthy devices. Take the scored self-assessment at /assess and plan with /roadmaps.