失去一台设备，仍有一个支点。
我把设备看作可能损坏或遗失的东西。恢复需要设备之外的独立支点，也需要在慌乱时仍能照着执行的清晰说明。
我会问：只靠这台设备之外的东西，我能从哪里开始？
原则
设计之初，
就留好归路。
我的设计取向是接受可控的损失，并保留恢复能力，而不是不惜一切代价留住所有东西。
RESILIENCE FIRST
选择一个情境
一部分停下，其余仍有出路。
我会区分继续工作所必需的部分，以及可以稍后重建的部分。分开依赖关系，才能让小故障有机会停留在小范围内。
我会问：什么必须先恢复，什么可以等一等？
增加便利，也保留选择。
采用一项服务前，我既看入口，也看出口：数据能否取回、配置能否交接、放弃这个工具会不会带走核心？
我会问：如果明天不再使用这个工具，还有什么属于自己？
回来的路
- 独立的支点
- 恢复核心
- 继续工作
探索系统
四个层次，四种优先级。
我区分恢复的基础、运行的核心，以及可以重建的部分。选择一个层次，了解它的作用。
恢复的支点。
基础身份与所有权需要独立的恢复路径。我让这一层保持精简，尽量减少对可能变化的服务的依赖。
身份 / 所有权 / 支点运行所需的核心。
让日常工作得以进行的部分，需要保护，也需要从外部恢复的路径。唯一的钥匙不应放在它所开启的盒子里。
访问 / 配置 / 恢复可以重建的基础设施。
域名、服务和连接构成系统的延伸。我明确依赖关系与恢复路径，让这里的故障不必拖垮基础。
基础设施 / 依赖 / 替换可以放下的工具。
应用和便利功能应该让工作更轻松。我让核心与数据保持足够独立，以便在工具不再适合时更换或放弃它。
工具 / 尝试 / 选择从初次沟通到交付
- 01
背景
理解使用者、限制和目的。
- 02
结构
梳理核心部分与依赖关系。
- 03
构建与检查
通过可检查的小步骤推进。
- 04
保留退路
记录、交接并维护恢复能力。
好的系统，为人的失误留有余地。
01 / 独立的支点
恢复路径需要存在于被恢复对象之外。我避免这样的循环：打开 A 需要 B，而打开 B 又需要 A。
02 / 不同部分，不同优先级
我用 ROOT、CORE、BRANCH 和 LEAF 来判断应该先保留什么。这是我思考设计的方式，并非适用于所有人的统一安全标准。
03 / 能够实际执行的恢复
数据存放在另一处，与真正能够取回数据，是两回事。可靠的恢复路径需要清晰说明，也需要在适当条件下验证。
04 / 分步改变
我倾向于一次改变一个部分，保留已知可用的状态，并在继续之前检查结果。情况不明时，我先弄清还有什么可以依靠。
保留关键，容许失误，知道回来的路。