<< Chapter < Page Chapter >> Page >
Creating and updating support cases in an effective manner is essential to timely problem resolution

Introduction

I spent quite a while working in an enterprise Tier 2/3 support role, and have had extensive experience interfacing with software systems support engineers both prior to and after that role in support. This guide is intended to provide an introduction to the most effective techniques for creating, managing, and closing a support case from both the supportee and supporter views. As a supportee opening a case, what are the salient things the individual who will respond to your case going to be looking for? And as a supporter trying to solve a problem, what would be the best thing(s) for your customer/reporter to provide to you?

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.

If your vendor has a specific policy regarding ticket reporting and case creation, by all means follow their guidelines - if they vary from this guide, make sure you do what they ask, when they ask!

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: ...
This shows the support engineer what you are seeing, and what you have already done - both of which you will be asked for!

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.

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Debugging and supporting software systems. OpenStax CNX. Aug 29, 2011 Download for free at http://cnx.org/content/col11350/1.2
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Debugging and supporting software systems' conversation and receive update notifications?

Ask