Justifications for a test/development server

Question

At my current workplace, the production SQL server and web servers are also used as development and test servers. I've asked for dedicated servers, but been refused as I can't justify it to satisfaction (the reasons against being cost of software, software licenses and hardware resources).

So, what justifications are there for a dedicated test/development server (a combined server at the moment - I don't want to push my luck and ask for 6 servers!)?

Summarised list

• Resource usage
• Prevention of errors
• DR purposes

The list doesn't seem as extensive as I'd hoped.

Answer 1

Well for starters the potential resources the production database has to use is restricted.

Also rogue/accidental developer SQL scripts could play havock with the production data.

Could there be issues with production data sensitivity? (eg personal data)

just a few to get started :)

Answer 2

Explain how often developer have fat-handed moments and hit enter too soon while editing statements starting...

drop table...

Answer 3

UPDATE veryImportantTable SET veryImportantField = '' WHERE 1 = 1 --TODO: make proper condition

This'd be reason enough for me. :)

I hope you have at least separate databases and are not developing on production data.

Answer 4

Consider using Virtual Machines to reduce costs.

Answer 5

Try to calculate the cost of downtime if you take the production system down due to a mistake in development.

Try also to calculate the cost of slow response times in production if/when you are doing performance testing.

As a cost benefit the test/dev hardware can be used as a spare if something bad happens to the production hardware.

Answer 6

Check the data protection act, and also look into PCI-DSS if you want to be really secure (Payment Card Industry Data Security Standard).

Answer 7

I think it's livable to have a test-database on the same physical machine as your production DB. Performance is often not an issue (and assuming it's a multicore muchas memory machine, even if you do a heavy query on test, production will often not noticably slow down), and so long as the DB connections are separate, the chance of accidental damage is very very low.

As for a web-server, almost any machine can run one of those (apache is free, and even IIS is free for 10 simultaneous connections or fewer) - you could install a test web server on any old machine, configure it to use your test DB, and have a decent, low-cost solution.

'course a separate machine is "cleaner" - but the difference isn't huge.

Answer 8

One strong argument is availability / reduce downtime / disaster recovery.

i.e. to have another machine on standby to replace the production machine should anything bad happen to it hardware-wise (e.g. disk controllers or motherboards or power supplies dying).

Ideally the additional machine should be identical to the production one so it can be swapped directly, or individual parts swapped in as required. They can also back each other up or have a local copy of their counterparts last backup so they can be restored from quickly.

Of course it depends on how critical uptime is to the business as to how much value they'll see it this. If you're able to roughly work out how much they'll lose in $ due to lost business with and without a 'hot spare' server and present your case from a $ saved viewpoint (hopefully a lot more than the cost of the server), they might go for it.