Re: Slight OT: Remote DBA team & effective support & communication
Date: Wed, 2 Nov 2011 07:54:44 -0700 (PDT)
Message-ID: <1320245684.99387.YahooMailNeo_at_web121018.mail.ne1.yahoo.com>
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_at_acxiom.com> To: oracle-l List <oracle-l_at_freelists.org> 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_at_acxiom.com 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.
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Nov 02 2011 - 09:54:44 CDT