Sunday, June 19, 2005

On Call

Being "On Call" for work is a strange thing, especially in my particular area of IS. I work in Data Warehousing and Business Intelligence. These systems aren't particularly "mission critical," as it were, which means that if they aren't available, people are inconvenienced in their work, but the company doesn't start losing money immediately.

First, the really silly part about being on call: all the text pages that say something to effect of "Everything went fine! Just wanted to let you know that the regularly scheduled 3AM backup ran just fine... again... for the 74th time in a row." Arg. How about you ONLY tell me when something goes WRONG!?

The other part of being on call is that you get to verify and sign-off on the work that administrators are doing to the systems managed by our group. Typically, this means making sure the database administrators are doing what they're supposed to be doing -- changes to database tables, permissions, etc. Now, here's the odd thing. We do these changes ONLY on the weekend, and sometimes ONLY in the middle of the night. Take tonight for instance, here I sit at 12:30 AM, waiting for a DBA to make some VERY simple changes to database views. My wife is sitting next to me wondering:

Why couldn't they do this at a reasonable time of day?
Why does my husband have to "check out" their work?
Why do they have so many conference calls?
It's not like you're a surgeon, on call for something important.

She's absolutely right. But, even though we're not a "mission critical" system, the 6,000 some users of our system still expect to have it up and running while they're working.

I do agree, though, that it's pretty silly that I have to sit and check every little thing that the DBAs and SAs do. If something weird does happen... then call me. Or, just wait until Monday so that someone can fix it at work. (Other people come in before me, so they can fix it.) ;-)

No comments: