RE: PROD without TEST

Well said Jack!
Now that I have the ammo you bet I am gonna be firing from both barrels.

Thanks

David

>From: Jack Silvey <JSilvey_at_XOL.com>
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: RE: PROD without TEST
>Date: Thu, 22 Jun 2000 15:28:04 -0800
>
>I had the same fight with management in my last job many times. I supported
>lots of canned apps, so the argument always was "but we won't be doing any
>development."
>
>The reasons that they should not deny you a test server:
>
>(1) To test your backup and recovery strategy - where else can you do this?
>By not allowing you to have a test server, they are CERTIFYING that your
>backup and recovery strategy IS AND WILL ALWAYS BE flawless. Let them think
>long and hard about taking responsibility for the fact that the database is
>unrecoverable and that the data is lost. DBAs can always find another job,
>middle management can't.
>
>Get this one in email form, and tack it to the wall. They are PREVENTING
>you
>from testing your recovery.
>
>(2) They are CERTIFYING that all code sent to you by the application vendor
>will run flawlessly with your paticular combination of hardware and
>software.
>
>(3) They are CERTIFYING that any patches sent to you by the database vendor
>will work flawlessly.
>
>(4) They are CERTIFYING that any patches sent to you by the operating
>system
>vendor will work flawlessly.
>
>(5) They are CERTIFYING that they will never need to upgrade any software
>on
>the production server, or if they do, that any and all software upgrades
>that you perform will be flawless and will never need to be tested first.
>Let them ponder for a while about what will happen when the vendor sells
>them the latest and greatest upgrade and it does not work in your system.
>You will have to take the server offline for an indeterminate period to
>roll
>everything back, assuming your untested recovery will work!
>
>(6) They are CERTIFYING that they will never require any development or
>customization of the software on the server, or if they DO need
>development,
>they are CERTIFYING that ANY development that occurs will NEVER compromise
>the integrity of the production data.
>
>(7) They are CERTIFYING that if any of the above is not true, you will be
>able to hack the prodcucion server until you find out what is true.
>
>If you inform the world via email (nicely, of course, not CAPITALIZATING
>everything IN SIGHT), they might begin to discover that it is in their
>personal best interest to get you a dev server and keep you away from prod!
>
>And if not, find a real shop where they understand the necessity of such
>things, not a place where they are cheap and/or not in the know.
>
>And now I can fairly say that I have had my say today!
>
>:)
>
>Jack Silvey
>ocp x 2
>Senior @ xol.com
>
>
>-----Original Message-----
>Sent: Thursday, June 22, 2000 4:31 PM
>To: Multiple recipients of list ORACLE-L
>
>
>David,
>
>If you don't have test databases, where are the developers doing their
>development and testing. I'm cringing here, waiting for you to say "in
>production".... then I'll scream.
>
>You need to document to your management the possible problems. NOW. And be
>prepared to fight over this.
>
>Rachel
>
>
> >From: "David Lee" <dba_lee_at_HOTMAIL.COM>
> >Reply-To: ORACLE-L_at_fatcity.com
> >To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> >Subject: PROD without TEST
> >Date: Thu, 22 Jun 2000 11:25:22 -0800
> >
> >Hi All,
> >This is more of a survey than a question, but how many of you DBAs out
> >there who are administering production databases that don't have a test
> >database to go with it?
> >We are a new but rapidly changing shop and we have a bunch of small
> >to medium size databases that are running without a test database. This
> >makes DBA tasks like upgrade more difficult. I am having a hard time
>trying
> >to get the management to allocate the resources for this. I wonder how
> >other
> >DBAs are doing to deal with situations like this.
> >
> >TIA
> >
> >David
> >________________________________________________________________________
> >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> >
> >--
> >Author: David Lee
> > INET: dba_lee_at_hotmail.com
> >
> >Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> >San Diego, California -- Public Internet access / Mailing Lists
> >--------------------------------------------------------------------
> >To REMOVE yourself from this mailing list, send an E-Mail message
> >to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> >the message BODY, include a line containing: UNSUB ORACLE-L
> >(or the name of mailing list you want to be removed from). You may
> >also send the HELP command for other information (like subscribing).
>
>________________________________________________________________________
>Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
>--
>Author: Rachel Carmichael
> INET: carmichr_at_hotmail.com
>
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
>--------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
>--
>Author: Jack Silvey
> INET: JSilvey_at_XOL.com
>
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
>--------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
Received on Fri Jun 23 2000 - 10:24:11 CDT