本文主要是介绍第七篇：稳定性之提升团队潜意识【提前预防、裕度设计】，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
提前预防
提前预防是告诉我们从失败中学习，防止同样的故障再次发生，海因里希法则告诉我们，一次重大事故的背后必然有一百次未遂事件和几十次轻度损失。这个法则对于我们有两个启示：一是事故的发生必然有其关联起因和先发信号；二是事故发生前一定有足够的提示，我们要及时遏制苗头，防患于未然。
从失败中学习吸取经验教训，例如每次出现事故，都需要对事故进行复盘，分析和总结事故原因，包括事故处理过程，包括后期的改进措施，海因里希法则，通过本次事故发现其他可能存在的隐患，而非针对此次事故。
例如：数据库慢SQL，拖垮数据库CPU，从而导致应用程序无法为用户提供服务，那么针对此事故，可改进进行复盘，及后期改进措施，如下：
- 对此次事故分析，是否有索引，如果没有，为何没有创建索引？
- 创建索引，索引使用是否合理，如何评估？
- 数据库建表或者查询等数据库设计规约是否强调索引创建意识？
- 是否还有其他的慢SQL？
- 如何通过手段或工具提前预防慢SQL？
- 表结构设计是否合理？该如何评估？
上述是针对慢SQL事故进行复盘，及同类问题拷问，只有想清楚这些问题，并解决掉之后才可能避免风险，出现事故。
提前预防是某种意义也是一种面向失败设计，更多考虑当出现异常情况时，程序或者系统该如何为用户服务，例如：在对某接口设计过程中，对第三方接口依赖失败，考虑该依赖是否强弱依赖，可以解耦，一旦失败是否有预案，或者补救措施，是否考虑可以增加Redis缓存，如果此次失败，可以沿用上次结果，再或缓存失败，又该如何，是否本地缓存（LocalCache）等等很多案例，再例如：服务建议部署N+1来确保服务的高可用，防止单节点出现故障。
小结
每个研发人员都需要有提前预防这方面的意识，架构设计或者稳定性建设，都需要提前预防，我认为提前预防有两方面，一是从失败中学习，学习并吸取历史事故的经验，预防事故发生，二是面向失败设计，提前预知失败，从而提升程序的鲁棒性，提前预防，防患于未然。
裕度设计
在工程实践中，系统的稳定性是最重要的性能指标。正常运行系统的负载大小波动、环境条件改变等许多因素都会改变系统的工作点，即系统的参数会变化。一个可靠的系统，必须保证在参数可能的变化范围内都是稳定的。稳定裕度：表示系统在设计的工作点(设计参数)运行时，到系统处于临界稳定的距离(余地)。通俗的来讲就是设计过程中考虑到各种因素，故意多设计出的一部分，设计时留点余量，预防突发流量从而给系统带来隐患。
一般在做架构设计或者容量评估是估算出最终的结果之后，预留出30%资源，原因是不论是数据库还是服务器或其他资源，是不允许资源被打满，试下：CPU或者系统负载过高，那么一旦某台服务器过高，可能导致阻塞，阻塞一台机器之后，那么就会出现雪崩事件。
小结
裕度设计是告诉我们架构设计或者容量评估时，预留出30%资源，防止线上资源负载过高，跑到极限，从而引发雪崩现象，裕度设计和冗余设计是有一定的区别的，裕度设计是针对单服务或者单资源设计时，要预留出一定的资源，防止单体资源负载过高，跑到极限，而冗余设计是在单服务或单资源之外的设计，为了高可用预备，防止单机挂掉，无法提供服务。
这篇关于第七篇：稳定性之提升团队潜意识【提前预防、裕度设计】的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
