Network Automation, Programmability, and Operability
This domain covers the programmability stack, infrastructure-as-code workflows, telemetry-based operations, and designing for change safety.
The programmability stack
SNMP polling and traps remain for legacy OIDs and thresholds, but scale poorly: N devices × M OIDs × polling interval grows linearly and consumes device CPU. NETCONF (RFC 6241) over SSH with YANG models, RESTCONF over HTTPS, and gNMI/gRPC give structured, transactional configuration and streaming state. Model-driven telemetry pushes data on change or on interval from the device to a collector, so scale is bounded by collector capacity and data rate rather than by polling frequency. Know the difference between native YANG models and OpenConfig models - the same intent may be expressed differently across vendors.
Infrastructure as code
Declarative intent plus idempotent execution: re-running an automation must converge the device, not reapply blindly. Keep configuration as templates (Jinja2) rendered from a source of truth (IPAM, NetBox, CMDB), store everything in Git, and run a pipeline that lints, renders, diffs against the running config, and only then applies with a rollback path. Zero-touch provisioning via PnP or ZTP with DHCP options and cloud redirect bootstraps new hardware without a truck roll.
Operability and observability
Collect flow data (NetFlow, IPFIX, sFlow) for traffic profiling, syslog with consistent severity and accurate NTP for correlation, and synthetic tests for user-path assurance. Alert on leading indicators (queue drops, interface errors, CPU trend) rather than only on hard failures. Detect configuration drift continuously, because manual changes bypassing the pipeline are the main reason automation is distrusted.
Worked example
A 500-device campus polls 10 OIDs every 5 minutes over SNMP: 5,000 OID polls per interval, growing linearly with devices. The operations team needs per-second interface utilization during incidents but hourly CPU trends otherwise. Design: keep SNMP for the low-frequency CPU and environmental polls, add gNMI dial-out telemetry at 10 s interval for interface counters, sized by collector throughput, and add a heartbeat alert so a device that stops streaming is detected rather than silently missing from dashboards. Reason: choosing one mechanism for both needs either wastes CPU or loses resolution.
Traps that cost marks
- Automating an undisciplined process, which simply makes outages faster and wider.
- Non-idempotent playbooks that reapply and flap production interfaces on rerun.
- No pre-change diff, validation or rollback, so a bad template hits every device at once.
- Credentials in plaintext scripts; use vaulting and per-task credentials.
- Assuming the controller is the source of truth while engineers still make out-of-band CLI changes.