,
"测试”的预案和流程应该涉及到架构中所有的元素,任何刻意避开的元素,说明存在一定的风险,也不要试图省略最简单元素的“测试”,任何意想不到的情况总会在“测试”中出现,而我们心中也要清楚,“测试”中出现任何不在预案中的意外情况都是我们乐于看到的,这给予了我们补救的机会。
,
在允许的情况下邀请其他部门或者是“门外汉”制定“测试”的案例,实施“测试”时,“破坏者”和“恢复者”最好是不同的人。
,
需要问的问题:当一个元素出现问题时,架构的运行情况是怎样?当两个不同类型元素出现问题时,架构的运行情况是怎样?当N个不同类型元素出现问题时呢?任何的单位元素都有热备份或冷备份吗?备份的周期是多少,恢复时间是多久?如出现本地人员不能解决的问题,可联系的支持是谁,多久可以到场?内部有运维处理流程预案吗?等等,等等。
,
从上到下的风险意识,如都能在“测试”中体现,这是最好不过的事情,软硬件投资都以“测试”的效果作为其中一个考量角度。
2011年写的一个小文,搬到这里。
