Well, it will be in an hour.

Sorry for the lack of updates this week; I've had a hellish week. But more of that in a bit.

First, yes, we went on a cruise over the weekend. Granted, it was only a 2-1/2 hour cruise around Elliot Bay, but that was part of what made it so relaxing. Here is the website of the company we went with, although there's not much information there. They have two boats; the one they talk about, Neptune's Car, is the other one. <G> We went out on the Obsession, which appeared to be slightly longer in hull length with about the same mast and sail; it's hard to say, since although I saw them both, I didn't see them side-by-side. Still, based on what I did see, I'd guess that Obsession is a bit larger, slightly slower - but it was still a lot of fun. We have got to do that again.

As for the hellish week... sigh. For various reason's, I don't really like to talk about work at AT&T Wireless here as much as I did other jobs; I'd be hard pressed to explain my reasons, but whatever they are, I'm simply less comfortable with it.

There are days, though... as I've mentioned before, my main job as the team lead for MS based systems is to evaluate system designs presented from engineering. It's not my job to determine if a project makes business sense; sadly, it isn't even really my job to operate or build systems anymore, but more to assign those builds to other people and back them up when necessary. Now, this is a new environment for AT&T Wireless, and as a result most of the designs that cross my desk have a problem or two. Usually, those things are relatively easy to fix, especially when the project teams come to me early. Lately, though, that seems to have fallen out of fashion; it's more fun, apparently, to set a deadline, purchase all the hardware, and set a schedule for me - then notify me of the existence of the project. I must be entertaining when I yell, or something.

Examples? Well, how about production servers running Microsoft Office as Administrator. Now that's just plain dumb. Why don't you just bend over - it's faster, cheaper, and if the proper lubricant is used, it'll probably do less long-term damage. The emotional scars are about the same, compared to what I'll do to you for suggesting the idea. Yet, somehow, three separate people have suggested exactly that for their projects - and every one was passed by engineering. Don't these people learn?

The solution is better documentation. If I can create clear, concise standards, and create an ironclad process for the evaluation of projects against those standards, then these hellish weeks of constant fighting will - hopefully - go away. However, that'll only work if I'm allowed to implement those standards and processes correctly.

The first difficulty with that concept is that my standards are very strict; I set tight guidelines, and getting me to grant an exception is extremely difficult. Not impossible, but you've really got to work to convince me it's necessary - in my experience, my guidelines are workable for just about any situation; it's just a matter of being creative in how you accomplish tasks. For example, it's never necessary to install Office on a non-terminal server; if your application needs to work with Office files, the use of restricted dlls and COM objects can accomplish the same tasks without exposing the system to the instabilities and security risks of the full-blown Office installation. And so on. I'm also not unreasonable; my people know what my standards are, and if you as a project manager request someone from my team to assist in making sure you're meeting those guidelines, we're happy to help. After all, it reduces our workload and headaches later.

The second problem is the way AT&T Wireless likes to resolve problems. The way I see it, the burden is on the project manager to meet my guidelines, and where they absolutely can't, to justify the exception. The way the process seems to be working right now, I'm doing the work - first in creating the guidelines, then in justifying why they should be enforced on the systems. That's backwards.

I'm told by my fellow team leaders - in fact, by every administrator who's been there for a while - that it's pointless, and I have no real option but to give up. Perhaps I'm stupid, but I just don't see it that way.

Why am I so insistent on this? It all comes down to a critical ratio in production environments; servers per admin.

It takes more work to manage a Microsoft server than a Sun server; therefore, the ratio is higher for Sun than for Microsoft, all things being equal. At ATTWS right now, we have a Sun ratio of roughly 40 to 1, which is pretty good. The highest I've seen - which ATTWS was at not all that long ago - was 50 to 1. More recently, the Sun team has been forced to accept whatever crap the product development and engineering teams came up with, and as a result the ratio is lower - instead of any admin being able to log in to any box, and know where things are located and how the system is supposed to function, it's now necessary for specific admins to work on certain systems, because they're the only ones who know how the system is laid out. 40 to 1 is still good, but most of the 40 are systems that were engineered according to strict standards. As more and more "unique" systems enter production, that ratio will continue to drop; at a guess, I'd say 20 to 1 will be the final number for the Sun team, maybe even lower. A certain chunk of systems which were all built by vendors with no overall plan has a ratio of about 5 to 1 - and those admins are overworked. That's an extreme example, though.

For MS systems, the situation is much worse. The highest ratio I've ever seen in a non-cookie-cutter environment was 30 to 1. The highest I've ever worked in was about 25 to 1. Both environments used extremely strict standards, where even small deviations from the standards meant servers weren't accepted into production. If that's the ideal situation, you can imagine what happens when that degrades - it takes a lot less to fall down to the bottom of the curve. In addition, this is as I said a brand new environment. If we start out at the bottom of the curve, it's a lot harder to get things whipped into shape later, especially if you've set the precedent. The industry standard for Microsoft systems is probably somewhere around 15 to 1; please remember, these numbers are not for homogenous environments. If you're operating in the kind of environment where every server is exactly like every other server, then of course your numbers can be much much higher, regardless of operating system.

Anyway, my goal is to create the kind of environment to shoot for that personal record; I want 30 to 1, double the standard and as high as I've seen. If I can't use the standards I want and the process I'm comfortable with, I won't even be able to hit 10 to 1. Try 5 to 1. You would think management would like that idea; we would have to spend six times the cash per server using my standards in order to match the cost per server to manage things in the environment they're advocating.

Last but not least, I've been offered the chance to purchase a replacement server. A Compaq DL-4500, tower configuration, with a single PII-450 and 512MB of RAM, 4 9GB drives with the standard SCSI controller. That system is a very nice system, and would be more than sufficient for my needs - but how much is it really worth? That's the trouble - I don't know. <G> Anyone got any thoughts on how much to offer?

Tuesday, August 28 - Movin' Right Along

Long day at work yesterday; I'm moving from my standard cube on one end of the office to a new, soon-to-be-nonstandard cube on the other end of the office, one of my new team members was in a car accident on Saturday (yes, she's OK, but her 6-week old 2001 car with 1500 miles on the odometer now has a $4000 repair bill - all thanks to an idiot who can't be bothered to look in a mirror before backing up) and, to top it all off, I'm being pressured to do something really stupid for one of the projects. Without going into specifics, let's just say they want me to essentially install unpatched and unpatchable Windows systems in the production network. Can you say "security hole"? I knew you could...