Sysadmin 101: Ticketing

How to Manage and Organize Tickets

Each ticketing system has its own notion of ticket states, but in my opinion, you should, at a minimum, have the following:

  • Open: a task that needs to be completed, but hasn't been assigned to anyone.

  • Assigned: a task that's in a particular person's queue, but they haven't started work on it yet. Tasks in this state should be safe to reassign to someone else.

  • In progress: a task that has been assigned to someone who is currently working on the task. You definitely should communicate with the assignee before you reassign tickets in this state.

  • Resolved: the sysadmin believes the task has been completed and is waiting for confirmation from the person who filed the ticket before closing it.

  • Closed: the task has been completed to everyone's satisfaction.

A well run ticketing system should provide the team with the answers to a few important questions. The first question is "What should I work on now?" To answer that question, each member of the team should be able to claim tickets, and team leads or managers should be able to assign tickets to individual members of the team. It's important for people to claim tickets and start work only after they are claimed; otherwise, it's easy (and common) for two members of the team to start working on the same task without realizing it. Then everyone on the team can start working on tickets in their personal queue, starting with the highest-priority tasks.

The next question a good ticketing system should answer is "What should I work on next?" Once sysadmins' personal queues are empty, they should be able to go to the collective queue and see a list of tasks ordered by priority. It should be clear what tasks they should put on their queue, and if there's any question about it, they can go to the team lead or manager for some clarity. Again, ticket priority helps inform everyone on the team about what's next—higher-priority tasks trump lower-priority ones, not necessarily because they are less important (a ticket is always important to the person who filed it), but because they are less urgent.

I approach ticket priority as a way for users to help inform the team about how important the ticket is to them, but not how urgent it is for the team. The fact is, there's no way every employee in the company can know all of the other important tasks the sysadmin has to perform for other people nor can they be expected to weigh the importance of their need against everyone else's needs.

A good manager should reserve the right to weigh the priority assigned to a ticket against the other tickets in the queue and change the priority up or down based on its urgency relative to the other tasks. It also may be the case where a task that was low urgency two weeks ago has become urgent now because of how long it was in the queue, so a good manager would be aware of this and bump the priority. If you are going to start the practice of changing ticket priorities though, be sure to inform everyone of your intentions and how you will determine the urgency of a ticket.

Another key to managing tickets is to make sure all of your requests are captured in the ticketing system. Sometimes a coworker can be guilty of trying to skip ahead in line by messaging you with a request or walking directly to your desk to ask you to do something. Even in those cases where you really are going to drop everything to work on their request, you should insist on capturing the request in a ticket so you can track the work. This isn't just so you can prioritize it based on other tasks or so you don't forget it, it's so in a week when some problem crops up based on this urgent change, you'll see this ticket along with other tasks completed that day and it will help you track down the cause.

Finally, as a manager, be careful to distribute work fairly among your team. Even if one member of the team happens to be an expert on a particular service, don't assign that person every task related to that service; it's important for everyone on the team to cross-train. Pay attention if employees try to get tickets assigned to their favorite member of the team, and don't be afraid to reassign tasks to spread the work around evenly. Finally, every ticket queue has routine, mundane grunt work that must be done. Be sure to distribute those tasks throughout the team so no one gets burnt out.

______________________

Kyle Rankin is senior security and infrastructure architect, the author of many books including Linux Hardening in Hostile Networks, DevOps Troubleshooting and The Official Ubuntu Server Book, and a columnist for Linux Journal. Follow him @kylerankin