This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

1

Shouldn't this be a SO question. I think it has already been asked there anyway.
–
Tim MatthewsMay 22 '09 at 5:40

Yes, but as has been noted on that question, there exist two very separate communities on SF and SO. I think it'd be interesting to see what programmer things sysadmins think sysadmins should know, rather than what programmer things programmers think sysadmins should know.
–
TimMay 22 '09 at 12:19

12 Answers
12

Version Control. Be able to generate, read and apply patches. Know how to use a version control system that presents repository wide versions and why you want one. Know how to write descriptive changelogs and why you want them. Know how to search a repository's logs for keywords and time frames.

Scripting. Do something once and be on your way. Do it twice or more, do it once then write a script.

Debugging. Know how to read a stack trace and how to report relevant errors to your software support contact. Finding the error is nice and helpful, but knowing how to fix it can take a lot of investment in reading the code. Do the part that's easy for you, and let them do the part that's easy for them.

Testing. Monitor continuously and log errors. Used in conjunction with version control and testing, you have a strong idea of what may have gone wrong when and what changed around then. Monitor both production and preproduction.

Peer Review. Propose and review changes to production systems. Test on preproduction, determine exactly what needs to be done and record what services may be affected for how long. Don't let Change Management degrade into political battles of bureaucratic power.

Study Cryptography. A modern system administrator is in charge of network resources; adding security as a final step is somewhere between impossible and a very expensive proposition. Understanding public key cryptography, password handling practices, and encryption in general will be extremely valuable.

Back in the real world...I have yet to meet a sysadmin who does any of this (apart from testing and writing a bit of doc). Maybe I've worked for the wrong companies!
–
PowerApp101May 22 '09 at 7:20

1

Then your version of reality sucks. Every one of my workers prefers vi (I learned emacs and don't feel like running through that torture twice); we've got hundreds of perl scripts and a dozen one-off php websites for support purposes. We run Opsview/nagios for monitoring, which is really just some form testing running continously--instant feedback when you commit a change. Still, I'd like to get more version control in place for websites and scripts, and better audit trails.
–
jlduggerMay 22 '09 at 7:40

You guys are Unix admins? In the Windows world, a lot of that stuff has yet to seep into the consciousness of sys admins. Believe me, I would love it if it did.
–
PowerApp101May 22 '09 at 8:36

20th century boy, we kicked our Windows admins into learning this stuff. They aren't there yet, but it's better here than when I joined. The bigger problems we are facing now are political/management issues, rather than the technical issues we had.
–
DevdasMay 22 '09 at 10:16

Oh, and we also have Windows developers with a clue, so they are actually supportive of such efforts.
–
DevdasMay 22 '09 at 10:17

Know how to program. Yes, that's important: as one commenter said, if you do it more than once, then write a script - and write it well.

Know the tools included in a standard operating system installation. For UNIX administrators, this means tools like Korn Shell (ksh) and Perl and vi. Don't rely on Emacs or Ruby or Tcl or C shell being present.

Know the network. How are Ethernet packets put together? What does a packet look like? What are the differing packet types? Get to know tools like tcpdump, wireshark, snoop, and others.

Write portable code. If the code is going to run under Linux - and Tru64 - and Solaris - and OpenVMS - then write portable code. Even if it will run under two versions of UNIX only - make it portable. But then, if it doesn't need to be portable, don't spend extra time on it.

Document, document, document, document! Document your code, create man pages, create inline Perl documentation, and whatever else is appropriate. Explain how to use the program and why you coded it that way.

Know your system's packaging tools. Know how to create RPMs for Red Hat, or HP-UX depots, or Solaris packages: this will allow you to build packages for your systems, and thus to integrate them into the installation process.

Scripting is essential, but I'd second the advice that knowing some "real" languages is a definite bonus. You can do some very useful things with the .NET System.DirectoryServices namespace, for example.

Most of the junior admins can look at one of our programmers and say (with authority), yes, I installed it correctly, here's where you have a leak which is why the code you just pushed is breaking. Or "No, its not our version of MySQL, look at your query here ..."

I think we're kind of different, when we hire a gifted administrator .. we half way expect for them to (eventually) find their way to programming, even if its just hacking something we use to work the way they need it to work.

Many, many years ago (Windows NT 3.1 in fact) I started out as a programmer specialising in writing services and even the occasional device driver. This means you get to know the Windows kernel very well. In time I got a bit bored with the programming and switched to network management. I've found my background in programming has been immensley valuable over and over again.

It's not just that writing VBScript scripts is relatively painless. Knowing how the guts of Windows works, and particularly how IP works, helps greatly with detangling odd server and network problems. Also it's a mindset. Programmers are used to documentation and version control, and it horrifies me me to see how many Windows admins will just try something to see if it works and worry about untangling the mess afterwards.

All very well, but it isn't very useful advice to say go away and work as a programmer for ten years! However I think it would help most sysadmins to have some experience of programming in a "hard" language like C++ or C#. And if you have tame programmers in your organisation go drinking with them!

With all the descriptions here, I'm not going to say that I am a sysadmin. But the fact that I built and manage a couple of windows/linux server, I must admit something:

in linux, bash scripting is a must to know - if you know how to integrate it with perl/awk/etc, it's better. I found that many task became easier by using it.

Knowing to program in C/C++ helps a lot. Sometimes you have to modify a GNU source code (if you use one) to suit your needs because became a GNU product doesn't ensure you will always get the help you need on time - and many times they are written in C/C++.

Programming - Language doesn't matter, just as long as you understand the logic and process you can learn and adapt to any language.

How to DOCUMENT CODE and CHANGES - this one is huge. How many times have you been stuck looking at a configuration trying to figure out why the heck did somebody do this and what is it going to affect if we change it back. This one goes beyond anything you code or script, this one covers when you make changes in the firewall settings to handle a fringe case when user X recieves email from domain Y on a tuesday afternoon when its raining out. And it may not be you, it might be the PFY who decides to go ahead and do itand then has to call you up at 2am on your vacation because everything broke in a hideous manner.

System languages - On Windows this is things like Powershell and WMI that let your scripting languages tie into some pretty powerful resources and do anything on a PC. Unix/Linux has their own set of tools that I'm not qualified to speak on.

Knowing how to bind to your LDAP and retrieve needed info in your scripting language of choice is key for everything from troubleshooting to really stepping up various types of automation (account and resource provisioning, more intelligent checks on user or machine accounts).

May seem basic but I have seen plenty of bread-n-butter shops where folks don't think they have a need for this kind of system administration. Plenty of places spend big $$$ on big sets of administrative tools and, as far as I can tell, 95% of what they use the tools for could have been done with a few hours of scripting if anybody knew that or knew how to do it.