标准的“主备倒换测试和破坏性测试”（后简称测试），以每季度/半年做一次为准。
“测试”是检验架构设计安全性、有效性、可维护性，以及人员配备是否完整有效的最好演习。
“测试”的预案和流程应该涉及到架构中所有的元素，任何刻意避开的元素，说明存在一定的风险，也不要试图省略最简单元素的“测试”，任何意想不到的情况总会在“测试”中出现，而我们心中也要清楚，“测试”中出现任何不在预案中的意外情况都是我们乐于看到的，这给予了我们补救的机会。
在允许的情况下邀请其他部门或者是“门外汉”制定“测试”的案例，实施“测试”时，“破坏者”和“恢复者”最好是不同的人。
需要问的问题：当一个元素出现问题时，架构的运行情况是怎样？当两个不同类型元素出现问题时，架构的运行情况是怎样？当N个不同类型元素出现问题时呢？任何的单位元素都有热备份或冷备份吗？备份的周期是多少，恢复时间是多久？如出现本地人员不能解决的问题，可联系的支持是谁，多久可以到场？内部有运维处理流程预案吗？等等，等等。
从上到下的风险意识，如都能在“测试”中体现，这是最好不过的事情，软硬件投资都以“测试”的效果作为其中一个考量角度。
2011年写的一个小文，搬到这里。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
