We take care of this with Telamon's TelAlert. Alerts come from OpenView (or
other places) and trigger alarms that get sent to TelAlert. We have TelAlert
programmed with shift and on-call information for the various support teams.
It calls (digitized voice messages), pages, announces through a loudspeaker,
or emails people on the list - in the order we prescribe - until someone on
the list "acknowledges" the call. ACKS can be accomplished over the
telephone by hitting a code on the keypad, via 2-way pagers, via a web
interface, or via email messages. If calls aren't ACKed within a
programmable timeframe, TelAlert moves down the list (including imbedded
lists) until someone does. In some cases we have lists that get FYI'd alarms
in addition to specific lists where an ACK is required.
TelAlert also uses direct TAP access (if you specify it) to pager services -
rather than email delivery - which in most cases gives you a guaranteed
notification that your message was actually transmitted by the paging
service. Handy when your email service may go through multiple hops and
queues and time-sensitive messages may get stuck in full or delayed mail
queues for hours. Combined with the ability to keep sending a message until
a positive acknowledgement comes back, it makes for a truly mission-critical
notification process.
If one of our 3000s goes down during business hours, an announcement gets
broadcast over a speaker in the computer room, myself and my assistant's
desk phones get called with a digital voice message, if no response from
either of us, it tries my cell phone, then his pager, then on to the a
backup team. After hours it tries my cell phone, my home phone, his pager,
his cell phone, our work and home email addresses, then the operations desk.
We also have it send summary notices to a large (Texas Instruments) LED
message board in our help desk area so help desk operators have a running
status of any downed systems.
-Chris (a very satisfied TelAlert customer) Bartram
-----Original Message-----
From: [log in to unmask]
[mailto:[log in to unmask]]
Sent: Monday, May 07, 2001 11:29 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] email as the best common
denominator
X-no-Archive:yes
That's one problem with automated reporting that you don't
have with people
reporting to an on-call: what happens when the person
on-call does not
respond. I suppose one could have a failure start a process
which will
"message" someone (I know, message is not normally a verb),
then sleep /
pause for n minutes, and at some point, "message" a
secondary on-call. All
other things being equal, the primary gets the message, and
the first thing
they do is kill the notification job. Of course, if the
primary contact is a
group, then more than one person should know about the
problem. I'm not sure
which is the "lesser of two evils", depending on messaging
to notify someone
and depending on them to respond, or automatically intruding
into the lives
of more than one person at a time.
But I've certainly heard that discussion here, where someone
in Operations
insisted that they paged an on-call (whose reputation for
responding was
impeccable), and the on-call having to defend herself that
she most
certainly did not receive any such page.
And, even if one's messaging service is impeccable, all it
takes is one
failed satellite or misdirected backhoe operator to
interrupt service, and
all bets are off.
Greg Stigers
http://www.cgiusa.com
-----Original Message-----
From: Black, Cory [mailto:[log in to unmask]]
Sent: Friday, May 04, 2001 4:01 PM
To: [log in to unmask]
Subject: Re: email as the best common denominator
It works well for us. We have 30 or so groups set up to
cover over 300
employees. A lot of work at first for the e-mail admin, but
now it's just
part of adding a new employee to the system. Many employees
fall into
multiple
groups, such as all admin assistants and all IT would cover
our departmental
admin. We don't have many rotating duties, so those changes
don't apply to
my comments. Watch how long a message take to get to a
pager. You'll find
a few messages in the archives about that.
* To join/leave the list, search archives, change list
settings, *
* etc., please visit
http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list
settings, *
* etc., please visit
http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|