Since we're on the subject of escalations, I thought I'd weigh in here. Not
sure how relevant this is to your end goal, but it may stimulate some
thought at the very least. 

This was in a pre 7.x environment, so the use of "Escalation Pools" was not
available yet. 

 

To help ease our troubleshooting efforts, we took a number of actions in our
environment.

1.       Created and maintained a document (spreadsheet) listing all defined
escalation, what they do, the defined timeline, and whatever other
information we needed to capture about the escalation.  Yes, this was a
manual process, but at least it gave us reference as to what was configured.

2.       It became a  "Change Control" process when ever added a new or
modifying an existing escalation, and part of that process was to update the
master reference document.

3.       We created a backend form (AR Escalation Monitor) to store
information about an escalation run.  This forms contained fields like:

.         Escalation Name

.         Start Time

.         End Time

.         #Recs

.         Secs, Mins, Hrs, etc.

.         Status

.         Secs (per/rec)

.         Free (Mins)

4.       For each escalation that we wanted to monitor (in our case all of
them), each  existing escalation was modified to include a "Push Fields"
action that pushes a new record (or updates) to the "AR Escalation Monitor"
form with each run of the escalation.

.          So basically, each time the escalation runs the following occurs:

                                                               i.
Create new record in AR Escalation Monitor, setting Escalation Name, a
"Start Time", #Recs = (#Recs +1), Etc.

                                                             ii.      Each
subsequent record processed by the escalation, updates the newly created
record and increments the #Recs counter.

                                                            iii.      For
the "Status", we set a value of "Running" at the beginning of each
transaction, and then set it to "Completed" at the end.

.         At the end of each escalation run, we end up with one new record
in "AR Escalation Monitor" that shows us useful information about the run.

.         Obviously, this process would add some overhead to what the
escalation is already defined to do.  However, after measuring the impact of
the additional overhead (in our environment), it was overwhelmingly agreed
that the benefit of the output by far outweighed any performance hit.

5.       A policy change was made to our Development Guidelines, which
required any developer who had a need to create a new escalation, to include
this process as part on that escalation.

6.       We then created a report (Crystal) which could be run On-Demand, to
display this data.

.         The typical report would show the following information:

                                                               i.      What
escalation is currently running

                                                             ii.      What
type of escalation (Time/Interval)

                                                            iii.
Previous escalations that ran (depending on the Date Range selection in the
report).

                                                           iv.      The
Start and End time for the escalation.

                                                             v.      The
number of records that were processed by the escalation

                                                           vi.      The
Duration of the escalation (Secs, Mins, Hrs).

                                                          vii.      How many
records per/sec the escalation has processed.

.         On the Crystal Report, some conditional formatting was put in
place to highlight certain records if defined thresholds have been exceeded.
Note: We defined these thresholds after establishing baselines from a
normally operating system.

 

So, to sum this all up, after having implemented this process, whenever a
problem was reported, we were able to pull this report up, Refresh, and
immediately see what escalation (if any) was running, and what the
performance of it was.  

This report was also very useful because it helped indentify if the root
cause was like related to Network issues as opposed to application.

 

Leonard Neely

 

From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of O'Brien, Keith KOB. (Citco)
Sent: Tuesday, May 12, 2009 5:46 AM
To: arslist@ARSLIST.ORG
Subject: Escalation Timeline

 

** 

Hi,

Just wondering if there is a tool or process available to document the
timeline of all active escalations on a system.

 

Regards,
Keith.

 

Disclaimer link. To see it, click the link below, or copy and paste it into
your browser's address line. http://www.citco.com/emaildisclaimer.htm 

_Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers
Are"_ 


_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"

Reply via email to