Working effectively with ServiceNow

先审阅 issue #42 中的草稿；其中未列出任何仓库文件或测试。明确文档预期的范围，然后检查 ServiceNow 设置、RITM 和 INC 流程以及通用流程部分的完整性和一致性，再考虑将指南视为已准备就绪。

General ServiceNow setup

Effective RITM and INC column setup

You can change the visible columns using the "Gear" icon at the top-left of the panel. Columns stay constant across filter favorites. I am not aware of a way to have column favorites to switch between.

RITM Columns

• Number: The RITM number like RITM0123456.
• Assigned to: which RC team member is responsible for this request.
• Updated (sort descending by clicking this column until a downward triangle appears): Date of most recent update.
• Updated by: Who most recently updated the RITM. Useful for finding tickets that need attention. Any ticket with a non-RC BlazerID here probably needs attention.
• Created: Date of creation.
• Requested for: Lets us know which tickets haven't had "Guest" updated to the actual person. Also, helps narrowing down tickets we are trying to find.
• Requester: Generally should be the same as "Requested for", but may differ if the ticket was created by one of the RC team for someone else. This is uncommon, but can help if we need to find out information from that RC team member.
• Tags: Allows us to quickly distinguish between ticket contents to assist with triage and finding specific tickets. Can be modified in the RITM table!
• Short Description: Same as tags but should not be modified.
• Closed: Date of closure
• Closed by: Who closed the ticket. Helpful for getting information on why a ticket was closed. This has yet to come up.

INC Columns

• Number: The INC number like INC0123456.
• Assigned to: which RC team member is responsible for this request.
• Updated (sort descending by clicking this column until a downward triangle appears): Date of most recent update.
• Updated by: Who most recently updated the RITM. Useful for finding tickets that need attention. Any ticket with a non-RC BlazerID here probably needs attention.
• Created: Date of creation.
• Customer: Lets us know which tickets haven't had "Guest" updated to the actual person. Also, helps narrowing down tickets we are trying to find.
• State: An important, high-level UAB IT metric is minimizing SLA (Service Level Agreement) Breaches. Incidents that are left open too long without attention are considered a breach. Breaches reflect negatively on RC and on UAB IT. Three email warnings are sent to all members of RC at 25%, 50% and 75% time elapsed before the breach occurs. To avoid a breach, the state must not be "Open" nor "Work in Progress". If a ticket is still being worked it should be either "Pending User Info" when we are waiting for a reply or "Pending Problem Management" when we are waiting on an internal step to complete.
• Tags: Allows us to quickly distinguish between ticket contents to assist with triage and finding specific tickets. Can be modified in the INC table!
• Short description: Same as tags but should not be modified.

Setting up RITM and INC filters for common tasks

Saving filters as favorites

INC processes

Incidents are used by Enterprise IT to track issues with mission critical systems. By process, all AskIT requests start their life as an incident, and get converted or dealt with as appropriate.

We prefer to deal with Request Item tickets rather than Incidents. We have a set of customized scripts that converts [email protected] emails into RITM, and allows our team and our researchers to interact with RITM via email. So ideally we want to convert all Incidents to Requests. Conversion does not copy any notes onto the Request, effectively losing the history of the Incident. So, if there is a history, we may not want to convert.

New Incidents

An Incident is "new" if it does not yet have a conversation in the "Notes" tab. We want to convert these Incidents to Requests.

1. Ensure INC is in Research Computing scope and handle accordingly if not. See [out of scope] below.
2. In the hamburger menu, click Convert Incident to Request and follow through on the dialogs.
3. Follow the RITM intake process.

Existing Incidents

1. Make sure that [email protected] is on the "Watch List". If not, [add it] and click "Save".
2. Make sure the requester's @uabmc.edu email address is on the "Watch List" if they sent their email from that address. If not, [add it] and click "Save".
3. Make sure the "Customer" field reflects the actual person who sent the request, if they are affiliated with UAB, i.e., the request came from @uab.edu or @uabmc.edu. If the request came from another email, then leave it as "Guest".

Closing Incidents

RITM processes

1. Make sure that [email protected] is on the "Watch List". If not, [add it] and click "Save".
2. Make sure the requester's @uabmc.edu email address is on the "Watch List" if they sent their email from that address. If not, [add it] and click "Save".
3. Make sure the "Requested for" field reflects the actual person who sent the email, if they are affiliated with UAB, i.e., the request came from @uab.edu or @uabmc.edu. If the request came from another email, then leave it as "Guest".

Adding Tasks for Ops

Common processes

Identifying and handling out-of-scope tickets

• Every so often we get a ticket about servers or storage outside our scope, or questions intended for "Research Administration" (we are next to each other in the "Business service" list).
• Identifying these tickets takes some experience, so don't be afraid to ask in Slack if the ticket is in our scope or not, if you're unsure.
• If the INC is out of scope, change the "Business service" field to "AskIT" and click the "Save" button.
• Add a "Work note" under the "Notes" tab stating something like "This ticket is out of scope for INC because the server is not part of our platform."

How do I add people and email addresses to the "Watch List"?

How do I change the "Requested for" field?

Linking tickets in Slack

Triage