A factory technician confirmed a theory on a lab switch: a bad uplink setting is the cause. Production has not been changed. Which methodology step comes next?
Select an answer to reveal the explanation.
Short Explanation
You confirmed the cause on a lab switch, and production is still untouched. Your next step is to make a plan for the change and its possible effects on users before you update the production core. Applying it immediately, closing the ticket, or discarding a theory you already confirmed would skip the right step.
Full Explanation
The troubleshooting sequence moves from a confirmed theory to a plan of action before implementation. Your plan identifies the production change and its possible effects on users, so you can assess the impact before copying a lab result onto a live uplink. Applying the lab change to the production core immediately skips planning and the rollback plan, risking an unannounced outage. Closing the ticket because of the lab result is premature: documentation of findings, actions, and outcomes follows implementation and verification, and production has not been fixed. Discarding the confirmed theory throws away evidence and returns to an earlier step without a reason. The appropriate next step is to establish the plan and note how the production change could affect users. Exam caveat: if the plan shows that the change is outside your authority or could be disruptive, it should include escalation rather than a silent edit. Practical check: write down the exact production change, its rollback, and who could be affected; obtain any approval required by your change process, then implement it. Include a rollback so you can restore the previous uplink setting if production does not behave as the lab did.