Network Automation Workflow

The same shape, every time

Every automation task you've seen so far — NTP checks, config backup, compliance checking — follows the same underlying shape. This lesson slows down and looks at each stage on its own, because understanding what each one is actually for is what lets you recognize the pattern in a task you haven't automated before.

Inputwhat do you want to check or change?
Inventorywhich devices?
Connectopen an SSH or API session
Executerun the command, or push the change
Handle failureswhat if a device doesn't respond?
Validatedoes the result match what you expected?
Reportsummarize what happened

Input: what are you actually trying to do?

Every automation task starts as a question someone would otherwise answer by hand: "are these switches synced to NTP?" "did the VLAN push actually apply?" "what firmware version is every access switch running?" Writing that question down clearly, before anything else, is what everything downstream depends on — a script can't validate a result against an expectation nobody stated.

Inventory: which devices, exactly?

Before connecting to anything, you need to know what "every device" actually means. Sometimes that's a simple list — a CSV of hostnames and IPs. Sometimes it's a filtered subset: "every access switch in Building 3," not the whole network. Getting the inventory step wrong (missing a device, or including one you didn't mean to) means the rest of the workflow runs perfectly against the wrong set of devices — which is worse than an obviously broken script, because nothing looks wrong until someone notices a device was never checked.

Quick checkConcept check

What is the 'inventory' stage of an automation workflow actually responsible for?

Running the command against every device on the network, no matter whatDefining exactly which devices the script should act on, before it connects to any of themDeciding what the correct configuration should beFormatting the final report

Connect and execute: doing what a person would do by hand

These two stages are the most literal translation of the manual process: open a session (typically SSH, sometimes an API), and run the same command or push the same change a person would type. Nothing conceptually different happens here — it's still the same protocol, the same command, the same device. The script is just the one holding the keyboard.

Handle failures: the stage manual work skips by accident

Here's something a person does automatically, without thinking about it, that a script has to be told to do explicitly: what happens when device 23 out of 50 doesn't respond?

A person notices immediately — the SSH session times out, they see it happen, and they move on to the next switch, mentally noting "23 didn't respond, I'll check on that separately." A script doesn't have that instinct. Without explicit failure handling, one unreachable device can stop the whole run, or worse, get silently skipped with no record that it was ever missed.

Good failure handling for a 50-switch NTP check looks like: if switch 23 doesn't respond within a reasonable timeout, log it as unreachable, move on to switch 24, and finish the other 49. The final report then separates "confirmed synced," "confirmed out of sync," and "couldn't be reached" — three different outcomes that all need different responses from the engineer reading the report.

Silence is the failure mode to design against

The worst outcome isn't a script that stops on an error — it's a script that fails quietly and reports success anyway. If switch 23 never got checked, the report needs to say so. An automation task that can't tell you what it didn't manage to do isn't trustworthy, no matter how well it handles the devices that did respond.

Quick checkScenario

A script is checking NTP sync across 50 switches. Switch 23 doesn't respond within the timeout. What should good failure handling do?

Stop the entire script immediately so no further devices are checkedLog switch 23 as unreachable, skip it, continue checking the remaining 49, and report it separatelyRetry switch 23 indefinitely until it responds, before checking any other deviceSilently skip switch 23 and report that all devices were checked successfully

Validate: successful and correct are not the same thing

A command can run without any error and still not tell you what you needed to know. show ntp status against switch 14 might return cleanly — no timeout, no error — while showing that the switch still isn't synced. The command succeeded. The check failed. Those are different things, and a workflow that only checks "did the command run OK?" would miss that entirely.

Validation is the stage that closes that gap: taking the output that came back and comparing it against what you actually expected, not just confirming that something came back at all.

Quick checkConcept check

Why does the 'validate' stage matter, even after a command has already run successfully?

It doesn't — if the command ran without error, the task is doneBecause a command can execute without error and still return output that doesn't match what was expected (e.g. still not synced)It only matters for configuration changes, never for 'show' commandsIt's only needed if the device is unreachable

Quick checkMyth check

Is running a command successfully on a device the same as the automation check succeeding?

Yes — if the command didn't error, the check passedNo — success just means the command executed; validating the result against what was expected is a separate stepYes, as long as the device is reachableNo — a command either fails or the whole script fails

Report: what the engineer actually reads

Everything upstream exists to produce one thing a person can act on quickly: a report that separates what's fine from what needs attention, and is honest about anything that couldn't be checked at all.

Here's the same workflow, written as a small script — you're not expected to read this as a Python lesson, just to see each stage from the diagram show up as a real line of code, including the failure handling this lesson focused on:

check_ntp.py

devices = load_inventory("switches.csv")    # Inventory

synced, out_of_sync, unreachable = [], [], []

for switch in devices:                      # loop = "repeat for every device"
  try:
      session = connect(switch, timeout=5)     # Connect
      output = session.send_command(
          "show ntp status"                    # Execute
      )
  except ConnectionError:                      # Handle failures
      unreachable.append(switch)
      continue                                 # move on, don't stop the run

  if is_synced(output):                        # Validate
      synced.append(switch)
  else:
      out_of_sync.append(switch)

send_report(synced, out_of_sync, unreachable)     # Report

Notice the try/except block — that's the 'handle failures' stage. Without it, one unreachable switch (a ConnectionError) would stop the loop before the other 49 ever got checked.

Quick checkOrdering

Put these stages of an automation workflow in the correct order: Validate, Connect, Handle failures, Inventory, Execute, Report.

Inventory → Connect → Execute → Handle failures → Validate → ReportConnect → Inventory → Execute → Validate → Handle failures → ReportInventory → Handle failures → Connect → Execute → Validate → ReportExecute → Connect → Inventory → Handle failures → Validate → Report

This shape doesn't change

Whether the task is checking NTP, pulling a backup, or validating a VLAN push, it's the same seven stages underneath. Once you can see this shape in a task, you already know what an automation script for it needs to do — the details change, the workflow doesn't.

Key takeaways

Every automation task follows the same shape: input, inventory, connect, execute, handle failures, validate, report.
Inventory has to be right before anything else runs — a wrong device list means every later stage runs against the wrong set of devices.
Failure handling is the stage manual work does automatically without thinking — a script has to be told explicitly what to do when a device doesn't respond.
A silently-skipped device is worse than a script that stops with an error — an honest report has to say what it couldn't check.
Running a command successfully and getting the correct result are different things — validation is the step that checks the result itself.

What you'll learn