Pagerduty workflows

1. You are here:
2. Handbook
3. Support Team Handbook
4. Support Operations Team
5. Support Operations Workflows
6. Pagerduty workflows

On this page

• Overview
• Requesting changes to PagerDuty rotations or schedules
• Determine if the request is valid
• Performing changes to shadow rotations
• Performing changes to non-shadow rotations
• Communicating the change for shadow rotations
• Communicating the change for non-shadow rotations
• Issue comment
• Announcement channel post
• SWIR issue

Overview

Requesting changes to PagerDuty rotations or schedules

All changes to PagerDuty schedules or rotations must be initiated through an Issue in the Support Ops PagerDuty Project. Requesters should create a new Issue using the appropriate Issue Template.

Determine if the request is valid

NOTE These are general guidelines. Please always use your best judgement or speak with a Support Operations Manager when you are unsure.

• For shadow rotation schedule changes, the request is essentially always valid.
• For non-shadow rotation schedule changes:
  • Additions are only valid if done 4 weeks in advance. If that amount of time is not given, an exception will need to be approved by a Support Operations Manager or Support Readiness Director.
  • Deletions are only valid if done 4 weeks in advance OR when it was not possible to do in advance (off-boarding, team transfers, etc.). If that amount of time is not given, an exception will need to be approved by a Support Operations Manager or Support Readiness Director.

Performing changes to shadow rotations

NOTE If you are removing 100% of users from a schedule, you should add the user "Support Ops Bot" on the schedule. This will prevent the layer from being deleted due to a lack of users.

The general guidelines for doing shadow rotation changes are:

• Additions can be done "now", but should be scheduled for start of next week
• Removals can be done "now" but should be scheduled for start of next week when others are on the schedule
• Removals can be done "now" with no need for scheduling when no others are on the schedule

Performing changes to non-shadow rotations

The general guidelines for doing non-shadow rotation changes are:

• Should never be done "now". These should always be scheduled:
  • Additions should be scheduled for start of next quarter when the current rotation has ended. As an example, if the rotation doesn't end until the second week of the next quarter, it should be scheduled for then. The goal is to cause as little disruption as possible to existing users.
  • Removals should be scheduled for start of next quarter when the current rotation has ended (when possible). If it is not possible (off-boarding, team transfers, etc.), please have requesting manager and their Senior manager work out the best method to do this with the least impact (such as using a placeholder and schedule overrides until the start of next quarter)
• Requests should be made at least 4 weeks in advance to allow for time to communicate the change to those impacted

Communicating the change for shadow rotations

As these tend to impact very little people, simply add a comment on the issue that details the changes (see Issue comment for more details).

Communicating the change for non-shadow rotations

As these tend to impact a sizeable number of people, you must:

• Make a comment on the issue (see Issue comment for more details)
• Make a post in #support_ops-announcements (see Announcement channel post for more details)
• Make a SWIR issue (see SWIR issue for more details)

Note your should have links in the issue for the #support_ops-announcements and the SWIR issue you create.

Issue comment

The comment you make on the issue to announce the changes should always be in the following format:

Changes scheduled for DATE_OF_SCHEDULED_CHANGE

For those on the schedule, please note the change:

| Oncall Start | Oncall End   | Prior to change     | After change        |
|:------------:|:------------:|---------------------|---------------------|
| 2020-01-01   | 2020-01-06   | GL_HANDLE_OF_PERSON | GL_HANDLE_OF_PERSON |
| 2020-01-07   | 2020-01-13   | GL_HANDLE_OF_PERSON | GL_HANDLE_OF_PERSON |
| 2020-01-14   | 2020-01-20   | GL_HANDLE_OF_PERSON | GL_HANDLE_OF_PERSON |
| 2020-01-21   | 2020-01-27   | GL_HANDLE_OF_PERSON | GL_HANDLE_OF_PERSON |
| 2020-01-28   | 2020-02-02   | GL_HANDLE_OF_PERSON | GL_HANDLE_OF_PERSON |

This will largely need to be manually created and will require using the Pagerduty UI before you make any changes and after you make the changes to determine.

You should always try to do one full rotation involving the scheduled change date and one full rotation after the schedule change date.

As an example, if the change date was 2022-10-31, you'd do one full rotation involving 2022-10-31 and the full rotation after that rotation. If 2022-10-31 was mid-way through a rotation, grab the values prior to that date at the start of that rotation.

Announcement channel post

The post in the #support_ops-announcements channel should use the following values:

SWIR issue

For the SWIR issue, the values used should always be: