From Band-Aids to Best Practices: USAA's Network Automation Journey#

Brandon Cavett — USAA (Senior Infrastructure Engineer)

• Why: A concrete, Arista-centric DC story of the pattern most enterprises actually live: Day-1 rack provisioning automated early, Day-2 becoming the real problem, and config-as-code (AVD) as the resolution — including retrofit difficulty and engineer-training costs.
• What: USAA built end-to-end automated rack provisioning (CloudVision config builders via API, switch provisioning in under an hour hands-off), then hit Day-2 reality: CLI-first changes, drift between designed and running config in CloudVision when standalone Ansible playbooks pushed directly to switches, and heavy per-playbook testing. They adopted Arista AVD (Architect, Validate, Deploy), which standardized config fabric-wide, enabled sweeping changes quickly, and let them use CloudVision's change-control process to pre-stage and review changes. Most recent environments are 100% config-as-code; the Day-1 provisioning pipeline was replaced by AVD entirely.
• How: AVD (Ansible collection) generates config from structured intent and deploys via eAPI or CloudVision; pre-provisioning pipelines export the data needed to add new switches into AVD. Next steps: wrap the whole process in CI/CD with Arista Cloud Test (ACT) for pre-deployment testing and ANTA for post-validation, plus retrofitting legacy environments.
• Where applicable: USAA/Arista-specific (AVD, CloudVision, ACT/ANTA are Arista tooling), so directly applicable only to EOS/CVP estates — but the drift problem from out-of-band playbook changes, the change-control-integration pattern, and the "training traditional network engineers on Git/CI/Ansible is the hard part" observation generalize broadly.