- What is XP?
- Extreme System Administration
- Caveat Admin
- Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Extreme System Administration
Okay, so 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 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.