Background
NORDUnet is an international collaboration between the Nordic national networks for research and education. NORDUnet operates and monitors several different kinds of networks and services.
Having an advanced Trouble Ticket System (TTS) is imperative for todays Network Operation Centers (NOC), to be able to meet requirements such as working 24/7 in shifts both in centralized and distributed organisation. In our search for a TTS to use by NORDUnet we found that neither open source or proprietary TTS were very generic. They both needed alot of customization to fit our needs. As NORDUnet are successfully using Confluence and JIRA we decided to go ahead and customize JIRA into a TTS supporting todays high requirement for a NOC.
Implementation
The goals while customizing JIRA to work as a TTS was to make it generic, fast and intuitive enough so that it should not only be useful to our organisation but other organisations too. During the development we have taken into account standards such as the "Trouble Ticketing OSS/J API v1.2" produced by TMForum and RFC1297.
We have used many of the native functions in JIRA and then written our own plugins to achieve more advanced trouble ticket features. We have created different issue types to represent different types of tickets, such as scheduled maintenance or unscheduled problems. We are using workflows to define states of a ticket, such as open, resolved and closed. Different projects and the project permissions are utilized to be able to use the TTS in both centralized and distributed organisation, this also makes for a good way to handle escalations and clear responsibilities.
Some of the custom plugins:
- Outages - If a ticket (problem) is service affecting it can have one or many outages recorded.
- Scope - A set of fields specifying where the problem resides.
- Tabs - Additional information regarding a ticket is stored in tabs. A knowledge management tab keeps track of other tickets in the system that have similar scope values as the current ticket a user is editing. That way a user can find tickets containing similar problems and read how they were solved.
- Updates - Updates are divided in two fields to be able to separate public information and internal information.
We are using connections to other application to enhance the JIRA functionality.
In special tabs the user can find links to Confluence pages where information is stored about customers and/or suppliers that are related to the current ticket, e.g. contact and SLA info.
If a field has a set of known values it is connected to an external datarepository. The user can then either get a popup window with values or write values manually and let the postvalidation check that the values are present in the external repository.
Postfunctions are implemented to send out a subset or all of the information in the ticket as notifications, we currently support email, HTML (i.e. information is visualized on a webpage) RSS and WAP notifications.
An ICS file is attached to scheduled maintenance notification. Receivers of the notification can then add the event to their calendar.
Based on filters in JIRA information is sent to a spreadsheet server where the data is collected into reports which can then be published in confluence.
Result
Using JIRA we have created a generic TTS that can be used by different kinds of organisation and have many of the functions only expensive commercial TTS have. Almost everything we have done have been implemented using only the JIRA plugin management.
Future
We are also redefining our scope implementation to make it dynamic and more useful for organisations outside network operations. On top of that we are working on implementing an open ticket API to be able to communicate with other TTS implementations.