Re: Slight OT: Remote DBA team & effective support & communication
- From: Kellyn Pot'vin <kellyn.potvin@xxxxxxxxx>
- To: "Dave.Herring@xxxxxxxxxx" <Dave.Herring@xxxxxxxxxx>, oracle-l List <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 2 Nov 2011 07:54:44 -0700 (PDT)
I've worked in remote scenarios and admit fully to simply missing office
banter, but when it came to communication between remote DBA teams, my previous
employer and team did a good job at this with ICQ chat sessions for the
specific team that was open throughout the day and phone calls when we needed
to hear a voice.
The person on call addressed issues. If you had a really bad run of issues in
a 24hr period, it was great having people in so many timezones, as team members
rotated the on call with their workday. I worked with a great group of guys,
(Yells out to Fahd Mizra, Andy Klock, Paul Logan and Mark Brinsmead... :)) I
know of a couple weekends where I was having some challenges, had been up for
extended hours and Fahd took the pager from me even though there was no
expectation for him to do so, he just took on call because he's a great team
member, (and for me not be grumpy on Monday and turn into Skippy, my evil twin
sister!)
With so many people working around the world, it was essential to have solid
hand-offs from those on the east coast to me on Mountain time, then from me to
Australia, then for them to do so again to Europe... This was all tracked in a
ticketing system. Nothing is perfect, but I felt that if the hand-off was done
effectively, notes were well written out, one DBA was easily able to take over
for the next and support was smoothly transitioned.
Outlook rules or any email systems filtering is almost mandatory when you have
multiple clients served with multiple notifications, escalation preferences,
etc. This always seemed a bit more complicated and wasn't always the easiest
to manage, but again, multiple clients and complex rules were the biggest
hurdle to that issue. Where I am now, one client allows you a lot more control
and I am one that if it is not a notification I need to respond to, no page
better occur. The problem of "white noise" paging and email notifications
swamping the DBA team and making them unable to know what to respond to and
what to ignore is a huge factor for me. I simply won't tolerate it for very
long and have been known to notify a boss or two in the past that I will be
filtering white noise, no discussion otherwise.
I do have rules filtering my backup emails, etc. to folders. Unless there is a
failure, don't want to see it in my inbox. Most of my DBA team is the same on
that one, but one of my favorite DBA's to work with in my career wanted
everything and he went through it all each morning. His personal preference
and I didn't argue the point with him, he was exceptionally competent, but I
was the fire-fighter on the team, where he was the project DBA, so he didn't
need to be as aware of problems ASAP as I seemed to be.
I believe that remote DBA teams do work as effectively as the team members on
them. If a DBA is naturally a good communicator, they will do well in a remote
DBA situation, if not, there will be challenges.
Kellyn Pot'Vin
Sr. Database Administrator and Developer
DBAKevlar.com
________________________________
From: Herring Dave - dherri <Dave.Herring@xxxxxxxxxx>
To: oracle-l List <oracle-l@xxxxxxxxxxxxx>
Sent: Wednesday, November 2, 2011 8:22 AM
Subject: Slight OT: Remote DBA team & effective support & communication
I'm curious how many of you belong to DBA teams where you rarely, if ever, go
into an office and work side-by-side with other DBAs on your team. For those
who answer "yes, I rarely go into the office ...", then have you come up with
any effective methods for managing communication and support across the team?
My current team is spread across the world in 4 timezones and we use email
almost exclusively for communication and monitoring. OEM & crontab monitoring
is handled by sending us emails for various warning/critical events, on which
we need to respond within a given amount of time. We also get various
information emails from these monitoring jobs to keep track of what's going on
across the many systems we support. All this leads to a tremendous volume of
email.
What have we done to still be effective? All emails from monitoring jobs have
a Subject line prefix that categorizes the email, so we can write all sorts of
Outlook rules to manage the incoming emails. We've also worked hard at making
sure we only get emails from these jobs when absolutely necessary for our job.
I've also given examples of how to set Outlook rules to auto-forward incoming
email to your cell phone when it's an emergency and you're oncall, even an
example of how to create rules with multiple ANDs and ORs by flagging emails
and then rules against those flagged emails.
Yet with all this, emails are still getting ignored and/or half read. Volume
shouldn't be an excuse, because we all get tons of emails and organizational
solutions have been presented. Emails I send out are also ignored/half read,
so emailing about the issue won't work.
I'm not sure what else to do, which is why I'm asking you all for
strategies/rules/guidelines that you follow. Is every DBA REQUIRED to set up a
set of Outlook rules for managing support-related email? Do you have other
methods and are they a requirement? Email doesn't appear to be going away,
more systems seem to be 24 x 7 and DBAs seem to be given higher demands on what
they monitor. To me it doesn't appear our current methods are working, much
less handle future increases.
I'm not sure I want responses to this, but is the problem with me and that I'm
too wordy, have too high of expectations and am a perfectionist?
Hopefully this thread can be a worthwhile discussion and not just ranting on
others, which I can't help but do when trying to explain my current
frustation. Thanks to anyone who is still reading this!
DAVID HERRING
DBA
Acxiom Corporation
EML dave.herring@xxxxxxxxxx
TEL 630.944.4762
MBL 630.430.5988
1501 Opus Pl, Downers Grove, IL 60515, USA
WWW.ACXIOM.COM
The information contained in this communication is confidential, is intended
only for the use of the recipient named above, and may be legally privileged.
If the reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this communication
is strictly prohibited. If you have received this communication in error,
please resend this communication to the sender and delete the original message
or any copy of it from your computer system. Thank you.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
