| This is the simplest but most overlooked step in the problem-solving process. This is largely due to the perceived obviousness of what the problem is. People assume that the problem they are experiencing and reporting is the actual problem. More often than not, there are key details missing from the problem narrative. For instance, a user might report that he cannot log into a server the firewall is protecting, when in reality the user is trying to log into another server. The user is confident that he is logging into the server your firewall is protecting, but someone made a typo in the DNS server, and the IP address now points to a different system where the user does not have an account. What is the problem exactly? Before even touching your firewall, consider that the problem may not be related to the firewall at all. As a central component in most organizations' network architectures, the firewall tends to be blamed for everything and typically only when someone cannot get "out" to the Internet. It's useful to determine if the problem lies elsewherebefore starting in on such a complex task as troubleshooting your firewall. Can you duplicate the problem and cause it to occur when you want to? This is essential when troubleshooting. The problem may no longer exist, and if you cannot duplicate the problem, you will have tremendous trouble testing your solution. Ask the most important question of them all: What changed? We recommend you print these two words out and put them up over your desk, because in our experience these two words have solved more problems than everything else combined. In short, if the system was working correctly at some point, what has changed between now and then? Never assume that changes have not occurred, or that the changes that did occur would not have caused the problem you are trying to solve. Sometimes the problem is simpler than we imagine. What happens if you revert the system back to its original state? Did that solve the problem? This is a critical step that helps to quickly eliminate the root cause of a problem. If rolling the system back to its original state does not solve the problem, you can rule out that change completely. What is the scope of the problem? Isolate the problem. Where is it? Does it affect one system, many systems, one protocol, or all of them? Which ports are involved, and what time of day does the problem occur? Which OSs is it affecting in your organization? If the problem is big, break it into smaller problems and tasks that are easy to manage.
Prioritize the problem(s). Is this something you have to fix right now?
|
