Slashdot: Should vendors have root access to customer systems?

Interesting - and at comments threshold 4, meaninful - discussion on slashdot whether vendors need root access to customer's equipment/OS. Eventually, it diverges into dumb vendors vs. dumb customers.

At BEA, we don't actually need root access to the system. In fact, you have to go out of your way to run at port 80 or with other root related issues. Comes with a Java territory, I guess. In fact, we prefer not to login into the customer system at all, but rather collect logs and analyse them on our own machines.

On the other hand, I do feel the discussion of who is smarter to be close to my heart.

I think that after years of working as Backline (Tier 3) support at BEA, I find myself liking two extremes of the customers.

• I like the customers who know what they are doing, how their system or network is setup and where their logs go. I like the customers who I can ask to run the software under nohup and redirect both stdout and stderr into the same file.
  
• I also find that I don't mind customer with not much clue, but aware that they are out of their depth. There was a number of times when an engineer has to fix the system they weren't even aware of until that evening. And it usually is evening and - lo and behold - they have a whole night to sort it out.
  These customers will follow my direction to the letter, they will tell me what they see, and they will read back the error messages with a precision. Yes, it takes a bit longer to go through the steps and the support engineer need to really think on their feet, but it is still ok. And when you fix their problems, these customers do know that you helped them.
  

The customers I find myself not enjoying are those in the middle. They think they know what the problem is, therefore they only send partial logs, snip out unrelated error messages and think the problem is obvious from a terse general description. (try Server crashed today. Please send patch.) For them, I find I have to explain every step in very clear written down details.

As an example, we often request an access log and server log in parallel. A customer like this would send access log for last 3 months and a server log from the last 3 hour run for the problem that happened 2 day prior. I have to re-request the log and in process explain everything about log roll-overs, checking the log entires' timestamps and general log locations. Not something you would expect to need to do for a sysadmin of a large organisation.

In terms of case types, the most hated situation around the office here is a customer that creates a new case (again, Server crashed, please fix) and requests an engineer to join the bridge where 30 people have been discussing this issue for 8-30 hours already.

Very often, we are not useful without seeing exact exception and/or log files in a context. Also, BEA product family is very large and - even though we support all of it - we have our own individual expertise areas. My hanging server skills are much higher than my JMS message lost skills (which my coworker excels in), so just asking somebody to join the bridge (and stay on it until resolution) will actually benefit less to the customer than spending extra 10 minutes on writing down the description.

For myself, I find it survivable to land in one of those bridge calls as long as the customer has a clue.

We have two very large USA telcos that like to do bridge calls. One has engineers with a very strong clue (even their CEO does), another seems to provide no training OR resources to their so-called sysadmins. Guess which one I hate to work with? Guess which one I will NOT consider as my provider, as I can see how bad their problem-solving skills are.

Anyway, enough rant. If anybody is interested in specific aspects of support life, ask in the comments.

BlogicBlogger Over and Out