• Jeff Moden (8/16/2014)


    Evil Kraig F (8/15/2014)


    Brandie Tarvin (8/15/2014)


    It's Wednesday. 3 people walk up to your cube. One is from the QA team, one is from the reporting team, and one is a business user. The QA person says she needs you to restore a database down to the QA environment immediately so she can finish testing Management's High Priority Release by the end of the week. The reporting team person says the financial reports that worked yesterday are failing this morning. The business user says the new feature released last night "doesn't work."

    EDIT: Is it sad that I'm basing these questions on stuff that actually happens to me?

    No, welcome to my world(s). Is it bad that my first question is to the reporting team guy: "Which reports, and what's their SLA's?" while asking the QA person to email me the ticket number while getting the automated restore script ready? The poor business user probably feels like he's ignored... but that's only because I haven't shipped him to the app guys yet to get me an error message I can actually use.

    Heh... I love rapid fire "triage". Here's what I'd tell an interviewer of how similar "sessions" have gone for me in the past.

    (Knowing I have a production problem that I have to fix NOW and the fact that I have a meeting in 30 minutes that I CAN'T MISS, I begin to speak...)

    Ok, QA (I actually know all these people by first name but you get the idea)... you're up first (as I turn to the keyboard to check the release notes for areas changed by the release and also look for recent changes to the problematic report). We have 4 major projects currently in QA and, since they're all mutually exclusive because of the nature of the test data for each, we have 4 active databases currently and actively in play on the QA box. Because of this "crunch", we're also out of disk space on the QA box and we don't have the room for another instance of the database you're asking for. However, not to worry (turning in my chair to face the QA person because I finished checking)... you don't actually have to wait for anything. I'm familiar with the requirements of the urgent project you speak of and it's not mutually exclusive to the "insert project name here" project in progress. Please use that database for QA of your project and let me know if you run into any problems especially in the area of privs. I do know that all of the procs have already been peer reviewed and put into a production wrapper. I can promote the database code (quickly writing a schedule out in my head) at 12:30 today. I just need you to have the QA Manager update the ticket for the project saying that it's ok for me to promote the code (this QA person already knew that but is a bit of a prima-donna and frequently needs to be reminded, so I did so gently. I do actually love the folks in QA. They all do an incredible and thankless job).

    Business user, you're next (recalling what I just saw on the screen). The release was mostly a front-end change done by the WebDev group and the fully peer reviewed and tested changes to the database weren't in the area that you just spoke of (I knew that without looking at the screen because I'm the one that did the peer reviews and promoted the code last night). I'm not putting you off. I just can't help you and it would be a waste of your valuable time for me to try. Please go see the Dev Manager and she'll be happy to help (I work closely with the Dev manager and know that's true). According to the emails I've seen this morning, she might already be aware of the problem and working on a fix but, if it's a new problem and since company policy mandates that all such problems be tracked for SOX and SEC auditing, you'll need to open a ticket, in that case. Make sure that you include some screen shots of the problem with a step-by-step description of the steps that led to the problem along with any screen shots of any error messages so that her team can quickly identify and resolve the problem as soon as possible. Understand that it was a huge release and she may be fire-fighting other problems, as well.

    Reporting person, I'm currently working on an urgent production problem and I have a required planning meeting for the new telephone system database in 30 minutes. That meeting can't be rescheduled because 3rd parties are involved and I need to resolve this production problem before that. Please come back at 11:30 (mentally allowing an extra half hour in case the meeting runs late like such meetings usually do) this morning and I'll have you pull up a chair so you can show me the problem. In the meantime, gather up as much information as you can about the problem because (again, recalling what I just checked on screen), according to my records, none of the procs, tables, or the report generator for the report you speak of have changed for at least a month. Again, not putting you off. Your problem is important to me and we'll solve it. I just can't get to it until 11:30.

    (I turn back to the keyboard to return to working on the production problem and look in my rear view mirror to see 3 people standing there with their jaws hanging. I turn in my chair to face them with a big ol' patented Jeff Moden smile and gently say...) C'mon folks... all 4 of us have deadlines here. You know what to do and I [font="Arial Black"]HAVE [/font]to fix this production problem or we're all dead meat. (They all leave because we've been through stuff like this before and they trust me, I fix the production problem in about 15 minutes (I knew what the problem was thanks to the "Morning Report" proc I had written), send out a notification that the problem has been repaired, gather up the handouts I made last night for the telephone meeting, and get there on time even after a quick stop to refill my 32 gallon coffee mug and another quick stop by the little boy's room to make room for more... it IS going to be a long meeting).

    And you have just described my office to a "T." It's amazing how people in our office forget that production systems are always the priority. And how often they assume the first IT person they walk up to is the one who can solve their problem.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.