1.将可靠性要求转化为清晰的可量化指标。可靠性指标需要通俗易懂，有明确的定义和计算方法，不仅要定性还能定量。例如用“延迟xx毫秒” 这样的清晰的量化指标代替“延迟较高或较低”这种感性说法
2.要分析业务系统请求链路面临的负载量和运行环境，确定基础资源需求。例如根据预估的用户数量来计算所需要的入口带宽，服务器资源规格等。
3.要对当前的业务系统性能，成本，和技术条件综合分析。设计系统时成本是重要制约因素，需要衡量投入的成本对可靠性提升有多大，带来的收益能否覆盖成本。同时根据现有技术条件选择成熟的方案，避免引入新的可靠性风险
4.识别业务系统中有可能存在的单点瓶颈或故障，对关键链路上的单点组件应当做冗余处理
5.控制一次迭代中引入的模块和组件的数量。这点很好理解，做的越多，出错的概率越多，排查起来越困难。
6.对可能过载的模块进行降级、限流、熔断设计。 例如一些网站的节日大促活动，或者突发性流量可能会导致网络拥塞、响应缓慢、拒绝服务，更严重的会耗尽服务器资源，导致其他的服务无法访问。所以要对这些情况做预案，对流量进行降级限流，必要的时候切断访问通道。
7.对业务系统的关键可靠性指标设计监控能力。监控是我们获取可靠性指标的最核心手段
8.对业务系统缺陷制定应急预案。目前国内公司这种情况很常见，比如一个业务系统开发了若干年，开发人员换了几茬，埋坑无数，产生了一些修复困难度极高的缺陷。这些历史原因造成的缺陷问题只能在事前做一些应急方案来规避，等到真出问题时执行预案即可
9.尽早做可靠性设计。越早设计，后期维护压力越低
10.可靠性目标要渐进式提高。因为架构是持续演进的，新技术不断涌现。没必要一次性把目标定的太高，这样不仅实现困难，而且成本也可能超支。也许现在出现的可靠性难题将来通过一些简单的开源组件就能解决。现在投入资源研发的可靠性工具链也许在将来的新架构中毫无作用。因此制定可靠性目标要脚踏实地，同时做一些前瞻性的研究，避免资源浪费
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。