RE: Remote DBA
- From: "Matthew Zito" <mzito@xxxxxxxxxxx>
- To: <andy@xxxxxxxxxxxxxxx>, <kjped1313@xxxxxxxxx>
- Date: Mon, 27 Sep 2010 17:02:19 -0400
To be clear, I only mean the term in the positive, as in an employee who
I am always happy to have on my team. In addition, let's not take
"ticket" too literally - any operational person who has 10 pounds of
work to fit in an 8 pound bag, yet manages to make continuous progress,
*and* sends up the red flag when they're in trouble meets my definition.
And from my perspective, anyone who improves their time to resolution by
emailing someone back with, "Not an issue" or "Run this command", or
other similar shenanigans that don't really address the core of the
problem, doesn't get credit for solving the issue.
I even mean, at the start of the week, "here's the 10 things I need done
this week, plus keep an eye on the customer support mailing list for any
questions that we can help with" - and at the end of the week, 8 out of
the 10 are done, 1 was escalated to someone else, and the 10th we're
waiting on clarification from someone else, and we helped out with these
other things. That's great, and I didn't have to be checking in every
day to see where we were on those items, and they didn't get caught down
a rabbit hole, or sidetracked by someone who wanted five hours of their
time without talking to me first.
Not blindly metric-ing based on closed tickets. Sorry if I gave that
impression.
Matt
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Andy Klock
Sent: Monday, September 27, 2010 3:54 PM
To: kjped1313@xxxxxxxxx
Cc: Richard.Goulet@xxxxxxxxxxx; andrew.kerber@xxxxxxxxx;
cicciuxdba@xxxxxxxxx; oracle-l-freelists
Subject: Re: Remote DBA
I also like Matt's glass half full definition of "ticket closer". The
ability to prioritize and work tickets is an important (and not easy)
skill. However, I've been using that same nickname for years, but in a
more derogatory way. There are some DBAs (but this mentality affects
developers too) who will take the path of least resistance just to be
able to close a ticket. And close many of them. For example:
Ticket: Investigate ORA-01653 in UAT
Action: alter database datafile
'/u01/app/oracle/oradata/important_tablespace01.dbf' resize 1000m;
Ticket State: closed
But then, only to have this same issue rear is ugly head in PROD the
next day. I think a more important skill is to effectively work a low
priority ticket to completion so it never becomes a critical one. I
also like verbose descriptions of the resolution path and copy/pastes of
the exact commands so they can be easily understood and reproducible.
I get very worried when I see a resolution that only consists of "Done".
Other related posts:
