Ms Marcia Michalik from Starkey Labs, Inc. has provided an excellent overview of a lifecycle of an Oracle Severity 1 Service Request in the latest OAUG Support in Focus Newsletter (July 2006 edition). If you are an OAUG member and want to subscribe to the newsletter, update your OAUG profile. (Don’t you wish there was an OAUG Support Focus Blog?) Below is an excerpt from Marcia’s article in the newsletter:
If you have not worked a Sev 1 TAR (P1 SR), this article may help to prepare you for that day (and night). If you have had the pleasure, relive the memories! This is a real-life example. The following are just some of the entries from this service request.
How we got to this point We have identified an issue with depreciation that appears to be the result of our recent upgrade. Our business analyst (BA) has narrowed the issue down to two specific patches applied to our production environment; on an older test environment, without these patches, depreciation runs correctly. The Oracle support analyst has been able to reproduce the issue internally and has logged a bug.
Tips Oracle Support will often request an OWC session. Through a secure connection, Support can log in to your application and see exactly what you are seeing. This has provided quick, easy resolution for us in the past. Also, even after youâ€™ve logged an SR, keep working! The more information you can provide, the more you can test, the more notes you can find on MetaLink that address your issue and the quicker you will move toward resolution.
0 HOUR March 22, 16:00:09 GMT â€” It is two days before cycle end and we need to have this issue resolved before we can close the period. BA and her manager contact the Oracle duty manager to request escalation of the SR to Sev 1. It is accepted. The bug is also escalated to Sev 1. Oracle Development responds that they have accepted the escalated bug status. From this point on, both Oracle and our internal resources must be available to work the issue straight through to resolution.
Tips Oracle indicates that it is appropriate to escalate an SR when the business impact is increasing and/or deadlines are approaching. Severity levels are:
- Sev 3: Typically where an SR begins
- Sev 2: Indicates escalating business ramifications
- Escalated Sev 2: At this status, the issue will be worked continuously during business hours
- Sev 1: Issue will be worked 24/7
Escalation may be done online through the support analyst, but is most often done via phone request to the duty manager. A request for escalation must include the following:
- Reason for escalation, including business impact of the problem
- Business or implementation milestone, critical date(s) (milestone date or resolve by date), along with the type of business or implementation milestone
- Name of the person requesting the escalation and contact information (phone number, pager, e-mail address)
Bugs, like SRs, have their own statuses. The analyst will often report on the status of the bug in the SR so that you can monitor progress. Typical bug codes are:
- 11: Code bug
- 13: Document bug
- 30: Additional information requested
- 32: Not a bug
- 99: Closed, fixed
Be aware of the ramifications of escalating an issue to Sev 1. Not only does Oracle commit to working the issue 24/7, but you, as the client, must also commit to being available to work the issue 24/7. You must have an analyst, a DBA and possibly a developer available around the clock until the issue is resolved. If you are a global organization, like we are, you may have the ability to pass the issue around the globe, as Oracle will do. If not, youâ€™re in for some sleepless nights!
HOUR 7 SEV 1 March 22, 23:48:25 GMT â€” Within hours, development updates the TAR with a note that they are testing a fix.
HOUR 12 SEV 1 March 23, 4:33:58 GMT â€” BA receives the call that a one-off patch has been developed and should be tested. BA agrees to do this within hours.
Tips Be careful with one-off patches. It is your responsibility to keep track of these during future upgrades and to identify whether they need to be reapplied if the functionality was not corrected in the base product.
HOUR 31 SEV 1 March 23, 23:33:39 GMT â€” Support analyst requests that priority be reduced back to Sev 2 since this is in user testing. BA indicates that users have identified issues even after application of the patch, but they are different issues.
HOUR 37 SEV 1 March 24, 5:22:02 GMT â€” Support analyst indicates that a second TAR should be opened for the new issues identified. This SR remains in Sev 1 status until users complete all testing and are confident that the patch has corrected the original issue.
Tips Oracle Support will be firm about the need to open a new SR when a new issue is discovered while working on an existing SR. When you open a SR that has been â€œspawnedâ€ by a previous SR, be sure to make note of the originating SR number so the analyst will be able to review all of the background and get up to speed more quickly.
HOUR 53 SEV 1, HOUR 742 OVERALL March 24, 21:46:02 GMT â€” BA closes TAR. Support responds by documenting bug number, one-off patch number and resolution. Everyone gets to sleep tonight!