Generic How To Handle Issues Page

I'd like to take a moment and throw in a few pieces of advice when a customer submits a ticket regarding "servers down". It may seem like a daunting task to figure out why their server is down, or what to do about it, but most of the tickets that we get are often solved by a simple reboot (providing the customer permits) of their server.

Included in the message below is a ticket that a customer recently submitted, in which they asked us simply to reboot the VPS in question, since they could not SSH to it. Based on the customer's request, here's what should have been done:

Step 1 - Determine the server location

SHARED HOSTING ONLY - cpanel01001/cpanel01002 is in San Jose, cpanel01003 (deprecated) is in Chicago, cpanel44001 is in London. We do not offer shared hosting in our Germany location.

ALL VPS NODES - node00001/node00002/node00004 are in Maidenhead, node01001 is in San Jose, node01002 is in Chicago, node49001 is in Germany.

If you access the customer's Client Profile -> Summary tab, you will be able to easily tell, based on this list above, where the VPS is situated. If the Server field says "HyperVM domU" This is an OpenVZ VPS and you cannot shut it down directly through 'root' on the node itself. You must determine the server ID of the OpenVZ VPS (login as root to the OpenVZ container to do this) and then take action that way. If the VPS is on the physical node and not inside of a separate container, you can manage the VPSes often times through DTC's admin panel.

Step 2 - Assess the situation

Not every situation is going to be the same, so a quick solution isn't necessarily going to be the best thing to employ. When a customer submits a ticket saying that something is wrong, we need to be able to determine what the problem is, and what's causing the problem. For example, if a customer says that their server is down, this could mean any number of things. More often than not, their service with us is Shared Hosting and they've more than likely banned themselves from the server by attempting to log into their cPanel/WHM account too many times. In which case, simply logging into WHM as the root user and removing them from the blacklist will fix the issue. But for more advanced issues like VPS suddenly not making outbound connections, or services unreachable (case and point: see below), there's a simple way and then a long way to fix things. We should be able to, based on even just a brief description of the customer's problem, determine the basic cause of an incident without going into much detail.

Step 3 - Rectify the problem

This is the easy part. In one case, a simple reboot could have fixed her problem. Instead, the agent that handled this ticket decided to take the long way around this and tried to look for the VPS by SSHing as root to the physical node. This will not work, because the VPS is an OpenVZ VPS (see Step 1). More advanced problems may require that you SSH in to the customer's server and run diagnostic commands to determine the problem, and it may be a tad bit more difficult than a simple reboot. Remember that we should never assume that the problem is fixed until the customer says it's fixed. We could fix one issue only to find out that the customer actually had another issue, and it was unrelated to the problem that they fixed. This is only an example, but it proves that assuming isn't always the best thing to do.

Please understand that failing to follow these three easy pieces of advice can and most likely will result in a negative customer experience. As always, remember to personalize your ticket responses whenever it's possible. A happy customer is a returning customer, and a returning customer is a loyal customer whom will most likely recommend GigaTux to their friends and family!