
146
|
第
9
章
试效率和生产现实性之间取得适当的平衡,要考虑测试可能的恢复方案。
还需要考虑各类利基测试场景,在这些情况下,恢复工作开展十分艰难。例如,在
Google
,
我们在一系列不同环境下实现了一种密码密钥管理协议:
ARM
和
x86 CPU
、
UEFI
和
bare-
metal
固件、
Microsoft
Visual C++ (MSVC)
、
Clang
、
GCC
编译器等。我们了解到,即便在端
到端测试上投入大量资金,模拟这一功能逻辑所有的故障模式也颇具挑战性。这是因为硬
件故障或中断的通信很难真实地模拟。相反,我们选择以一种可移植、与编译器和位宽度
无关的方式来实现核心逻辑。我们对逻辑进行了广泛的单元测试,特别留意了针对外部组
件的接口设计进行抽象。例如,为了伪造单个组件并模拟它们的故障行为,我们创建了分
别用于从
flash
闪存读取并写入字节
、加密密钥存储空间以及性能监控原语的接口。由于能
明确地捕获想要恢复的故障类别,测试环境条件的方法经受住了时间的考验。
最后,通过持续验证寻找方法来建立对恢复方法的信心。恢复涉及人工操作,但人为因素
是不可靠且不可预测的。仅靠单元测试,甚至是持续集成
/
交付
/
部署
,都无法捕获人工
技能或习惯产生的错误。例如,除了验证恢复工作流的有效性和互操作性外,还必须验证
恢复指引的可读性和易理解性。
9.3
紧急访问
本章中描述的恢复方法依赖响应者对系统的交互操作熟练度,也倡议在恢复过程中使用与
正常操作相同的主要服务。但为了能在正常访问方法完全中断时进行部署,还需要设计一
款特殊用途的解决方案。 ...