Investigate with evidence, document failed assumptions, and verify service restoration. The framework is a guide; the appropriate sequence depends on the incident and change controls.
1. FrameEnvironment · Problem · Symptoms
2. InvestigateAssumptions · Investigation · Evidence · Dead ends
3. ResolveRoot cause · Remediation · Verification
4. ImproveEngineering lesson · Preventive controls
The 12 steps
- Operating environment. Record the products, relevant versions, traffic path and constraints.
- Original problem. State the impact and the expected behavior.
- Observed symptoms. Separate observations from interpretation.
- Initial assumptions. List hypotheses and what would disprove them.
- Investigation process. Trace the failing path and test one hypothesis at a time.
- Commands, logs and evidence. Capture relevant, sanitized output and explain what it proves.
- What did not work. Document unsuccessful checks and why they were ruled out.
- Actual root cause. Connect the evidence to a specific failure mechanism.
- Remediation. Describe the scoped change, its risks and a rollback approach.
- Verification. Check end-to-end service behavior, logs and user-visible recovery.
- Engineering lesson. Explain the assumption or design issue behind the incident.
- Preventive controls. Identify monitoring, testing or design changes that reduce recurrence.
See it applied
In the F5/FortiGate case, a reachable VIP and healthy pool did not establish that the server-side application flow was permitted. Comparing both traffic legs exposed a missing firewall policy; connection tests and captures verified recovery.
Read the full investigation · Browse cases
Use article commands only after checking their relevance to your product version and environment. Production changes require your organization’s approval and rollback process.