Last week I met blogger Bob Plankers (@plankers), author of the, and we had a great conversation on how the sysadmin role has changed over the last 5 years and what sysadmins and help desk professionals can learn from one another.


JK:  How did you get into blogging?

BP:  I got into blogging in 2005.  At that time there were not a lot of bloggers in sysadmin space.  I found that in searching the Internet for answers to questions, once in a while I knew something of interest that was not available on the Internet. My blog was the way to put it on the Internet. I’ve been in the field for around 15 years at all kinds of companies, from a consultant to the private sector to working in the help desk to working as a sysadmin at a large university in the Midwest.


JK: Since you have worked on both sides of problem determination – the help desk and as a sysadmin – what advice do you have for these teams to work better together?

BP:  A lot of sysadmins would benefit from a rotation in the help desk.  Seeing what help desk folks have to deal with, the problems they face from users and to actually talk to users who have to use the things that you are building.    A lot of times IT departments don’t follow up with the users or the help desk to find out what the pain points are.  Then you end up with people that are angry, because the application may be doing things as unintended but you never hear about them because the normal interaction between the service desk and the sysadmin is in a break-fix mode.  No one thinks to send things to a sysadmin like, hey, this app logs me out every 10 minutes and it’s a big hassle.  This is an annoying problem that a sysadmin might thing is just a security feature, but it is really impacting the user experience of the application and could be fixed.


I am pretty sensitive to that – I understand being caught as a help desk person in not quite knowing what to tell an end user who is complaining, and not getting any love from the sysadmin team because they don’t think it’s a problem since it’s not a technical issue.


Sysadmins can address technical as well as non-technical issues by listening to some of those complaints.  Addressing an issue might be as easy as explaining to the help desk why something is the way it is.  This helps a lot because they can explain it to the user, and at least the user would understand why the application is the way it is.


Beyond that, you can give the help desk access to the server monitoring tools.  It’s like sysadmins are the high priests of the IT organization and they want to hold all the information.  If you’re all on the same team, everyone should have the same information.  Give the help desk access to the information, and train the help desk team to not make any major decisions unless sysadmins are consulted first.  If the help desk staff can see what you (sysadmin) are seeing, it makes a big difference.  If they have the information of an outage that is occurring, when the end user calls the help desk, the help desk admin can speak intelligently that there is a problem and it is being worked on.


For example, I report that cable is not working in my area, and the support guy tells me that “nothing is reported in your area.”  So I go on Twitter and complain, and a guy deep inside the cable company sees it and fixes it. That’s neat, but probably not the way it should work. If the help desk appears smarter to the end user the end user will actually call the help desk when something is wrong, rather than throw up their hands when a service is slow or not responding.


This is especially important as virtual infrastructures are more pervasive – being able to work through technical and non-technical issues.


JK:  What’s an example of a non technical VM issue?

BP: VM seems slow – that is what I normally get.  I follow up with – how can you tell it is slow?  Well, I logged in and it seems kinda pokey.  Well, can you run applications or services?  Yes, but it just seems slow.  How should your application be performing, are you meeting your SLAs?  Well, yes, but the VM seems pokey.


With virtualization, it’s a different game now, your VM may be slower than physical box you used to own, but your application still works fine.  This is not a technical issue but an issue related to educating users why a VM may be slower than what they were used to, and why the business thinks it’s fine that way.


JK:  How has the System admin job changed over last 5 yrs?

BP:  Over last 5 years, the idea of working in silos has gone away, and with it some of the problems.  Historically the network guy would find out about things last – to many sysadmins he’s like a plumber – the network should work like your pipes, and we don’t need to talk to him on a regular basis, just when the plumbing plugs up. That was a bad idea then, and a real bad idea now.


The classic idea that everyone is separate is dying.  Now instead of a storage guy, or a network guy or server guy, now I have to be a generalist and have the right tools in place to see across these environments.  Virtualization also muddies the waters across these classic domains.  The rules aren’t so cut and dry. Best practices say stuff like you shouldn’t have more than 20 VM’s on a data store, but what they really mean is that you can’t have the wrong 20 VM’s on a data store.  Figuring this out is not so easy, and you need the right tools to do this that will save you time.  There are a whole bunch of tools out there, but by the time you are done implementing them you have spent more time than you will ever save in using the tool.  Having a good tool that will show you if the VM is slow, the storage issues and the network information is very valuable.


One thing I learned working in the help desk is linear troubleshooting – changing one variable or chasing one metric at a time.  A lot of sysadmins don’t know anything about storage or networking.  They never had to worry about how a network worked before virtualization.  With virtualization, now they have to configure a network, never thought about a VLAN, what is a LUN, a datastore?  How does fiber channel SAN or iSCSI work?  Take complicated storage and stack that on top of a complex network and your head really hurts.  It’s like working one of those math exams where the answers for part B and C depend on part A. You get part A wrong and you’ve screwed everything up. You’ve got to have your network solid for your storage to work, and so on.  Overall, I’d say that if you’re a sysadmin today, you’re better off being a mile wide and an inch deep in all areas.


JK:  What technology trends are you planning to blog about in 2013?

BP:  Right now I am working on a column for TechTarget around the topic that IT does not practice what it preaches when it comes to consolidation.  What I mean is that with server consolidation, cloud, virtual desktops – IT is pushing stuff back into the datacenter.  However, within the datacenter we are now seeing distributed building blocks like direct attached storage which is clustered, rather than these big storage arrays.  Within the datacenter we are becoming decentralized.  IT is doing it to save gobs and gobs of money.  It’s an interesting trend.


Another trend I find interesting is now that costs have been driven down for the infrastructure through virtualization and cloud, folks can spend more time on intangibles.  How much time do I spend performing a particular task?  Should I spend the time automating that task or is my time best spent elsewhere?




Other IT blogger profiles:

Ryan Adzima, The Techvangelist

Bill Brenner, Salted Hash

Tom Hollingsworth, The Networking Nerd

Scott Lowe,

Ivan Pepelnjak, ipSpace

Matt Simmons, Standalone SysAdmin

David Marshall VMBlog