nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Reliability tracking - incident vs. problem

Graham Hine

We have a non-software product and are trying to figure out if JIRA can he used to track incidents to help build a reliability profile.

An incident is an occurance of a problem.

So if my problem is that the product burst into flames, each time one burst into flames would be a separate incident.

I suspect some of this is terminiology, but everyone uses different terms for these things.

Accepted answers

Nic Brough -Adaptavist-

At it's most basic usage, Jira is an "issue tracker". Most people use it more as a "bug tracker", which is one use for an issue tracker, but it can easily be used to track "incidents" as well. Exactly as you say, each time system X goes "bang", you raise a new incident. When your team puts out the fire, you move it to a status that says "panic over", and then, if you're doing proper incident management, your process will spawn out into "what caused it", "how do we prevent it", "what have we learned" and so on.

(As for terminology, I think you've used your English in exactly the way I would. I then got a bit fuzzy about the differences between "issues" and "bugs", but I hope I've been clear enough!)

All comments

Nic Brough -Adaptavist-

(As for terminology, I think you've used your English in exactly the way I would. I then got a bit fuzzy about the differences between "issues" and "bugs", but I hope I've been clear enough!)

Graham Hine

Thanks Nic. I think that's how we want to use it. I'll see if I can design the workflow to do what I need.

Norman Abramovitz

If your number of problems you are tracking is relatively small (a few hundred) you could use components to associate an incident with the problem type.

If you have a large set of problem types to track then I might consider using issues as problems and then either linking the incident issue to the problem issue or turning the incident issue into sub-issue. Linking is a bit more generic since you can incidient issues linked to muliple problem issues.

If you problem tree is more than two levels deep you will need to use a hierachy plugin to help with the associiations.

For reporting you will probaly need some assistance from some linking related plugins, but it depends on the approach you will be taking.

I am assuming you want to know how incidents of a particular problem type occurred today, week month, quaruterly, yearly).

You can put your various solutions into the problem type comments

Nic Brough -Adaptavist-

As Norman says, it's well worth thinking about the long term.

A good approach is to have "incidents" which essentially go through status like:

New bad thing happen
Support is looking at it
It works now

... However, there's a whole second phase which is often neglected

We don't know why
We do know why, and we need to work on prevention and/or cure
Are there more things we can't directly fix *
We've fixed everything we can

The second phase is a root-cause analysis function, and the line with the * on the end is very important - that's where you spawn out the more generic "problem" items.

Personally, I'm not sure "heirarchy" reporting will help you much here - the point of creating "problems" is that you have, well, a problem - you might have found it because of X, which is now fixed, but it's not actually important how you found the problem.