(资料图片仅供参考)

1.系统“应该”做什么

1.1.添加所需特性

2.系统“不应该”做什么

2.1.崩溃

2.2.停止响应

2.3.丢失数据

2.4.侵犯隐私

2.5.损失金钱

2.6.摧毁公司

2.7.“杀死”客户

3.QA部门的测试

3.1.团队的大部分工作是想方设法地通过测试

3.2.做了敏捷、务实和自动化的测试，也不足以证明软件已经为面对现实世界准备就绪

3.3.仅通过QA测试并不能证明系统在未来3～10年的适用性

3.4.几天甚至几周的测试，不可能说明系统未来几年会怎样

3.5.项目团队的目标往往是通过QA部门的测试，而不是通过生产环境的生存考验

4.软件行业的“可制造性设计”

4.1.为生产环境而设计

4.1.1.以低成本和高质量的方式进行运维工作

4.2.忙碌的软件开发项目中，很容易做出优化开发成本而忽视运维成本的决策

4.2.1.运维时间远远超过开发时间

4.2.2.为了节省一次性的开发成本，却耗费无尽的运维成本，这样做没有意义

5.计划再周详，仍会出状况

5.1.误以为自己已经预见和消除了所有可能的不良事件并能万事大吉，这是最要命的

5.2.要采取行动以预防那些能够预防的事情

5.3.要确保系统在整体上能够从任何未曾预料到的重创中恢复过来

6.缺陷的容忍度

6.1.随着用户的增加和系统规模的扩大，系统遭到破坏的方式也会翻新，环境会变得更加恶劣，人们对缺陷的容忍度会变得更低

6.2.把适用于小型WordPress网站的设计，应用于大规模的分布式事务系统时，会出现重大系统故障

7.早期决策会对系统的最终形态产生巨大的影响

7.1.早期决策恰恰是在信息最不完备的时候做出的

7.1.1.团队在启动项目时，往往最不了解软件的最终架构

7.2.虽然不同的设计方案通常具有相近的实施成本，但这些方案在整个软件生命周期中的总成本截然不同

7.3.在选择时，必须着眼于实施成本和下游成本，从技术和财务的视角综合看问题

7.3.1.投资5万美元来创建不停机发布的构建流水线和部署过程

7.3.2.至少可以避免100万美元的损失，而且大有可能提高系统部署频率，占领更多市场份额，但是目前阶段的直接收益尚不足以体现

8.设计务实的架构

8.1.对系统更高层次的抽象，以便于跨平台移植，并且基本不会与诸如硬件、网络、电子和光子这些难以处理的细节产生联系

8.1.1.当系统崩溃时，用户会为此欢呼，因为至少他们可以有一段时间不必使用它了

8.2.务实的架构师更可能讨论诸如内存使用情况、CPU的需求、带宽的需求，以及超线程和CPU绑定的优缺点等问题

8.2.1.其中每个组件都足以满足当前的负荷

8.2.2.当负荷随着时间的推移发生变化时，架构师知道要替换哪些组件

8.3.以产品化为归宿

8.3.1.软件、硬件和用户三者之间至关重要的交集

8.3.2.当系统最终发布时，架构师、用户和公司都将会更加快乐

关键词：