12.3. Filing a ticket

Be sure to get the TCC user name of the person reporting the problem (from that you can get their full name with acctmngr -s <username>). Also get their phone number. It is especially important to get a phone number on email and login problems as that is usually our only means of contact. You may need to press for that info sometimes (like if a person is in a hurry to leave) but it's really needed when filing tickets. Of course you'll also need other details pertinent to the problem.

When answering the phone get in the habit of pulling up the ticket system so that you can open a ticket as soon as you know the phone call is to report a problem (or seek a solution to one).

When filing tickets please take the time to include any error messages. Verbatim if possible, but at least include key words. Exact wording is important as there are sometimes similar sounding messages that indicate quite different causes. Also provide the steps that brought you to the problem since sometimes just changing the way a thing is done can fix the problem.

Note

If the ticket involves security issues it has to be categorized as a "security" ticket. Any "security" tickets are automatically made Internal. Some other categorization of tickets are also automatically made Internal.

There may also be other reasons for a ticket being made Internal and they should be explained in the ticket note which sets the ticket as internal. Tickets which have been marked as internal are not to be made external without good cause and a manager's okay.

As the contents of an internal ticket are sensitive and meant to be restricted that content, or information about the content, is not to be released to people (or entities) outside of the TCC. Those who want to know about such tickets should be directed to the Services Coordinator or the Director of Academic Computing. Releasing such information outside the TCC can cost you your job.

Information that speeds responding to a ticket includes:

the "Reporter's" TCC account name,
their real name (if you can't get that from their account name),
their phone number, (needed for email or login problems)
details about the problem or request, and
when they need resolution (Estimated Day of Completion).

Develop, and reinforce, the habit about getting all needed detail the first time around. Having to go back for it later delays resolution, frustrates the person having the problem (more than they already are), and costs us additional resources.

Reports of the form “machine x is hosed” are almost useless even though they have to be followed up on. It would be decidedly more useful (and probably not that much more difficult) if it said “machine x is hosed because:”

its monitor is on fire
it says rpc_authd: program not registered (extremely easy fix)
it says “out of memory”
it says “vmunix: panic ufs: freeing_free_frag (better not say this)

Here are some of the types of questions you should be asking when you are gathering details about the problem. Approach the collection of details from the point of view of what you would need to know if you were to have to fix the problem.

How much time spent trying to correct the problem ?
What steps taken to attempt to correct the problem ?
Which Operating System (OS) does the problem occur on ?
Which software program(s), or package(s), was being used ?
Is there a pattern to the failure ?
What exact error message(s) was received ?
What was expected to happen and what actually happened ?
Was anything rebooted, or power-cycled ? (If so, what ?)

Note

The question on time spent should be answerable from the Time: field in the opening note of the ticket. The other items may be in the body of the original ticket note. If they're not then the Reporter will need to be asked about them.

Here's a relevant memo:


    From rayzer@teal.tcct.nmt.edu Thu Sep 14 10:28:18 1995
    Subject: Memo: Hardware Failures

    Whenever a machine dies and it gives a hardware error (e.g.
    kochab's memory faults) please be sure to take
    down all the information that is displayed so that our task in
    repairing the problem can be faster.  Such as the memory error, if
    we had the information on which block of memory failed, it would
    then be trivial to determine and replace the memory SIMM in
    question.  Please try to keep this in mind the next time any machine
    fails.

    Thank You.

Tech Computer Center User Consultant Handbook