Chapter 26 — Automation and scheduling
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 What to automate"]
N2["26.2 Scheduling"]
N3["26.3 Monitoring the automation"]
N4["26.4 Keeping humans involved"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 What to automate"]
N2["26.2 Scheduling"]
N3["26.3 Monitoring the automation"]
N4["26.4 Keeping humans involved"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 What to automate]
|
v
[26.2 Scheduling]
|
v
[26.3 Monitoring the automation]
|
v
[26.4 Keeping humans involved]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) automate routine security checks; (2) schedule and monitor scripts; (3) handle failures of automation.
26.1 What to automate
Jamal has written several scripts: the inactive account check, workstation baseline check, failed login analysis and restore verification. Running them by hand takes time and is easily forgotten. He selects those that run on a fixed schedule with predictable inputs and automates them. Ms. Grant advises automating stable tasks first and keeping a person involved for decisions, such as disabling accounts. He lists each candidate script with how often it runs, what input it needs and whether its output requires a decision, and chooses four for automation in the first month.
26.2 Scheduling
Jamal schedules the scripts on a server using the operating system's task scheduler. Each runs under a dedicated service account with only the access it needs. Results go to a shared folder and a summary email to the IT manager. He documents each schedule with its purpose, owner and timing. He learns that scheduled tasks also need inventory and ownership, just like systems. He tests each scheduled task for a week, checking that outputs arrive and that the service accounts cannot access anything beyond what each script needs.
26.3 Monitoring the automation
Automated checks can fail silently. Jamal adds a simple heartbeat: each script writes a line to a log when it finishes, and a separate check alerts if any script has not run on time. In the first month, the alert catches the baseline check failing after a password change on its service account. He fixes it the same day. Ms. Grant notes that unmonitored automation can give false confidence for months. He adds the heartbeat check itself to the scheduling documentation with its owner.
26.4 Keeping humans involved
Jamal designs the inactive account script to list accounts for review rather than disabling them automatically. The IT manager reviews the list weekly and disables accounts after checking with managers. One account belongs to a member of staff on long-term sick leave, who should not be disabled. Jamal learns that automation should support judgement where context matters, rather than replacing it. He adds a note field to the review list so the IT manager can record why any flagged account was kept, which helps later reviews avoid asking the same questions again.
Worked example
Jamal automates four stable checks under dedicated service accounts, adds a heartbeat that catches a failing job and keeps human review for disabling accounts.
Synthetic case. Schedules are synthetic.
Errors and limits
Automation that fails silently gives false confidence.
Exercises
- EX076 — Automation choice. Which tasks are automated first? Rubric: 3 = stable tasks with predictable inputs;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX077 — Heartbeat catch. What did the heartbeat catch? Rubric: 3 = baseline check failing after a password change;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX078 — Sick leave. Why should one inactive account stay enabled? Rubric: 3 = staff on long-term sick leave;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 26 (chapter 26 of 30)
← Chapter 25 · Course chapter index · Chapter 27 →
Continue to the next authored lesson.