SLA for Application Availability
Asked by Dave Trevino:

Looking for some input on approach/best practice, or a point in the right direction for any resources I may have missed.   

Currently we are in preproduction implementation of JSM on our instance. Our existing ITSM processes are all implemented in Remedy ITSM on-prem, We have identified a gap in the SLA functionality.

Specifically we are using a type of SLA known in Remedy parlance as CI Unavailability or CIU for short. We have configured the other SLA's in our Jira instance, but for this use case I am fairly certain the SLM configuration in JSM does not support. anything similar

Use case:

We have specific monitors configured which are intended to indicate if an application is available or not. We need to be able to report on a monthly basis for each application what percentage was it available for accounting for the varying availability windows of the applications (ie some apps should be available 24x7, some should be available 24x5, should be available during business hours, etc), vs the expected availability.

Current state:

In our ITSM environment events for these application SLA monitors are sent to BMC Event Manger and there are rules with cause the event to create a related CIU record. We then have a escalation(Remedy scheduled automation) which creates a record on a custom form nightly for each application indicating what percentage of the expected availability the application was actually available for based on any unavailability records corresponding to the application.

Hoping to find anyone who has tried implementing something similar, and if so any recommendations, pitfalls, approach, etc


Answers:
author: Mikael Sandberg
body: Hi [@Dave Trevino](/t5/user/viewprofilepage/user-id/5521240),

Welcome to Atlassian Community!

You should be able to do something like this in JSM using Assets. Each object would be the application and you can have the expected uptime and other information about it as attributes on the object. You can then for example [heartbeats](https://support.atlassian.com/jira-service-management-cloud/docs/what-are-heartbeats/) or [integrations](https://support.atlassian.com/jira-service-management-cloud/docs/understand-the-integration-framework/) to find out if an application is running or not. You can then act on those and calculate the uptime and report on it. I would check out [Discover alerting and on-call](https://support.atlassian.com/jira-service-management-cloud/docs/discover-alerting-and-on-call/) for more information.

comments: author: Dave Trevino
body: Thank you for the response that is fairly in line with what I had anticipated. I think one area I am not very clear on is what record would store the up/down time, as this is a daily thing entry. I am almost inclined to use a custom issue type, but not sure that would be the cleanest approach of if another asset type/attribute would be better.   

Our SLM team would need to be able to report out the data to include with their metrics so that is a factore.


author: Mikael Sandberg
body: I would keep the expected uptime as an attribute on the object and then use a request type, for example incident or outage, that is associated with the application object. You can then use the created and resolved date/time of those requests to get the outage time and then get the daily average of uptime. You would need either [Analytics](https://www.atlassian.com/platform/analytics/what-is-atlassian-analytics) (available if you have an enterprise plan) or a reporting app, like [EazyBI](https://marketplace.atlassian.com/apps/1211051/eazybi-reports-and-charts-for-jira?hosting=cloud&tab=overview), available in the Marketplace to generate that report.


Tags: cloud

jira-service-management

jira-service-management-cloud

metrics

sla