ORIGINAL COMPANY-CONTEXT PRACTICE
Correlate a synthetic telecom incident storm
Original practice scenario: A network simulator generates thousands of alarms after one upstream link fails. Design incident grouping without suppressing unrelated failures.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Group alarms using topology and time evidence while retaining raw events. Correlation should create a reviewable hypothesis, not assert that every nearby alarm has the same cause.
Work through it
- Version the dependency graph and capture alarm identities, onset times, recovery signals and confidence in their device mappings.
- Form candidate incidents using affected paths and bounded time windows, preserving independent symptoms and allowing groups to split when evidence conflicts.
- Test simultaneous unrelated failures, stale topology, delayed alarms and recovery flapping; measure missed incidents and unnecessary duplicate notifications separately.
Tradeoffs to discuss
- Aggressive grouping reduces noise but can hide distinct failures; conservative grouping increases workload while preserving more uncertainty.
Common pitfalls
- Do not discard raw alarms after attaching them to an incident.
- Temporal proximity alone is insufficient evidence of a shared root cause.