OpenCyber AcademyLesson map
Lesson 39 published. Map, example, EX115.
flowchart TD
N0["Learning outcomes"]
N1["39.1 Documentation"]
N2["39.2 Simplicity"]
N3["39.3 Staff changes"]
N4["39.4 Vendor changes"]
N5["39.5 Review cycle"]
N6["Maintaining baselines"]
N7["Technical debt"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX115"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["39.1 Documentation"]
N2["39.2 Simplicity"]
N3["39.3 Staff changes"]
N4["39.4 Vendor changes"]
N5["39.5 Review cycle"]
N6["Maintaining baselines"]
N7["Technical debt"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX115"]
[Learning outcomes]
|
v
[39.1 Documentation]
|
v
[39.2 Simplicity]
|
v
[39.3 Staff changes]
|
v
[39.4 Vendor changes]
|
v
[39.5 Review cycle]
|
v
[Maintaining baselines]
|
v
[Technical debt]
|
v
[Worked example] --> [Exercise EX115]
Learning outcomes
You will (1) design for long-term maintenance; (2) document; (3) plan for staff changes.
39.1 Documentation
The repository holds image definitions, scripts, runbooks and decision records.
Keeping everything in one repository means a new technician has one place to look. The image definitions show what the PCs contain, the scripts show how they are built and restored, the runbooks show how to operate them, and the decision records explain why. Each document carries the date of its last review, so stale ones can be spotted quickly. Marta checks the dates each quarter and asks owners to review anything more than a year old.
39.2 Simplicity
One image for all public PCs and few custom scripts keep maintenance manageable.
Every custom script is something a future technician must understand and maintain. Mateo kept his to three: build the image, check measurements and produce the morning report. Everything else uses standard tools from the operating system or the management product. One image for all three hundred PCs means one set of tests and one release process, rather than variations to keep in step. Any proposal for a new script must explain why a standard tool cannot do the job.
39.3 Staff changes
Two people can perform every task; documentation is tested by a new technician.
Mateo and the technician cross-trained during the pilot, so each could do the other's tasks. A technician from another library network, who had never seen the system, then followed the documents alone for a week; the worked example describes what she found. Testing documentation with a newcomer is the only reliable way to find steps that make sense only to the person who wrote them. Her notes were added to the repository with the fixes.
39.4 Vendor changes
Hardware refreshes require testing firmware and Secure Boot settings on new models.
New models may have different firmware menus, different TPM behaviour or different restore times. Before a new model enters service, it goes through the full set of requirement and integration tests on a lab unit, and its settings are added to the firmware configuration. Mateo's notes list what had to change for each existing model, which gives a starting point for the next one. Models that cannot meet a requirement are not bought for public use.
39.5 Review cycle
The design is reviewed annually against updated benchmarks.
The annual review compares the image with the current benchmarks, checks whether requirements are still needed, reviews firmware support dates and updates the documentation. It also looks at the year's incidents and asks whether any reveal a weakness in the design itself. The review is recorded as a decision record, so later reviews can see what was considered and what changed. Marta and the technician attend; Dr Novak joined the first review as an outside reader and suggested two checks that were added.
Maintaining baselines
Benchmarks and vendor baselines change. Each year Mateo's successor compares the image settings with the latest CIS Benchmark and Microsoft baseline, records differences and decides which to adopt. NIST SP 800-128 calls this maintaining the baseline configuration through change control. Without it, a once-strong image slowly falls behind.
The annual review also checks whether any requirement is obsolete.
Technical debt
Quick fixes, such as a temporary script, are logged as debt with a plan to replace them.
Training
New staff complete a short training using the runbooks and a lab PC.
Licences
Software licences are tracked so updates are not blocked by expired licences.
Retirement
Old PCs are wiped and disposed of securely.
Successor planning
A named successor is trained.
Dependencies
Maintenance depends on vendor support for PC models; end-of-support dates are tracked.
Budget
Annual maintenance time is estimated and included in Fernhill's plan.
Simplicity check
Each new feature must justify its maintenance cost.
Annual checklist
An annual checklist covers baseline comparison, requirement review, firmware support dates, licence renewals and documentation review. It takes about a day and keeps the design current.
Worked example
A new technician follows the runbooks for a week without help, finding one unclear step, which is fixed.
Synthetic case. Synthetic.
Errors and limits
Systems maintained by one expert become fragile when they leave.
Exercises
- EX115 — Repository. What does the repository hold?
Show marking criteria
Rubric: 3 = image definitions, scripts, runbooks, decisions; 2 = three; 1 = two; 0 = none. - EX116 — Staff resilience. How is staff change handled?
Show marking criteria
Rubric: 3 = two people per task, tested docs; 2 = partial; 1 = vague; 0 = none. - EX117 — Review. How often is the design reviewed?
Show marking criteria
Rubric: 3 = annually; 2 = partial; 1 = vague; 0 = none.
Synthesis
Simplicity and documentation sustain the system.
Continue studying — chapter 39 of 50
← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →