Server Change Management Lab

A browser-based training lab where you act as the change manager for a fictional insurer. Over three server changes you classify the change, assess risk, choose approvers, plan testing, rollback, the window, communications and verification, and then see a seeded outcome of what happened. It trains judgement about process weight, not command syntax.

Because it is repeatable, has a written procedure, is proven on earlier rings, and has a clean history. In ITIL change enablement terms that is what a pre-authorised standard change is. The light touch is earned by the evidence from ring 0 and ring 1, so skipping them removes the reason it is standard.

An emergency change is needed urgently to stop active or imminent harm, such as a vendor-confirmed exploited flaw on an internet-facing system. It follows a faster approval path with named emergency approvers and a review afterwards. It does not mean skipping testing or a rollback, and an impatient requester does not make a change an emergency.

By staging it: patch the staging mirror and run smoke tests, then patch one production node out of rotation and watch it before the rest. That costs tens of minutes, and it limits the damage if the patch is bad. Patching every node at once is the classic emergency mistake.

Because a patch closes the door but does not tell you whether someone already came in. After the fix, search logs for exploitation before the patch and run the exploit check from outside. If there are signs, the incident process takes over.

Clients that cannot speak the newer protocols fail, and some of them belong to partners you do not control. Rare clients, such as a weekly file transfer, may not show in a short log window. Mining a longer window, testing with partners and staging the rollout are the safeguards.

Each change hides a few risks, such as a hang on reboot, a start-order problem or a rare client. The seed fixes the dice. Choosing tests, rollback, windows and approvers that address a risk makes it much less likely to fire, and a good rollback or verification limits the damage if it does. The same seed, level and plan always give the same outcome.

Rookie shows a hint at each step and a "watch for" list of hidden dependencies, and has the lowest chance that an unmitigated risk fires. Pro hides the hints, but a good test plan reveals a hidden dependency as you choose it. Elite hides everything until the outcome and raises the chance that an unmitigated risk fires.

A Markdown change record per change, with type, risk, approvers, window, test, rollback, communications, verification, the simulated outcome and the process findings, and a CSV register of all three. Downloading and copying documents is Pro. You can read the same records on the debrief page.

No. Pellworth Insurance, its people, servers and the pellworth.example domain are invented, and every outcome is simulated in your browser. Nothing here connects to a real server.