LEARN. PRACTICE. GROW.Concept and mechanism
During a failure, impact may need to be reduced before the complete cause is understood. The decision should consider expected effect, risk, reversibility, dependencies, and applicable authority. Ask specialists to explain what an option should improve and which signals would verify the result. Correlation with the latest change is a clue rather than complete causal proof. Rollback may be appropriate but can be incompatible with data or configuration changes; confirm those conditions. Record hypotheses and results to avoid repeating attempts without learning. Do not turn time pressure into blanket permission for any intervention.
Guided application
In a fictional scenario, a message queue grows after a release and two options emerge: roll back the application or temporarily limit incoming work. Coordinate compatibility and consequence analysis, including already processed data and pending work. The selected option needs an owner, observation, and a reconsideration condition. If signs of compromise appear, involve security response through the local process. Preserve relevant records, their provenance, and authorized access; do not distribute sensitive logs in an open room. NIST SP 800-61 Rev. 3 provides a current cybersecurity-response reference but does not replace the organizational plan or itself define legal notification duties.
A successful mitigation can reduce impact without proving the definitive cause.
Common pitfalls
Rollback assumed always safe; multiple unrecorded changes; exposed sensitive logs; cause assumed from timing.
Related topics: Declaration, impact, and priority · Command, delegation, and shared state · Communication and uncertainty
Choose an evidenced action, observe its effect, and update the decision.
Reference: Effective Troubleshooting · Google SRE incident guidance; PagerDuty contextual incident model; NIST SP 800-61 Rev. 3 April 2025; editorial review 2026-10-01