oreilly.comSafari Books Online.Conferences.


Automating Network Administration, Part One
Pages: 1, 2


So you're convinced that automation is the way to go, and you're ready to get cracking. You are either starting with a clean slate, all your hardware ready to power on and install, or you have a network and you want to automate all of that time-wasting work that's been keeping you busy. Now I want to convince you not to start just yet.

Automation can and should save you significant amounts of time, but you can end up wasting all that time, and more, if you don't plan your automation. A plan can consist of as little as whom to inform and when to put it into production, but it can also be a project plan spanning months or years and requiring a complete rebuild of your network. Most plans are going to require some modification as you progress, but you will always have a better-designed, more complete picture solution if you make a plan before you start working.

At its most basic, a plan serves as a blueprint for your work, something you can use to remind yourself of what you are doing and in what order. In the same way, it allows other people, including your manager, and sometimes your users, to understand what you are doing and why. Because of this exchange of information, having a plan gives other people more confidence in your ability to do the job well, and you are thus much more likely to be given the resources you need to do it right and a better reward when it is all done.

Like any programming task, it is always best to work through an automation plan as completely as possible before beginning a full-scale implementation; there's no good excuse for doing 90% of the necessary work and finding out that your solution isn't compatible with your network, or that it's just not possible. The process of planning your automation should provide you with an understanding of the complexity (or lack thereof) of the task at hand and the confidence that your methods will be sufficient. This again makes you more capable of convincing others to provide you with the necessary resources to do the job right the first time.

With a plan, you, your users, and your managers will all be surprised far less by the results of your work. Nothing goes perfectly, but least when something does go wrong people will see it as a reasonable deviation from a reasonable plan, rather than the inevitable failure of someone with stars in his/her eyes.

As you get in the habit of planning the work you do, you'll find that your plans provide documentation of the network as you want it to be and your automation tools provide documentation of your network as it is. Between the two of them, it should be relatively easy for anyone to understand both the current state and the future direction of your network. This makes the loss of an employee less damaging, but it also makes everyone involved, from the low-level help-desk employee running shell scripts s/he doesn't understand to the manager who can't spell Unix to the users who have to change the way they work, feel like they are part of the ongoing work, because they can see and understand it as it progresses. It's all about people understanding and agreeing with your work, supporting you in doing it, and appreciating the amount of effort you had to do to get it done; this is what facilitates your work as you do it, enhances your company's understanding of your importance in the network, and just generally gives you the satisfaction of a job well done.

Once you're in the habit of planning your work, and you have progressed in implementing some initial automation plans, the plans become easier, because you have a clearer idea of the network and thus a more realistic idea of the work involved. This, combined with the already-completed automation, in turn makes the continuing automation easier, thus getting the plan accomplished faster. Just like automation, planning seems to feed on itself, but planning also provides your way of communicating to the rest of the world what you are doing, when, and why, which is often important if other people happen to use the servers you maintain.


Now you're ready to go build a plan to redo your entire network so you can automate it down to the last detail, aren't you? Well, once again, I want to convince you not to start yet. It seems that even in system administration, patience is a virtue.

Part one of this series was for those who weren't aware of how much of quality system administration depends on automation and planning; part two will focus on where the network starts: during the server build process. Nowhere is automation and planning more important than in the server build process, because it is the build process that determines how you will maintain your systems afterwards. An hour spent automating an install can often save you that same amount of time every month for the life of the server.

Luke A. Kanies is an independent consultant and researcher specializing in Unix automation and configuration management.

Return to

Sponsored by: