Always Consider Corporate Policies, Procedures, and Impacts Before Implementing Changes

Considering corporate policies, procedures, and impacts before implementing changes might seem like common sense. In the heat of the moment when you’re troubleshooting a problem, however, and other people are pressuring you for an answer, this commonsense advice is often ignored. Unfortunately, not following this advice can lead to other problems, including the loss of your job.

You may be wondering what sort of scenario would result in not considering corporate policies, procedures, and impacts? For example, consider a scenario in which a user is attempting to access an S3 bucket in your company’s AWS environment.

By looking at the permissions of the bucket, you can see that the user should have the ability to read the contents of this bucket. The user claims that he can’t view the contents and asks you to change the permissions to include the write permission. He says he needs access immediately and feels granting write access will also allow him to read (view) the contents of the S3 bucket.

Your company has a policy that to gain write permissions on an S3 bucket, a user must fill out a request form. You mention this policy to the user, who you now realize is a senior manager, and he says, “We don’t have time for that. Just give me write access now.”

As you can see, you are now in a difficult position. You want to help the user, but taking the action that he is requesting will break company policy. The policy is in place for a reason: to prevent unauthorized access to corporate data that is stored in S3 buckets. Although you may be tempted to give in to the user’s demands, it is best to follow the corporate policy to the letter. You might be able to expedite the user’s request, but following the policy is important to ensure additional problems are avoided.

While some may consider troubleshooting to be a mysterious art form, it is really based on very specific steps that you should follow. Here’s a summary of these steps:

1. Identify the problem.

2. Establish a theory.

3. Test the theory.

4. Establish a plan of action.

5. Verify full system functionality.

6. Document the findings.

For the rest of this chapter, you will explore what actions to take in each of these steps.

1. Identify the Problem

The first step to the troubleshooting methodology is to identify the problem. In this step you want to gather information to determine the cause of the problem. This step includes actions like the following:

• Question the user, identify user changes to the computer, and perform backups before making changes.

• Inquire regarding environmental or infrastructure changes.

Throughout the rest of this chapter, we will use a scenario to help you further understand what actions are performed in each step of the troubleshooting process. To avoid specifics about any particular cloud vendor, the steps will be somewhat generic.

Scenario: You have been contacted by a user who maintains a web server in your corporate cloud environment. This user indicates that the web server is no longer responding. You will be using your troubleshooting skills to solve this problem.

Step 1: Identify the problem. You start by asking the user a series of questions (the answers to these questions are in italics after the question):

• When was the last time you were able to access this web server? Last Tuesday morning.

• Where did you try to access the web server (home, in the corporate network, some other location)? In the corporate network.

• Are there other applications on the server? If so, are they still accessible? No other applications that I am aware of.

• Did you try to access the web server using its name or its IP address? I used the web server name.

• Have changes been made recently to the web server? Not that I know of.

• Have changes been made recently to the operating system where the web server is installed? Not that I know of.

2. Establish a Theory of Probable Cause (Question the Obvious)

In this step you need to conduct external or internal research based on symptoms and then establish a theory of the probable cause of the problem. Depending on the problem, this step may require you to take any of the following actions:

• Review documentation for the software/system.

• Test multiple techniques to work around the problem.

• View log files.

• View internal change orders (changes made to the system).

• If there is a similar system or software available (and working), attempt to compare the two (configuration files, settings, log entries, etc.)

Scenario, Step 2: Establish a theory of probable cause. You have researched the problem and have discovered that you can access the web server via a ping using its IP address, but not by the web server’s name. The ping command uses an ICMP network packet to determine if a device is reachable via the network. Your theory is that a change to the internal DNS server has resulted in the IP address-to-name lookup process to fail.

3. Test the Theory to Determine Cause

You may be tempted to immediately fix the problem after you have established a theory; however, there is another step to take before you try to fix the problem. You should test your theory before trying to fix anything. This step includes the following:

• After the theory is confirmed, determine the next steps to resolve the problem.

• If the theory is not confirmed, reestablish a new theory or escalate the problem to a higher level of support.

Scenario, Step 3: Test the theory to determine cause. To test the theory that the DNS server is to blame, you attempt to access the web server using a web browser and the IP address of a web server, and you get a response. You verify that the response is correct with the user who notified you of the problem. You also contact the team that is responsible for the DNS service in your organization and ask if any recent changes have been made to the DNS service. The response: The DNS server was updated Wednesday morning.

4. Establish a Plan of Action to Resolve the Problem and Implement the Solution

When you feel confident that you have determined the cause of the issue, it is time to establish a plan of action to resolve the problem. The reason this plan of action is important is that the steps you take might not really solve the issue, and as a result, you may need to “back out” of the steps that you took. If you just take the steps without planning them first, undoing any actions that you take will be very difficult.

Additionally, this plan of action will make it easier to document this issue. One of the steps of documenting a troubleshooting process is to describe the actions that you took to solve the problem.

Scenario, Step 4: Establish a plan of action. Working with the DNS team, you develop a plan in which a new DNS entry will be added for the web server. After this change takes place, you will test the functionality by first trying to connect to the web server using its name and the ping command. If this is successful, you will then attempt to access the web server using its name via a web browser.

5. Verify Full System Functionality and, if Applicable, Implement Preventive Measures

A solution may produce additional problems. For example, if a solution to accessing a web server is to open a hole in the company firewall, this solution may result in additional, unintended access. To the best of your ability, you should test to verify that your solution does not cause additional problems.

Scenario, Step 5: Verify full system functionality. You have notified the user that the problem seems to be fixed and asked the user to verify. While discussing this solution with the user, you ask the user to share his screen and walk through using the website to ensure it is fully functional. Because there are no other applications hosted on this system, this step completes your verification of a fully functional system.

6. Document the Findings, Actions, and Outcomes Throughout the Process

If you have worked with computers for a while, you most likely have had the following happen to you: You run into a problem, take the time to research and troubleshoot the problem, and fix the problem only to have it crop up again sometime later. If you are like most people, you will vaguely remember the problem and maybe parts of the solution, but in many cases, you will have to troubleshoot the problem from scratch.

Our brains are just not good at documenting solutions to problems that we have seen only once. This is one of the reasons that you should document all issues, including your findings, any actions you took, and the outcome to those actions. If you document as you go, this is really an easy process. If you wait until the end of these steps, you are likely to forget parts of the troubleshooting steps you took.

Scenario, Step 6: Document the findings. You have been gathering documentation during the troubleshooting process. Your company has a tool that takes this information and stores it in a database so others can access the information. You use the tool to upload your findings, and your job is now complete.

What Next?

If you want more practice on this chapter’s exam objectives before you move on, remember that you can access all of the CramQuiz questions on the companion website. You can also create a custom exam by objectives with the practice exam software. Note any objectives you struggle with and go to that objective’s material in this chapter.