Five buffering incidents and a deferred firmware upgrade
A SaaS e-learning platform has suffered five 'video playback buffering' incidents in six weeks, each affecting 8-15% of learners for 35-50 minutes. Every time, the on-call team restarts cache nodes and playback recovers; the incident is closed within the 99.9% SLA. The service desk has a workaround article, but no problem record exists because the incident manager closes each ticket at restoration. The cache vendor has identified a firmware defect and proposes an upgrade. Change enablement deferred the upgrade twice because it touches a peak exam period and the risk assessment shows possible 20-minute downtime. The product owner says 'restarting is cheaper than a change'. The problem manager has only one full-time analyst and a backlog of 30 problems. Learner complaints are rising, and the support director wants incident management to 'stop reopening old incidents and focus on new ones'.
1. Should the latest buffering incident be closed as usual? Explain your decision and the records and linkages you would create, including problem and known error.
Read the worked answer
Yes, the incident can be closed once playback is restored and validated, because incident management's purpose is to restore service quickly. Closure is not the same as resolution of the underlying cause. Closing the incident is correct; leaving the systemic issue unmanaged is not.
The repeated pattern - five incidents, same symptom, same workaround - should trigger problem management. I would create a single problem record linked to all five incidents, with the shared symptom, cache-node evidence, vendor firmware finding, and the restart workaround. If the vendor defect is confirmed, the problem becomes a known error, and the workaround article should be linked to it. The problem record gets an owner and a priority based on impact, frequency, and risk, even if the problem manager has limited capacity.
The support director's instruction can be satisfied without hiding the issue: do not reopen closed incidents, and do not create duplicate incident records. Manage the recurrence through the problem record. Incident metrics will still show five incidents, but the problem record explains why. The service desk should use the workaround consistently and capture the time and scope of each recurrence so the business case for change is evidence-based.
2. The firmware upgrade is deferred and the product owner prefers restarts. Evaluate this trade-off and recommend what incident, problem, and change management should do next.
Read the worked answer
The product owner is comparing the cost of a planned 20-minute change with the cost of an unplanned restart, but that understates the recurring cost. Five incidents at 35-50 minutes each, affecting 8-15% of learners, create support load, SLA credits, lost learner confidence, and repeated engineering effort. The restart is a workaround, not a fix. It also carries risk: a restart may not always recover playback, and repeated cache restarts can mask a worsening defect.
Change management should not simply defer again. It should assess the upgrade with a proper risk and benefit case: schedule it outside the peak exam period, pilot it on a non-critical cache cluster, define rollback, and agree a communications plan. If the next exam peak is close, an emergency change may be justified if the risk of another outage outweighs the change risk. The decision should be recorded with the change authority, not decided informally by the product owner.
Problem management should quantify recurrence and own the known error, keeping the workaround available until the fix is proven. Incident management should keep the major incident trigger ready if buffering spreads beyond the usual 15%. After the change, review whether incident frequency and duration actually fall. The test is not whether a change was avoided, but whether total service risk and learner impact went down.