On Nov 2, 2006, at 19:59 , Narayan Desai wrote:
"Brandon" == Brandon S Allbery KF8NH <[EMAIL PROTECTED]>
writes:
Brandon> On Nov 2, 2006, at 11:26 , Paul Anderson wrote:
1) bring up new server
2) point all clients at new server (and wait for them to make the
change)
3) decommision old server
Brandon> passes all tests. The assumption here, as I stated
Brandon> recently in another context, is that sysadmins are only
Brandon> human; people do make mistakes (especially when things are
Brandon> blowing up), and even when they don't make mistakes
Brandon> unforeseen problems can arise, so it's best to not
Brandon> completely automate the process.
from your perspective, does our solution sound too hands off? I am
just kind of curious. Are there other sorts of checking we should
perform in order to make the process less error-prone? In our
experiences, this has worked well-enough in basic processes, but it
isn't cost-effective enough to use for all configuration changes...
I think what I'm getting at is that there *is* no good solution to
the problem Paul brought up, and a practical change management
solution needs to allow for the possibility that unforeseen events
could lead to it coming up even in the best-organized and "safest"
change sequences. So I prefer *not* to automate at the level you
suggest, unless it's done outside of the CM framework (as I
mentioned, a project management system could be used for such
sequencing as long as it doesn't automatically kick changes out),
both to avoid the overlap issue Paul raised and to allow changes to
be staged to test machines and require someone to sign off on success
before they're staged globally.
In short, it seems to me that paranoia and pessimistic planning are
good things when it comes to change management. :)
--
brandon s. allbery [linux,solaris,freebsd,perl] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon university KF8NH
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
