While it is true that an incoming sysadmin should be able to figure out
what a predecssor did, it's the WHY that's important. And what else
does it impact. In a support situation RTFM is important if someone
documented it first as was pointed out earlier.
> -----Original Message-----
> From: Derek Martin [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, February 01, 2000 2:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cisco Router Configuration
>
> 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
> **********************************************************
**********************************************************
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
**********************************************************
