Many of you are undoubtedly familiar with using Jira as an issue tracker. But for those of you who have been juggling issue tracking and meeting SLA requirements — and for those of you who had the recently acquired VertygoSLA addon — this article may be useful as you may have found yourself rethinking how your Jira installation is structured.
As an engineering services company that thrives on meeting and beating the expectations of our service level agreements, we have very strict requirements on how those SLA’s are met, particularly in regards to time. As you may have guessed from previous articles, we extensively deploy Nagios to manage and alert us of issues to the point of obsessiveness — and with good reason. Because we keep our windows as narrow as possible, we needed reliable updates and tracking, and while what we had before works, we were really interested in a more integrated solution that would make it easier for other techs to track issues and minimize down times.
When we first started investigating, we had narrowed down our choice to Jira with the VertygoSLA addon. After installing Jira and realizing that the addon had been acquired and converted, the newer Jira Service desk addon didn’t entirely meet our needs, so we had to get creative. In our research, we found that the ScriptRunner addon added extensive functionality and some useful reporting information to Jira. At the time of writing this, ScriptRunner is free — though its likely to become a paid product down the road.
The most useful features of the ScriptRunner addon are the Built in Script Listener and the Built in Escalation service. I’m going to be assuming that you have a working knowledge of Jira already and understand how workflows and projects are created/work. If there’s enough interest, in my next post, I can go through the basics of setting up Jira workflows and projects in a later post.
To use ScriptRunner as a functional SLA tool — and this is just one of many ways to go about this — we created blank Events in the system such as ‘Escalate’ without a notification scheme. This was done mostly because we didn’t really like the built in email templates, especially when considering that the higher priority issues end up as SMS messages, we needed a template that was easier to deal with.
Leveraging this method, we would have a transition such as the following excerpt from our workflow:
As a post function for the ‘Ack Time Exceeded’ transition, we have it fire the ‘Escalate’ event, which we’ll come back to in a minute.
In the ScriptRunner addon, we used the Escalation service to keep track of timing for our SLA’s. In the above example, one of our timers will automatically transition a ticket from the New state to the Unacknowledged state. The service looks something like this:
Doing this allows us to take advantage of the script listener. Now, we could have had the transition (action) do most of what we wanted, but this method makes getting to the actual action a bit quicker and easier to deal with. Below is a screenshot (with some changes) of the script listener. One thing to note before moving on is that we discovered the interval and time elapsed can be a bit tricky since there are a few delays. In the final version, we would probably end up with the ‘elapsed’ time being more like 27 minutes to account for processing and mail lag.
As you can see below, its looking for the ‘Issue Escalated’ event to run against, then it looks at the time of day and day of the week to establish business hours etc.
I’m sure from looking at this, you can already see the potential for Jira to become a very usable service desk, and since most of the documentation for this kind of thing is already out there. Once you have the basics in place, its easy to start playing with the options and tweaking things to your advantage.
As an aside, what I’ve shown you is still in the development stages and probably won’t totally represent the final version, though I will say that this works and works quite well.