A lire sur: http://www.infoworld.com/d/data-explosion/7-simple-rules-better-systems-testing-227834
October 01, 2013
Whether you're testing DR procedures or double-checking backups, these tips help you get the most out of those tests
Generally
speaking, you should never expect anything you don't test regularly to
work properly. This is true across all kinds of technologies, but the
need for regular testing is often overlooked. Would you expect a car you
parked in a barn two years ago to start today? If it did, you'd feel
lucky. IT systems are no different. You shouldn't count on a successful
site failover, to take one important example, if you haven't tested or
maintained the systems that make it work.
As critical as testing is, it's often overlooked in favor of the never-ending backlog of seemingly more critical tasks. Forgoing testing completely is obviously dangerous, but it's also dangerous to test your systems in ways that don't meaningfully reflect how the systems would be used when they are really needed. Here are seven things you can do to make your testing count -- and to ensure that the confidence you have in your systems and procedures is well founded.
Testing rule No. 1: Perform real-world tests
The very first step to take is to ensure your tests are as close to real-world circumstances as possible. For example, if you're attempting to test your capability to perform a site failover, be sure to completely isolate yourself from the primary site just as if it has been rendered completely inaccessible. You may find that certain parts of your procedures (such as passwords or the procedures themselves!) are either located in or depend upon things at the primary site.
The best way to do this is by staging a test at a time when the production environment can be disabled for the purpose, but few of us have user communities and management that will support that idea. Instead, you will probably need to invest some time in being absolutely sure you're not depending upon the functionality of the infrastructure or services you might be trying to recover.
Testing rule No. 2: Include the human element
Similarly, it's also crucial to involve the human element in your tests. It's one thing to make sure all the systems work, but what about the people? Do they remember what they need to do? Do they know where critical documentation is located and how to get to it? Will they recognize an emergency and react the way you hope they will?
Because most things you'll want to test are responses to unexpected events, it's often eye opening to try to perform the tests when the people responsible for carrying them out don't expect them. You'll learn about your staff's response time and ability to carry out procedures without guidance that could end up being just as important as what you'll learn about the systems you're testing.
As critical as testing is, it's often overlooked in favor of the never-ending backlog of seemingly more critical tasks. Forgoing testing completely is obviously dangerous, but it's also dangerous to test your systems in ways that don't meaningfully reflect how the systems would be used when they are really needed. Here are seven things you can do to make your testing count -- and to ensure that the confidence you have in your systems and procedures is well founded.
Testing rule No. 1: Perform real-world tests
The very first step to take is to ensure your tests are as close to real-world circumstances as possible. For example, if you're attempting to test your capability to perform a site failover, be sure to completely isolate yourself from the primary site just as if it has been rendered completely inaccessible. You may find that certain parts of your procedures (such as passwords or the procedures themselves!) are either located in or depend upon things at the primary site.
The best way to do this is by staging a test at a time when the production environment can be disabled for the purpose, but few of us have user communities and management that will support that idea. Instead, you will probably need to invest some time in being absolutely sure you're not depending upon the functionality of the infrastructure or services you might be trying to recover.
Testing rule No. 2: Include the human element
Similarly, it's also crucial to involve the human element in your tests. It's one thing to make sure all the systems work, but what about the people? Do they remember what they need to do? Do they know where critical documentation is located and how to get to it? Will they recognize an emergency and react the way you hope they will?
Because most things you'll want to test are responses to unexpected events, it's often eye opening to try to perform the tests when the people responsible for carrying them out don't expect them. You'll learn about your staff's response time and ability to carry out procedures without guidance that could end up being just as important as what you'll learn about the systems you're testing.
Aucun commentaire:
Enregistrer un commentaire