Unhelped

As of late last week, one of the major things I'm dealing with at work is the fact that one of the servers utilized by one of our applications has been taken offline. I wasn't consulted whenever the server was under consideration for decommissioning, nor was I properly informed when it actually happened. I just tried to use the application one day and realized it wasn't behaving exactly as it should, and I started poking around and troubleshooting, and eventually got to the point where I had exhausted all of my own (limited by design) options and had to call the helpdesk. Usually these calls result in someone rebooting the troublesome server, which takes care of things. Surely I could reboot the server myself, if that's all it takes? Yes, except that I'm expressly forbidden from doing that, and I have neither the physical nor virtual access to even attempt to circumvent that protocol in any case. This is life as a contractor fulfilling a vaguely technical role that piggy-backs on the DoD's existing technical infrastructure: many responsibilities, no authorization.

This time, instead of being notified that the server had been rebooted, I was informed that the server was gone, which was a bit of a shock. And thus I have entered a protracted round of exchanging information with a helpdesk representative who is authorized to track down the old server and migrate the data from it that I need to some new server, and then re-establish the proper connections my application would need with the new server, &c. &c. and again it's all stuff I could do and get done quickly by giving it my full and undivided attention, but that's not the way it works.

The extra layer of frustration for me in this scenario is that the helpdesk person has a lot of questions which I feel all boil down to the person saying to me "tell me how to do my job". I've been working this contract for just about five years now, so I learned the ropes of the applications long ago. But apparently the helpdesk has much higher turnover, so the people I learned the ropes from are long gone and now new people have taken their place, new people with no idea how my applications were set up or why they were set up that way. I've already had at least one conversation that started to stumble down that path and I had to politely yet emphatically remind the person I was talking to that I am forbidden to do anything or even know too much about how the servers are configured, and if I was told five years ago I would be using servers X, Y, and 37, and at the time I said "thanks very much" because everything worked as needed at that point, it's not exactly fair to demand that I explain the why's and wherefore's of how part of my application ended up on server 37. I wasn't told and I didn't ask. I understand if it's part of the reason why I'm in the non-functioning predicament I'm in now, but it's not as though I specifically requested that arrangement. You may have a very valid point, helpdesk person, that your predecessor never should have set things up that way, but said point validity in no way implicates me. I don't care how or why it got set up badly/lazily the first time, and I trust you to set it up better this time (not that i have any choice but to trust you) but instead of dwelling on the past let's go ahead and put things right going forward so I can get back to using my applications as normal, all right?

Every time I go through an upgrade or migration or generalized system failure like this, I tell myself that I'm going to first survive it, then turn all the questions around on the helpdesk tech after the fact, particularly the ones they raised which I wasn't able to answer due to my own enforced ignorance, and I'm going to document everything so that the next time it happens it will be that much easier to turn the entire knowledge base over to whomever is manning the helpdesk at that point somewhere down the road. I tell myself this, and yet I never quite manage to follow through on it. Well, maybe this time.