Brokenhaze

I had a great – albeit brief – conversation with Matt Simmons while he was in town on his world tour in NYC recently that got me thinking about bringing the SysAdmin community together. This isn’t the first time that I’ve thought about how bring the SysAdmin community together in a stronger way. And, since I’ve joined Stack Exchange I’ve thought about it more and more since community building is a big part of what we do here.

The working theories are that there are a large portion of our community in the small business sector – places like regional ISPs that have a large need for administrators, but aren’t that big in the grand scheme of things. But it _seems_ that a good deal of system administrators aren’t involved in the community at all – or at least not in a visible way. There are a few questions that come to mind when you start to think about how to grow and solidify a community:

* How do I reach these people
* How do I get them involved

The problem I’m having now, is simply I don’t really have any ideas on how to accomplish these goals, how to reach out and bring people into the wonderful community that is being built.

I shall keep mulling this over, but if you have any ideas – leave them in the comments below.

I think the first time I heard the term DevOps I didn’t think all that much about it, in fact I vaguely remember thinking “oh great another group of developers that think they don’t need sysadmins and they can just code themselves out of any systems problem.” Of course, at the time I was working in a soul crushing job, with incompetent programmers who thought their job was to push out code and as long as it ran on their laptop everything was just fine. So, I may have had a slightly … jaded view of things. At that point I just put my head back down and got back to work.

It’s been about two years now since I first heard the term DevOps, and you know what – i _still_ don’t like it. However, now I don’t like it for completely new reasons.

The first, and I think biggest problem I have with the term DevOps is simply this – it shouldn’t exist. Simply, what people are calling DevOps should be shortened to “SysAdmin.” That’s right every SysAdmin should be working this way – there shouldn’t need to be a new term. Every SysAdmin should have a basic set of skills, a common ground we are first and foremost IT workers – that means we craft raw computing power into usable and complex systems. Those systems are not built by hand after the first time. They are built by automation, automation lets you not have to worry about the details of a solved problem. Automation lets you know that your complex system will be built correctly the second, third, Nth time.

In my opinion every sysadmin should at a minimum say yes to all of these things:

* You should be able to script in at least two languages
* You should have a passable command of one compiled language
* You should be able to look at a piece of code in any language and have an understanding of basically what is going on
* Why? So you can talk with your devs, that’s why

There are many people that will wave their hands, and shout “But, But that’s not what DevOps is about – DevOps is about bringing your Developers and SysAdmins closer and getting them to work together for a common good.” Ok, that’s a fair point and brings me to the second problem I have with DevOps. That problem is that the real word you are looking for is **TEAMWORK**. You shouldn’t need to coin a new term that says the IT department should work together – that should already be the goal.

My boss at my last job but it very well:

> The guys in charge don’t care about how things get done. They only care that they do get done. All they see when the Dev and SysAdmin teams argue about anything is “The Geeks are fighting again – I don’t know about what and I don’t care, they just need to figure it out and get it done.”

Everyone outside of IT sees us as a collective but, we still bicker between each other like children a lot. We need to start seeing everyone as part of the *same team*. We should take the ideals of the DevOps movement and repackage them as how things are done every day in the IT department. No need for special labels, no need to make a huge fuss about it. We just need to drop the label and get to work.

*For any dev that reads this and goes “what about me” you can just s/SysAdmin/Dev/g and it still applies – for the most part. I’m a SysAdmin so some things may be slanted that way.*

This is a crazy idea, but it’s true there really is no such thing as too complex in an IT environment. If you take a moment to think about it, everything we do is incredibly complex. Really, just take a moment to think about it. There is not one thing that you do as a Systems Administrator that isn’t complex.

You still don’t believe me do you? Fine. Lets take a look at a very simple operation. We are going to monitor a single box via SNMP. We are going to assume that you already have a central monitoring box already setup.

1. You configure your box-to-be-monitored with SNMP, configuring the proper access controls
2. You add any extra scripts that you need to call via SNMP
3. You open the firewall on the box to allow SNMP traffic
4. You configure your monitoring server to query the box-to-b-monitored via SNMP
5. You check the results

And, THAT is the simplified version of events. In reality there is a lot more that goes into just the simple process of monitoring ONE machine. That really is complex, and it’s not a bad thing.

Now having said this:
> There _is_ such a thing as **BAD** complexity.

Bad complexity is complexity for the sake of making something more complex, or the inverse: making something less complex for the sake of being *not* complex. What you want to do is create a system that is of the **correct** complexity. That is you want to create a system that is neither too simple, nor too complex.

The problem that you run into with either end of the complexity spectrum is this: either you have a system that is too basic and cannot be scaled properly as the need arises *or* you have a system that is unmaintainable, and cannot scale because there are too many pieces meshed together.

When you are designing a system, you really will never achieve the perfect amount of complexity. There will always be trade-offs you have to make, based on past design decisions, future configuration considerations, and application constraints. However what you can do is make every decision in a thoughtful way that tries to strike a balance between the two extremes of complexity. And that, is one of the true zen things when you are a sysadmin. You achieve this beautify nearly perfect level of complexity system, and you sit back and smile. Then you go run to put out the next fire.