0.1 Creating effective support tickets

Introduction

While every application will have different specific needs, there are myriad overlaps between systems, and knowing how to interact effectively with the product's support team is crucial to the successful use of any environment.

Identifying the problem

The first mandate of successfully navigating the support process is to properly identify the issue at hand. A solid knowledge of basic troubleshooting skills is helpful, but - especially the larger the tool - not only is domain expertise needed, individual components of a system may react in unexpected ways. For example, an error may manifest itself in a log file as a component getting an "OutOfMemory" message, when the real issue is that your JVM can't expand its memory usage from the system heap due to insufficient swap space (a specific example that haunted me for over a week on one project).

Be sure to familiarize yourself with the system's log file locations: in all probability not only will they provide initial clues to the issue, but the support engineer will ask for them to be added to the case you create during the process. On a Linux/Unix system, this is typically in /var/log/appname .

Helpful case titles and descriptions

The most useful aspect of any support case is a helpful, descriptive title, and a clear explanation of the issues witnessed. The least useful title I can recall having seen was "problem". Not what the problem was, but just "problem". Try instead for something like "Cannot start tomcat6 on Ubuntu 10.10 x64" - this describes the basics of what you are trying to do, and where you are trying to do it!

Adding an initial description to our case title above might look like the following:

After successfully running sudo apt-get install tomcat6 on my Ubuntu 10.10 x64 server, Tomcat will not start.

The following message is showing in /var/log/tomcat/stderr.out : ...

Debugging steps taken: ...

Because you've shown at least some inclination towards being helpful, the support technician(s) are likely going to be more inclined to want to work with you to a resolution. In this specific example, you've identified some errors showing up in a specific log file - go ahead and add that log (or perhaps the whole log directory, if appropriate) to the case so that the engineer(s) you interact with can have a head start on their more advanced troubleshooting steps.