On Tue, 1 Feb 2000, Kenneth E. Lussier wrote:
> > 1. No support other than who ever's maintaining it.
> This is a major problem for most managers and corporate-types. Just
> because YOU can support it, they know tha you won't always be there, and
> the next person may have no clue what you did.
I refute that as an argument against doing ANYTHING, if it is otherwise
the right solution. Sysadmins are, or should be, smart enough to figure
out what their predecessors did. Unix administrators are famous for
implementing their own ad-hack solutions... most of which were intended to
be temporary but ended up being permanent. And Unix is far from the only
universe where this takes place.
Now, I'm not saying that's the right way to engineer a solution, but it's
very common out there. We all know that these things tend to happen when
some manager comes down to the IT room and say "we need this to happen
NOW!" Since they are the source of the problem, management should be
prepared to hire replacements for help that has left which are capable of
doing the job, which implies being able to figure out the processes that
are in place, or at least be able to rip out the old one and replace it
with something else, if they inherited a broken system. It also implies
that they should be willing to pay for it. There's an old saying that
time = money, and that's absolutely true. The faster you need it done,
the more it will cost...
The right answer is to install a solution that will require as little
maintenance as possible, and DOCUMENT it.
> > It may work great at first, but as the load and usage > increase do
> you really have the time to worry about > the scalability of your
> homegrown solution?
> You can never predict what kind of load you will have. Sure, you can do
> studies, you can watch connection usage and chart it all out and
> determine your "average load", but that is only the data for that
> day/week/month/year. What happens that first really bad snow storm when
> 80% of your company decides to work from home?
I have a friend who is a civil engineer, and works in traffic planning.
He'll tell you that you never plan a system around the expected peak
requirements. That condition should be considered an abberation, and poor
performance under those conditions should be understood an tolerated.
Besides which, if you build in capacity for extra traffic, the users will
find a way to use it.
> There are so many things to be considered in a remote access system, I
> don't feel that a homegrown solution would be wise in a mission critical
> place unless you really are an expert in all of the different areas
And that's another thing... except for certain kinds of businesses, RAS
should NOT be considered mission-critical. If you have work to do, and
your RAS solution is broken, get your ass into the office and do your
work! Obvious exception is when you have people whose job is to work
remotely. We have a problem with people demanding remote access (and
management is holding that up as well...) but the fact is they don't
really need it. We keep hearing how important or "critical" it is, and it
just isn't.
Now, I'm not saying it isn't something we want to provide, and I'm also
not saying it isn't higly beneficial. But mission critical? Bah...
</RANT>
--
"Quis custodiet ipsos custodes?" "Who watches the watchmen?"
-Juvenal, Satires, VI, 347
Derek D. Martin | Senior UNIX Systems/Network Administrator
Arris Interactive | A Nortel Company
[EMAIL PROTECTED] | [EMAIL PROTECTED]
-------------------------------------------------
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
