Every Monday at 2 a.m. a campus uplink reaches about 90 percent utilization, matching the backup window already recorded in last month's baseline. How should operations treat that spike?
Select an answer to reveal the explanation.
Short Explanation
Your baseline already includes this Monday 2 a.m. rise, matching the recorded backup window, so you treat the 90 percent utilization as expected and do not page. A fiber cut or disabling the backup invents a problem the baseline has already explained.
Full Explanation
A performance baseline records ordinary utilization, including known jobs. Last month’s baseline already shows this uplink climbing during the Monday backup, and the live spike matches that pattern at about 90 percent at 2 a.m. Treat the spike as expected backup traffic and do not page. Paging because 90 percent is always an incident ignores the key evidence: this rise matches the recorded window. Paging on a known backup can teach the team to ignore alarms. Declaring a fiber cut is not supported by a repeating rise that mirrors scheduled backup traffic; a cut typically causes link loss or errors rather than this matching pattern. Disabling the Monday backup would flatten the graph only by canceling the protection the backup provides. Exam caveat: expected does not mean unlimited. If utilization later saturates and the backups fail, a departure from the baseline deserves investigation. This matching spike does not. Operational check: overlay this Monday’s utilization on the baseline, confirm the start and end track the backup, and keep the alarm above that known pattern or suppress it only within that window. A spike on Tuesday is a different event and should still page.