Further reading<\/span> Network Audit Guide<\/a><\/p>\n Once you\u2019ve determined the nature and scope of the problem, you can assign it a priority level. The priority level should reflect how many users the problem impacts and how critically it disrupts their work.<\/p>\n If it\u2019s a major incident, begin responding as soon as you can. Otherwise, establish a timeline for when you will resolve the problem.<\/p>\n During this process, think as well about the origins of the incident and what it will take to fix it. Will you need to travel to a remote site? Do you need to order new equipment? Will you need multiple staff members to resolve the problem? Factors like these will influence how quickly you can plan to resolve the incident, regardless of its priority level.<\/p>\n In cases where you are dealing with a critical problem but can\u2019t solve it right away, you may consider introducing a stopgap measure in the meantime. For example, if you need to rebuild a local server but don\u2019t have new server hardware on hand, you could spin up a replacement server in the cloud using a virtual machine temporarily, then take an image of that server and transfer it to the new local server hardware when it arrives.<\/p>\n Before you begin working to resolve a networking incident, you should have a plan in place for how you will handle it. The plan should reflect what you believe to be the root cause (or causes) of the problem, and it should specify the resources and procedures that you will need in order to resolve it.<\/p>\n For serious or complex incidents, it\u2019s wise to test your response plan before implementing it. For example, imagine a situation where your response plan is to replace a network router that is actively handling connections, but is starting to fail. In order to ensure that you can decommission the router and replace it with a new one with as little disruption to users as possible, you could perform a test run by setting up a spare router first. That way, you\u2019ll familiarize yourself with the steps you\u2019ll need to go through when performing the actual incident response. This will minimize the risk that something unexpected will happen and bring the live network down for an extended period.<\/p>\n When you\u2019re in the midst of responding to a networking issue, writing documentation may not be at the forefront of your mind. But it should be, because it\u2019s critical to document every stage of the network troubleshooting process.<\/p>\n Write down the steps you perform in order to assess and diagnose problems, as well as the response plan you intend to follow. Then, note the outcome of the plan after you execute it. Having this documentation on hand will help you respond more quickly in the event that the problem occurs again. It is also useful when you are troubleshooting other network issues and want to determine what has and hasn\u2019t worked in the past.<\/p>\nClassify the Incident<\/h2>\n
Develop a Response Plan<\/h2>\n
![\"CTA\"](\"https:\/\/no-cache.hubspot.com\/cta\/default\/5442029\/aa07fdb8-7776-46a5-9fa0-ec6e93f0f0a6.png\")
<\/a><\/span><\/span><\/div>\nDocument the Troubleshooting Process<\/h2>\n