Primary and standby switching testing and destructive testing in operations management

Standard "primary and standby switching testing and Destructive testing" (hereinafter referred to as testing), the quarterly/semi-annual.

Testing is the best exercise for verifying the safety, effectiveness, maintainability, and completeness of the design of the architecture.

The "test" plan and the process should involve all elements of the architecture, any deliberately avoided elements, indicate a certain risk, do not try to omit the simplest elements of the "test", any unexpected situation will always appear in the "Test", and we have to understand, "test" Any unexpected situation that is not in the plan is our pleasure to see, which gives us the opportunity to remedy it.

If allowed to invite other departments or "laymen" to develop "test" cases, the implementation of "testing", "the" "Destruction" and "recovery" is best for different people.

Question to ask: What happens to the schema when a problem occurs with an element? How does the schema work when there are problems with two different types of elements? When there is a problem with n different types of elements? Do any of the unit elements have hot or cold backups? What is the period of backup and how long is the recovery time? If the local people can not solve the problem, who can contact the support is who, how long can be present? Is there an operational process plan for the internal operation? Wait, wait.

From top to bottom risk awareness, such as can be reflected in the "test", this is the best thing, hardware and software investment in the "test" effect as one of the considerations.

A small article written in 2011, moved here.

This article is from the "Beautiful Journey" blog, please make sure to keep this source http://longweijin.blog.51cto.com/3603815/1621892

Primary and standby switching testing and destructive testing in operations management