Lab 1.3: Ticket SLA, On-Call, and Notifications

Est. Time: 30 minutes

Goals:

• Create a Team, On-Call schedule, and SLA in Jira

Note:

• The SLAs we will be creating are very generous; that is because this is a class lab. For a normal SOC, SLAs will need to be much more strict- we’re talking somewhere less than 30 minutes at least for highest priority tickets. But for our case, there is no reason to set it up that way for now.
• Should you decide to modify this Jira Space for production, you will need to adjust the SLA timers to meet your contractual or self-applied SLAs.

Instructions

1. While these functions used to be partially managed in Opsgenie, Atlassian phased out that capability and instead include it within Jira itself. For anyone who has worked in Opsgenie previously, we will be doing much of the same administration, just within Jira.

2. Navigate to “Operations” for your whole Jira deployment. It’s important that you navigate to the overall Operations page rather than your Space-specific Operations page.

   

   

   1. This is the page you’re looking looking for:

   

   1. Select “Enable operations”, then “Let’s create your team”.

      

   2. Give your team a name and ensure that you yourself are on that team, then click create. This Team would be the team of SOC analysts responsible for incoming tickets.

      

3. This will create an on-call schedule schedule by default, as well escalation policies, routing rules, and more. You’ll likely land on the operations view for your Team which is where will manage on-call schedules.

   

   1. To navigate back to that page should you get lost, remember to go to the overall JIra Operations page as described above.
   2. By enabling Operations within your team, you will have created a default on-call schedule.

   3. For now the default is going to be good enough since you’re the only analyst (oh no!), but if you need to edit it, select the 3 dots and click “Edit”.

      

   4. Another important note for this page- you have also created an Escalation policy. This is a notification policy that determines how soon alerts assigned to you, during your on-call period, will also be sent to other analysts if you don’t get to them in time.

      

      1. For example, if an alert comes in, and after 10 minutes you still haven’t marked that alert as being worked by you, it will then notify everyone in the SOC Team so that someone available can work the alert.
      2. Now is a good time to review your notification settings. If you are the analyst currently on the On-Call schedule (you are, since you’re the only analyst) you will get notifications for new alerts received. You can get there from Cogwheel settings → Notification Settings → Alerts

   

   

   1. (Optional) Set up notification methods, like email, phone number (text or call), or the Jira app. Note that you will be pinged by Atlassian as we create Jira tickets, so I recommend nonintrusive notification methods for now.
      1. For now I just left my notification settings as the default, which is to email me for notifications.
   2. I recommend turning on quiet hours- If we were a production SOC things might be different, but this is a lab environment, and the last thing I want is for Jira to wake you up in the middle of the night for some reason.

      1. Still under “Alerts”, scroll down to “Do Not Disturb” and click “Turn on quiet hours”. Set those hours for something like from 5:00 PM to 9:00 AM and hit Save.

         

         

4. Now let’s set up some SLA settings. This is optional since this is a test project and it might stress some folks out- but I don’t mind it and it can be important to know how to do.

   1. Back in Jira, navigate to “Space settings” for your space.

      

   2. On the sidebar under Request Management select “SLAs”

      

   3. You should have a number of default SLAs available to you. You may have different defaults, which is okay, keep reading on.

      

   4. Let’s delete the ones that we do not need here. Delete: “Time to close after Resolution”. Click on the 3 dots next to unwanted SLAs and select “Delete”.

      1. Your list might be slightly different. Ultimately, leave only Time to resolution and Time to first response**

   5. Let’s look at the “Time to resolution”. We want this SLA to be for us to close out a ticket as completed:

      

      1. We only care about the “Incidents” section for now since that’s what our SOC tickets will be labeled as.

         

      2. We’re going to remove the SLA time for Low and other alert priorities. For example, if we send an alert to our stack with the Priority of “Low” that’s going to be more Informational than anything.

         1. Select Edit. We’ll leave the ticket category JQL alone; we just want to set the time for “Low” and “All remaining”.

            

         2. Set “Low” and “All remaining” to blank. Leaving the value blank means there will be no SLA assigned to Incident tickets that match those priorities.

         3. Once you do that, it should look something like this.

            

         4. The other SLA timers are fine as is. Like I mentioned in the note preceding this lab, these timers are generous since this is not a production SOC Jira instance. In a production SOC your SLAs will be minutes, not hours. 3. Now scroll down in this same section, still editing the SLA, and look at “Conditions”. Conditions determine when the timer starts and when the timer is breached. Let’s make a couple adjustments.

         

      3. For the timer to start, we aren’t using the old workflow so get rid of “Resolution: Cleared”.

         

      4. Now scroll down to “Finish counting time when”. This actually suits our purpose because we set a resolution as we close our tickets. So leave this as is.

         

      5. Make sure to save your changes.

         

   6. Now take a look at the “Time to first response” SLA. This SLA is going to be shorter— this is the SLA for us to begin work on the SOC ticket, so it will naturally be shorter than the closure SLA.

      1. Remember we only care about the “Incidents” section.

      2. Do like you did above and remove the SLA for Low and Other tickets.

         

      3. Scrolling down to the conditions, make sure those are set how we want them:

         1. Delete the other statuses until you’re left with just “Issue Created” under the “Start counting when” condition.

            

         2. The condition for “Start counting time when” works fine like this since we want it to start as soon as we get a ticket.

         3. Adjust “Finish counting time when” to complete once we mark a ticket as under investigation.

            1. Remove any unnecessary conditions.
            2. Add the condition “Entered Status: Under investigation”.

            3. Click the plus and type in your search.

               

            4. Your “Finishing counting time when” condition should now look like this:

               

         4. Make sure to save.

         5. Lastly before we test the new SLA, you may have noticed that all of these SLAs you were creating have a “Sample 9-5 Calendar” applied to them. SLAs in many cases are 24/7, but for this project the default is weekly and 9-5. Regardless, it’s important to know where this can be adjusted.
            1. To view these calendars click on the calendar symbol under the same SLA menu.

      

   7. This calendar dictates when SLA timers count time, so this is very important to ensure you have configured correctly. For our case, this is just fine.

      

      1. An example of how this usually works: A ticket comes in on a Saturday at 15:00. That SLA timer will not begin to tick down until Monday at 09:00.
      2. You now have SLAs set up. Go create a sample ticket in your project to make sure the timers operate as you intend.
         1. Either navigate to your Project, or just click Create at the top of the screen. Remember to use your Request type.
         2. The default priority for our tickets created manually is “Medium”.
         3. You may need to refresh your page to get SLA changes or fields to show up throughout these next steps.

      

      1. Note: in the screenshot my “Time to first response” timer specifies Tomorrow; that is clearly not within 6 hours, which is the SLA we have to acknowledge a ticket. That is because of the 9-5 schedule for all our SLAs. If we up a schedule that is 24/7, the timer would be be for exactly six hours when the ticket was created.
         1. Transition to “Under investigation” and make sure that your response SLA is met. You may need to refresh for the SLA to show as met (even though on the backend it has been met).

      

      

   8. Now close the ticket to set a resolution. This should also clear the Time to resolution SLA.

      

   9. You now have an SLA!

Help and Tips

• Configuring SLAs according to your organization’s standards helps maintain quick response times, and helps measure whether your staffing is adequate.
• Jira sometimes takes a moment to show SLA changes. Try refreshing your page.

Additional References

• Setting up SLAs in Jira