Sysadmin Appreciation Day
w00t! It's Sysadmin Appreciation day! What could be better?
System Administrator Appreciation Day - A special day, once a year, to acknowledge the worthiness and appreciation of the person occupying the role, especially as it is often this person who really keeps the wheels of your company turning.
- Read about the day: www.sysadminday.com
- UserFriendly's cartoon: www.userfriendly.org
- Do something good for yourself and join Usenix/SAGE: www.sage.org
- Schedule some "me time" and register for LISA in the US, or SANE in Europe.
OSCON2004: July 26-30, Portland
We're pleased to announce that Tom will be teaching a new and updated version of his class, "Time Management for System Administrators: Getting it all done and not going (more) crazy!" the Open Source Convention 2004 at the Portland Marriott Downtown, Portland, Oregon, July 26, 2004 - July 30, 2004. The class will be on July 26, 1:45pm to 5:15pm. More details soon.Apple OS X Server: Ready for Prime Time?
I really like Apple OS X. I really, really, really like it. It's what Unix people have been begging for for years: Full BSD unix with a kick-butt GUI. The email reader alone is reason to switch. I'm a recent convert to the Mac world and now I'm converting my entire 8.5B company to be running on Macs.
However, OS X Server doesn't seem to be ready for prime time. There's so much great stuff (Admin Tool) but once you start using it for real-word situations it seems to be, well, incomplete. OpenDirectory is buggy, the open-source tools they provide are based on old versions of code (Cyrus, postfix, Apache, OpenLDAP, others) with tons of known bugs. I'm very happy with my Xserve G4s and G5s, but now that I've put them in a co-lo, I see all these little annoyances that make me long for a Dell 1440 1U server running FreeBSD.
Can anyone help this author get in touch with product management for OS X Server? I'd love to pick their brains and get an understanding about the product's future. (And, yes, I've read everything about Tiger and have the preview releases).
Time Management at OSCon sold out.
We're pleased to announce that Tom's class "Time Management for System Administrators: Getting it all done and not going (more) crazy!" is sold out for the O'Reilly Open Source Convention 2004 in Portland, Oregon, July 26, 2004 - July 30, 2004. You can sign up for the same tutorial at LISA 2004 in Atlanta, Georgia Nov. 14-19, 2004. See you there!
How much support do you provide to unapproved equipment?
On the $GROUPNAME mailing list (that's a NJ-based SAGE-local group) someone asked for help putting together a policy on how much effort Sysadmins were permitted to spend on unsupported hardware/software that users asked questions about. We have much to say about this issue.The question was as follows:
I have a user who has his own Treo 600. He is having some problems with it, and has come to me for help. I'm looking for some sample policy statements where support for unapproved equipment is discussed. [...] I don't want to be draconian about this, but I do need to draw a line somewhere.
You got it absolutely right. You shouldn't be draconian, but you don't want this drowning person to drag you down too. Imagine if "being helpful" delayed your other projects. How embarrassing it would be to have to tell your boss why an important project was delayed because you were working on something that he/she isn't paying you to fix!
When I worked at Bell Labs we had an official, but unwritten, policy about this: We could work for 60 minutes on unsupported equipment and even then only if there we no other pressing issues.
This policy started in the days of funny PC video cards that required a driver for each program. One of our PC technicians had spent an entire day trying to debug a video driver issue and failed. He was trying to be nice. However, at his salary it would have been cheaper to give the person a free video card that was on our list of supported cards.
Some important things that made it work so well:
- Our supervisor supported us. They agreed that 60 minutes was reasonable for unsupported equipment.
- We told people about the time limit at the START of working. If you tell people once you get to the time limit, it just looks like you're giving up and making up an excuse.
- We told people the limit was 30 minutes. At the 60 minute mark, we looked like heros for trying so hard even though we'd failed to fix the problem.
The instructions to the sysadmins was to actually take your hands off the keyboard and back away from the computer then say, "Gosh, this isn't on our supported list of (whatever). But I tell ya what! I'm in a good mood today, so I'll give it my best shot for 30 minutes and if I can't figure it out, I have to give up. ok?" The customer would always agree.
Before this policy: Our boss would get angry phone calls complaining that something couldn't be fixed. Of course, this put him in a difficult situation because an angry person doesn't want to hear, "Oh yeah? Well, he wasn't even supposed to be helping you!"
After this policy: Our boss often would get love notes from users saying, "Gosh, he worked on something for a full hour and I know he wasn't supposed to but I want to recognize his great effort! Thanks! You have a great staff!" (and that was for situations were the task WASN'T successful!)
It isn't about the time limit, it's about how you sell it!
New career, same old stuff
Earlier this year I switched careers from sysadmin to aerodynamicist at a Formula 1 motor racing team (after completing a PhD in Aeronautical Engineering). As it turns out, in some ways, being an aerodynamicist at a racing team requires many of the same tools and processes as being a sysadmin. Here's what I have found...
Tools:
There are many things going on at once, as with most jobs. It can be difficult to keep track of everything you need to do, when you need to do it by, who needs to know when you have completed your task, and what you have done so far. For me, the tool that comes to mind for this task is a light-weight trouble ticket system. There can also be problems that occur with the model or the wind-tunnel operations that need to be tracked. Again, a trouble-ticket system is useful for this. (Chapter 16: Customer Care)
One of the most important parts of the job is viewing the wind-tunnel data produced. For this we have a suite of in-house software, and associated configuration files and templates. As the software changes and more functionality is added, the configuration files and templates change. No single person is responsible for these, the aerodynamicists all need to be able to add and update templates for others to use. The best way of sharing these updates, and being able to revert to previous versions if an update adversely effects your work, is, naturally revision control software, which we routinely use for important system configuration files as sysadmins. (Chapter 10: Change Management)
Processes:
Speaking of this in-house software that gets updated... It is a critical piece of software. If it doesn't work, the aerodynamicists are dead in the water. Even though the software is tested, real-life use of it puts it through its paces more rigorously. To avoid taking down all the aerodynamicists, new releases are first given to one volunteer aerodynamicist, who tests it, and works out the bugs (and has access to the previous stable release, to get back up and running if the new version fails badly). After that aerodynamicist okays it, the software is released to the rest of the (small) group. This is a miniature version of the One-Some-Many roll-out process. (Chapter 13)
Wind-tunnel time is precious and tightly scheduled. Tunnel testing involves someone to run the tunnel, an aerodynamicist and some model makers. The aerodynamicist directs the test, but everyone needs to be on the same page.
A test list must be prepared in advance, with a list of parts to be tested, and the order in which they are tested. The model makers pre-fit the parts to the model, to make sure there will be no problems when the time comes to test them. The aerodynamicist considers, and documents in advance how the test will proceed based on the results from each part as it is tested. Beyond looking at the results to decide which part X (e.g. front wing end-plate) is better, there is no thinking required on the day. The decisions have been made in advance, and no tunnel time is lost trying to decide what parts to run next. This process is very much like the process we used for preparing for maintenance windows (Chapter 12). Document what you want to do, what could happen at each step, and what you should do as a result. That way no time is lost during the time-critical period in which you are doing the work. Preparation and check lists are key.
