Municipal platform engineers want shorter outages after bad deploys of the clerk portal. Which practice most directly reduces MTTR?
Select an answer to reveal the explanation.
Short Explanation
Automated rollback runbooks are the fast reverse gear after a bad clerk-portal deploy—that is how you shrink MTTR. Longer meetings and quieter alerts stretch the outage.
Full Explanation
MTTR shrinks when restoration is automated, rehearsed, and fast after bad deploys. Municipal platform engineers wanting shorter outages after bad clerk-portal releases should rely on automated rollback runbooks that restore the last known-good release quickly—the reverse gear that turns a bad deploy into a brief blip instead of a prolonged citizen-facing incident at the clerk desk.
Lengthening the change-advisory board meeting before every hotfix adds process latency to recovery and increases MTTR when clerks are already blocked. Turning off alerts so fewer people notice the outage hides pain without restoring service and typically lengthens citizen impact. Requiring handwritten change forms before any automated action inserts manual friction into the restore path exactly when speed matters most for municipal operations.
Exam caveat: automated rollback needs clear health signals and immutable prior artifacts; rolling back blindly can mask data-migration issues—pair rollback with smoke verification after restore. Operational check: on a bad clerk-portal deploy, execute the rollback runbook, confirm last known-good is live, re-run critical smoke, and measure detect-to-restore time against MTTR goals.