Parks backup jobs should alert operators and kick a retry runbook when a job fails. Which event-driven pattern supports that response?
Select an answer to reveal the explanation.
Short Explanation
You want a backup failure to reach the people who can act and start a retry, not sit unnoticed. Notification-driven automation turns that failure into a timely response instead of relying on silence, citizen reports, or an annual paper log.
Full Explanation
Parks backup failures should trigger notification-driven automation: the failure event pages a ChatOps channel and can start a retry workflow or runbook. This closes the loop from detection to operator awareness and automated or semi-automated remediation, protecting reservation systems and other parks data. The retry runbook can be kicked off through the same event path, so the failure prompts action rather than merely producing a record. Suppressing failure notifications and deferring investigation until the annual audit allows data-protection gaps to accumulate undetected and can turn a needed restore into crisis archaeology. Waiting for citizens to report missing reservation data is also a poor monitoring strategy: people discover the loss after it has affected them, too late for timely backup operations. Printing failure logs once a year for the city council binder does not provide timely operational response; annual paper is not a substitute for alerting operators when a job fails. Exam caveat: notification-driven automation still needs alert hygiene, including deduplication, severity, and on-call routing, so ChatOps remains actionable rather than noisy. Retries should be bounded and idempotent to avoid repeatedly stressing a broken target. Practical check: force a controlled failure in a lab backup job, confirm ChatOps receives the event, execute or automatically start the retry runbook, verify that its success or failure is recorded, and ensure production alert routes are not normally muted.