Most of us have three environments in our organizations: Development, Staging, and Production. But I don’t count Staging as a test system. Sure, I use it to do an integration test for code before it goes to the users, but that’s not the only kind of testing I do. I install management and performance software, I run script routines and so on, and I need a place to check that just before I do anything on my "real" systems.
I’ll point out software links on this blog, and you’ll get those from other folks. I’ll give you a script or two as well, and I normally warn you to "try this on a test system first". That’s not an idle comment – you really should try any software or scripts on a completely throw-away system, one you can rebuild if needed with no downtime to production. I’ve had more than one package change a configuration on my test system that would have been quite…unfortunate if it had happened even on my workstation that I use to manage my systems. After all, that workstation is my production system for the job I do all day. Sure, it might not have affected the server (whew), but any downtime on my laptop is downtime to me, and I can’t afford that.
I recommend a Virtual Machine for your testing. It is throwaway, doesn’t affect anyone else, and it has the added advantage of being able to take a "snapshot" of the system before you try that script or install that software. Then if things go all wrong, you can simply revert to the snapshot and Bob’s-your-uncle.
They always say a "word to the wise", but I don’t think the wise need the word, do they? It’s the rest of us that need the warning!