Slashdot Mirror
Agile Methods in System Administration?
sta asks: "Agile methodologies focusing on development techniques and approaches abound, many of which at the very least give food for thought. I have been in constant discussion with our dev manager about agile approaches and their extension to the systems administration world. Can agile methods and the agile mind set be applied to the systems administration world? Does systems administration rely on policy and procedure for it's integrity and reliability or is that just an ingrained habit? There appear to be a number of administrative tools that claim agility but are there any established agile methodologies?"
Geekness has put food on my table for 20+ years but I have no idea what the submitter was asking and Babelfish isn't helping.
Trolling is a art,
i think that no one should post an answer.
you want an answer? use your agility (+13)!
to adjust the shield harmonics of your projects, you could create a feeback loop in their subspace attenuators!
Then... PROFIT!!!!111
...but if it's lacking, one can usual balance it out by scoring higher in the areas of cynicism, paranoia and sadistic glee, I've found.
Village idiot in some extremely smart villages.
Agility not (always) substitute lack of knowledge.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
The real question, though is how aggregated interactive communities can help us embrace best-of-breed experiences and optimize e-business networks in the field of bricks-and-clicks vortals. Agile technologies are great and all, but will they leverage frictionless initiatives? Didn't think so.
Another one bites the dust
This guy provides an intro to agile methodologies. Not being familiar with this notion and not having finished the article, I don't know how you'd apply agile methods (or eXtreme Programming methods, of which "agile" seems to be an offshoot) to system administration but this text from the article seems to indicate that it might be possible:
The following factors suggest an adaptive [agile] process
* Uncertain or volatile requirements
* Responsible and motivated developers
* Customer who understands and will get involved.
These factors suggest a predictive process
* A team of over a hundred
* Fixed price, or more correctly a fixed scope, contract
"It's a wonderful idea. But it doesn't work." -- Tad Danielewski
Fuck Slashdot. It has officially
JUMPED THE SHARK
I mean, this post is basically a form question. "Can I use [buzzword] to achieve [unrelated goal]? How can I [verbed noun] my [neologism] to [marketing speak]?"
I'm just waiting for the dupe. Seriously. Where's Jon Katz to ask "If only people would pay attention to Agile Methodologies, they wouldn't have shot all those kids in the face! Agile Methodologies are the unsung heroes of high school!"
I refuse to comment on posts that do not include a link that can be slashdotted!
Hang on, that makes this an oxy-moron....
gus
.. if only.
Of the top of my head, while I doubt it can be applied in its entirity to all of "system administration" in any realistic way, two things are possible, I think.
First, and most obviously, you can apply agile methodologies to creating sysadmin tools to help you do your job.
Second, more subtlely, and perhaps more importantly, you can apply the idea of pervasive testing, probably the most important tenant of agile methodologies (although that's my opinion, not necessarily held by the "experts"), to your sysadmin job.
Every time a user calls you up and says a resource is down, and you didn't already know about it, that is a failure. Really, creating test scripts for such things isn't too hard on average; a script to send email through the corporate email system and retrieve it, once a minute. A script to iterate through all user files and do some basic permission checks every night. A script that pings critical machines every five seconds and does something drastic if they don't reply.
A lot of this is available haphazardly already, some of it you'd have to write, and some things you'd have to get a little creative with. (Example: Checking if the voice mail system is still up is not impossible, but would take a bit of work.) What I'd recommend to go forward in an "agile" sense is to start plucking low lying fruit: Whatever you current most common problem is that you get from users, write a script to detect it before they do. Then proceed to the next most common problem.
A completely adaptive system that detects everything is probably out of your reach. On the other hand, the number of relatively simple precautions that could be taken and aren't sometimes surprises me. You can reach a happy middle in most cases, I think.
I think agility is very important. Yesterday, I was using typing on the computer to repair damage done to our system by one of our clueless lusers (Bob) while simultaneously delivering a series of side kicks and back kicks to his abdomen to make sure he understood the gravity of his mistake. This involves both balance and agility. Lucy walked in on us and was about to cry for help when I immediately executing a beautiful spinning roundhouse kick to her temple. Again, fast reaction times and the ability to rapidly change direction and momentum -- agility -- saved the day. In the meantime, Bob was able to gasp a breath of air and was about to run away. Seeing Lucy drop to the ground, I whipped around a delievered a picture-perfect forearm smash right into Bob's teeth! Knocked him out cold. I continued typing on the computer, repairing the mess while simultaneously flicking the door to my office closed with my foot to conceal the physical mess.
Agility is the key to sanity as a sysadmin, my friends. If you can't multitask like that, you're gonna have a tough life. They don't teach you this shit in school.
GMD
watch this
No.
Yes and Yes (in that order).
No (see answer 1).
If you are at all familiar with XP, then you've probably heard YAGNI. XP is all about option theory, because it is expensive to write good software, so you need to keep your options open so you don't through money away.
You don't have that problem in system administration because so many of the tools are so cheap. And YOU ARE GOING TO NEED IT. We've seen the YAGNI approach to home firewalls and spyware checkers and anti-virus. System Administration is about having it all. So many great tools out there and not enough cuban coffee to try them all out.
I'm sure there are some big administration projects that would benefit from XP, but I don't have any experience with them. It seems the agile practices are best applied to development work.
Technology Consulting & Free Downloads
It appears that the poster has hit the Guiness a little early already today!
For once, the slew of sub-witty barbs and carpet bomb of +Funny mods is actually the best response to the posted story.
I hate these flavour of the month marketing-memes that always generate more heat than light.
Lard.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Now you can get to "No's" when you ask for mission-critical hardware or software.
as someone who has developed software under a couple of different processes, i actually find this a compelling question...
if it came to a choice or not, i'd not be very inclined to following any porcess. my favourite programming tools are a clipboard and a mechanical pencil -- and frankly after i've drawn up a UML i end up wanting to be an Agile programmer almost by default. it depends on how you're defining Agile.
for that matter, IBM claims that its Rational Unified Process is inherently flexible, but having had to program in that process a few times, i'll argue that it's not.
let's argue that one of the key tenets of the Agile Method is to encourage the talented and motivated to do a good job and lead through their individualism. in a small or even medium sized business, that is a good way to run things (and this is true of fields other than IT). it encourages random improvements and magic features that might not have been planned in the roadmap since version 0.1.1. and if you are running a particularly small group, it is brilliant way to do things.
by comparison, if i was managing the development of a prodcut like M$ Word, i would live in dread of a rogue coder doing something brilliant but failing to properly check that every object and variable behaved like it was supposed to. i'm reminded of a blog by a microsoft programmer with a bug that caused havoc with the mac version
bringing it back to the sysadmin question: i thik there is a lot of potentilal in using Agile Methods. flexible and fast are what the cutsomers want. but i think there needs to be a further defining of what the "official" Agile Method is because i can certainly see problems with it.
as someone who sysadmins some very strange situations, i can imagine horrible problems if one of my junior admins decided to go all rogue elephant on a DNS server using some OS that is incompatible in a weird and unknown way
i love and encourage people to find their magic solutions to scertain questions, but yes i must admit that if you do something that means a batch of our users can no longer find the network then i'm a little worried.
to my future junior sysadmins: yes we can already run the directory and network with any damn OS you choose, they all fit. magic improvements are highly welcomed and i look forward to them. but please, follow the damn chart, there are a couple things that are in place and already work.
Is this what Willis was talkin' 'bout?
Incremental adding of features, upgrading, transitions etc. One step at a time, evaluating the value of each step.
It is not as easy as it sounds, although recent advances in virtualization at the OS level and service level is going to make it a lot more interesting if not easier.
FFS, if I wanted to read nonsensical crap like this submission, I'd do some work!
MacBook Pro. Worst name since the Bicycle
I... read Argyle..
This was on Multics, which had to stay available 7/24, and for which there was support for changing hardware (a brand new thesis on that one) and softwware on the fly.
If they'd blown it during the the first pack, they could revert to a backup disk pack, fix the problem and continue.
The method was continuous small changes, applied in low-load periods, watched through high-load priods and then accepted. After whic h you applied the next small change to that subsystem. You could be changing lots of other subsystems at the same time, of course, so longas they weren't dependant on each other,a and you could keep them straight in your head.
Have a look on google scholar for Multics and continuous change.
--dave
davecb@spamcop.net
You need to try www.business2.com or www.fastcompany.com . They know all the buzzwords.
It's good to use your head, but not as a battering ram.
Can anyone post a translation of the story from Marketspeak or Advertinese ( I can't tell which it is ) into plain English?
I suspect there is some ridiculous "methodology" called "Agile" that those silly programmers use to try and make their code less sucky, and the poster wonders if it could be usefully applied to SA work.
Well, unless it involves us learning how to get a job where we can put any misconfigured piece of DHCP request answering shit on someones production network, then go away to play pool on the table that was installed "because we're creative and have special needs", then I don't really want to know...
But, let's be fair and take a look at what agile is... (from http://agilemanifesto.org/)
Processes are bad.
"Hey, my account won't let me sign in!"
"Yeah man, that new account generation proccess that ensures you get access to the dozen departmental systems that people designed themselves because they know better, that was just too fascist for me man!"
Deliver stuff early when it partially works - yes, we SAs invented that, it's called kludging.
Talking to people in your team is a good way of communicating - yes, also we've heard there's this thing called fire that you can use to heat things up.
Working software is the primary measure of progress - you don't say! Really? I also heard there's this thing called fire that you can use to make cold things hotter.
You should try to make your software well designed and technially excellent - that's where my Perl scripts have been going wrong! I've been trying to make them shit all this time! D'oh!
Motivated people make better programmers - cattle prods are motivating, aren't they?
Do I sound bitter? Well, today I had to spend an hour of my life (that I won't get back again) teaching a perfecty intelligent person how to jump through the stupid hoops needed to make a piece of shoddy software designed by an intellectually challenged monkey perform a simple task for them. Yeah, making all twenty icons look the same, that was good idea. Maximise should show you more of the current document? No way man, it's just a conspiracy - don't let those Micro$oft bastards force you to comply to interface standards.
~~~~~ BigLig2? You mean there's another one of me?
1) Pair admining of difficult tasks such as the install of new applications (tried and recommended).
2) Pen and paper UML deployment diagrams (I'm not sure if this is strictly agile unless you use post-its and A3, but it is useful).
3) Risk based analysis of projects -- of course, and most admins do this anyway on instinct.
4) Test driven setup/deployment -- again I think admins already have this when they do ORT.
5) Collective ownership -- this sits well with admins already.
delicate DBA shudder
I think that agility is the opposite of what we're driving for in a production system. The IT Infrastructure Library (ITIL) is a codification of best practices for operating data centers. One of the key tenets is to control changes by a formal release management program: bundle the changes into a release, test the release, and migrate to the release.
The point is that production has to be reliable and stable between releases. Agile methodology is designed to create rapid change cycles, which to me seems to be the opposite goal.
Having said that, the trend toward virtualization and clustering may permit a more agile approach. Change one server in the cluster, validate, switchover, and do the other. Wash, rinse, repeat.
I've been a sysadmin for 10 years, and all I have to say to the submitter is:
say what you mean in fucking english
Hmm, I wonder if that answers his question...
Gimme a break, no real engineer talks like this, only managers or really bad programmers/engineers shooting to be in management use this many buzz words, especially when talking to other engineer types. Pretty sad that Slashdot would even post this. But in answer to the posters questions, good Sysadmin boils down to 3 things,
1. Standards Standards Standards
2. good change management that is actually used, that involves testing before production
3. knowing when it is appropriate to ignore the first 2 rules and knowing when it isn't
To me the word "agile" in programming has come to mean "a renaissance of best practices". In other words, an excellent programmer is already agile, but a mearly"good" programmer might benefit from having it spelled out.
/etc configs (if you're using dispatch-conf + RCS on your gentoo box, you're doing this already .. just start checking YOUR changes in the RCS files too.. this saves my butt at least once a week)
.. does your machine need a certain config? Write a script that verifies that the config is present. Run it, it will fail. Fix the config, run it again, watch it succeed. Now put the script in cron and forget about it (you might want to build a framework for this if you have a lot of these little scripts puttering around). This too has saved my butt: I have scripts that make sure ports are CLOSED on certain machines.. when the firewall config was accidentally erased I detected it right away.
.. your scripts will be shorter and more robust. Use programs like djb's daemontools to run daemons, instead of this bizarre thing where they put themselves in the background and you need all this scaffolding to track them down to start/stop/watchdog (wtf is up with that anyway).
.. use publicfile instead of Apache .. etc.. just do the simplest thing that can work.
But by giving it this new name, there's a risk of backlash. I guess that's happened already, judging by the utterly vapid responses to this post!
To me, agile means the following things:
* don't do work until you need to
* do everything in the simplest way you can
* write tests for everything
* make your work relocatable and reusable
* use version control
* communicate with customers
* release your work to the customer as rapidly as practical
Now, I happen to wear both a sysadmin and a programmer hat depending on the time of day. Mostly sysadmin, but since discovering this philosophy of programming, I've started doing more coding. It's a pretty amazing feeling to have 100% code test coverage with everything tucked away in version control, with single-command deployment and distribution to client machines. They never taught me this stuff in school.
So, if you're a syadmin, and you're not as cynical as the other slashdotters here today, can you see anything in that list that might help you?
Here's some things I do as a sysadmin:
* use version control for
* practice "test-first sysadmin"
* do everything in as simple a way as possible: for your next script, use environment variables and the presence/absence of files in a directory to configure it, instead of inventing Yet Another Config File format
Use the filesystem instead of MySQL
Don't ever install things by hand. Build a custom package. If your OS doesn't let you do this easily, switch to one that does (gentoo rocks for this as well).
* document everything: when you do something, make a note of it on a wiki or a text file. Give the other sysadmins access and chide them when they don't keep the file up to date. lead by example.
* automate: don't do anything 3 times. anything you do a third time, automate it. (you will appreciate the simplicity of using the filesystem as your config file when you do this, by the way). need to watch something on a box? create an rss feed. you don't need a web server, just build the rss feed and scp it from your laptop every hour. do whatever it takes for you to work as little as possible yet meet your goals.
Yeah, you probably do a lot of this already, but you'd never think of calling it "agile" or anything else other than "a good job". Fine, whatever. Agile is more of a mindset than anything else, based around simplicity and being ready for change.
No
I get the thinking behind not performing a task mutiple times, but sometimes (for me) it seems silly to create a script for something ... why? Well because then I have to create documentation to remind me what the script is called and what it does.
... things like that [I know inane example but just go with me on this one, ok?].
Mainly I do web design with php. I can write classes for all sorts of things, shorthand variables for $_SERVER variables and all sorts of automations. But at the end of the day I've forgotten what I called them. Was it $thisHost or $myHost
Often I find it easier to repeat a task rather than searching for the tool that I created to repeat the task.
Any tips?
PS: This is why I was good at maths and physics, I could go back and work out the equations from first principles and develop rational arguments based on the equations. In other subjects you couldn't do that.
In contrast, once said hardware/infrastructure is up and running, recurring sysadmin tasks are reasonably well-defined and are largely a known commodity.
That being said, most of the good sysadmins that I've known are "lazy" (in a good way), preferring task automation and scripts to manual monkeywork. This is very much in the spirit of the build/test automation that lies at the heart of most decent agile approaches.