Extreme system administration
System administrators often could benefit from some programming techniques, and often do. This tip, by Pat Eyler, the author of Networking Linux: A Practical Guide to TCP/IP
, is excerpted from InformIT. It talks about applying the principles of Extreme Programming to systems administration. You can click on the link to InformIT to gain more context for this tip.
Got a networking administration tip of your own? Why not send it in? We'll post it on our Web site, and we'll enter you in our tips contest for some neat prizes.
System administration is less like traditional development and more like duct taping things. Does this mean we shouldn't design things? Or that we should run from fire to fire putting out flames? I don't think so. If we spend our time making sure that our work is done right the first time, we'll all be better off.
I think this is where Extreme Programming (XP) can come in. Some of the XP practices seem to fit right into system administration. Certainly, the ideas of maintainable code (and configurations), common ownership, and clean design are laudable goals for anyone dealing with computers. But how do the practices work for a sys admin?
Collective code ownership, simple design, 40-hour weeks, and coding standards all seem to fit without a great deal of fuss and bother. Recognize that configuration files are just another body of code, and the fit is even better.
The planning game is a bit more of a stretch. Every sys admin has a wide and varied set of customers, and not all of them agree on what needs to be done. It's important to work in light of the basic needs of customers, though. Talking with them about the end results of your work and developing plans in concert with them will help ensure that you're on track with what needs to happen.
Building a body of tests for your network and/or system(s) allows you to make changes in a controlled fashion. Testing gives you the reassurance that everything is as it should be.
Refactoring should be a part of every sys admin's toolkit. If you can consistently simplify and/or improve your systems, they become easier to maintain. You can refactor configuration files. You can refactor crontabs, scripts, and even your architecture. Just make sure that you can test everything to verify that you haven't broken anything.
Having an on-site customer allows you to check the impact of changes you want to make, verify solutions you've implemented, and better foresee needs that will come up. Some methods of bringing your customers on site include email lists, a users group, and just walking around to talk to people.
Small releases allow you to put a change into place incrementally. Making changes slowly lets you back out problems quickly. You can work with greater confidence because you're doing fewer things at any given time.
Metaphor (understanding the whole system) allows each member of the sys admin team to respond quickly to problems. It also allows you to describe proposed changes more readily, and understand the potential effects of user requests.
To read this entire tip, click over to InformIT. You have to register there, but the registration is free.
Did you like this tip? You can email us to sound off.
This was first published in September 2001