Difference between revisions of "Ticket Handling Guidelines"

Latest revision as of 15:08, 17 July 2018

Tickets for Newbies.

Documentation

If in doubt check the GGUS documentation: https://ggus.eu/pages/docu.php

GGUS and its documentation is always evolving, so it's worth a regular review.

Access to GGUS for new admins (and users) can be obtained through this link:

https://ggus.eu/index.php?mode=register_info

New Site Admins should be registered in the GOCDB with the relevent roles.

So my site recieved a ticket? What next?

• Does the ticket actually apply to you or your site?
  • If it doesn't then reassign the ticket back to the TPM or the unit to which the ticket should be assigned, leaving a note in the public diary.

• If the ticket is relevant, and cannot be solved immediately, set the ticket to "In Progress" and if necessary leave a note acknowledging the problem.
  • Don't leave the ticket hanging in an assigned state - this looks bad, ticket response time is a metric the NGI is judged by.

• It's worth double checking the urgency of the ticket, and lowering it (or on rare occasions, raising it) if you believe it's labelled incorrectly. It is rarely the case where a Tier 2 site could legitimately be assigned a Very Urgent or higher ticket - usually only security incidents would justify such a high urgency for a Tier-2 site running "normal" services.

• Never be shy to request further information from the user. Whilst waiting for such information, or whilst waiting on some other factor (for example seeing if a problem has calmed down, transfers have restarted etc.) the ticket should be set to "Waiting for Reply".

• When for some reason progress cannot be made on a ticket until a later date (for example, if it relies on a patch being made available by developers, or can't be solved until a new piece of hardware arrives) then a ticket should be set "On Hold".
  • When setting a ticket "On Hold" it is advisable to set a reminder date for yourself around the expected time that work on solving the problem would be able to resume. This prevents tickets being left to languish.

• Once the issue appears to be solved, depending on the nature of the problem you can either "Solve" the ticket or request that the ticket submitter confirms that the issue is cleared (setting the ticket to "Waiting for Reply" if you do).
  • It is unwise to leave setting a ticket to "Solved" up to the users, and after a suitable period of time (1 or 2 working days) the admin is advised to close the ticket themselves.
  • Tickets can always be reopened, so the solved state isn't final. However it is a good idea to only solve a ticket when you can say with some certainty that the issue is fixed.

• When solving a ticket, try to leave a helpful description of how the problem was resolved in the "solution" field - this could help other users and admins experiencing the same problem.

• In the unfortunate event that there is no solution then it advisable to use the "Unsolved" state rather then leave a ticket languishing "On Hold".

Ticket Submission Guidelines

• Choose a ticket subject that describes the problem, and try to include any pertinent information (error messages, versions etc). Files such as logs can be uploaded to help with the debugging. This saves on having to waste time supplying the information later.

• Help the TPM help you - make it as clear as possible which unit you think should be responsible for the ticket (if known). If submitting on behalf of your site it is useful to make it clear that this ticket is for a problem your site sees, not a problem with your site (otherwise your own ticket might land at your doorstep).
  • (I like to include a note of the tickets intended destination in the public diary immediately after submission.)

Ticket Trickery

• Tickets can be linked, referenced and given a master/slave relationship.
  • This behaviour is useful when a ticket depends on the resolution of another problem, or tickets are essentially duplicates (like when a problem affects multiple VOs).
  • Sometimes a problem at a site will require a support ticket to be opened with, for example, software developers.
  • Even when there is no call or clear way to directly link tickets in this fashion, it is good practice to reference relevant or similar tickets.

• To involve other stakeholders in a ticket, as there doesn't appear to be a "smart" way of doing this, you must try to use the current tools to involve the other unit. The "lite" way of doing it is simply adding the stakeholder's mail (preferably a generic address to the support unit) to the "involve others" list in the ticket. The more involved way would be to submit a second ticket to the support unit and link the two. In the latter case I would also add the e-mail address to the "Involve Others" field of the original ticket.

• Tickets can also be replicated, useful in situations such as when a site wishes to ticket multiple VOs that it supports.

Weekly Review

Tickets are normally reviewed weekly at the Tuesday GridPP Ops meeting, compiled on the day before by the Ticket Follow-Up member of the Core-ops team (currently Matt).

Ticket_follow-up