50 lines
2.1 KiB
Markdown
50 lines
2.1 KiB
Markdown
|
# 第九章 简单化
|
|||
|
|
|
|||
|
|
可靠性只有靠对最大程度的简化不断追求而得到。 ---- C.A.R.Hoare, Turing Award lecture
|
|||
|
|
|
|||
|
|
软件系统本质上是动态和不稳定的。SRE的工作室在系统的灵活和稳定性上维持平衡。
|
|||
|
|
|
|||
|
|
## 系统的灵活性与稳定性
|
|||
|
|
|
|||
|
|
有时候为灵活性而牺牲稳定性是有意义的。
|
|||
|
|
|
|||
|
|
SRE通过创造流程、实践以及工具来提高软件的可靠性，同时SER需要最小化这些工作对于开发人员灵活性造成的影响。
|
|||
|
|
|
|||
|
|
## 乏味是一种美德
|
|||
|
|
|
|||
|
|
我们不想要自发性和有趣的程序，我们希望这些程序按设计执行，可以预见性的完成商业目标。
|
|||
|
|
|
|||
|
|
关注必要复杂度和意外复杂度之间的区别非常关键，必要复杂度是一个给定情况所固有的复杂度，不能从该问题的定义中移除；意外复杂度是不固定的，可以通过工程上的努力来解决。
|
|||
|
|
|
|||
|
|
为最小化意外复杂度，SRE团队应该：
|
|||
|
|
|
|||
|
|
- 在他们所负责的系统中引入意外复杂度时，及时提出抗议
|
|||
|
|
|
|||
|
|
- 不断努力消除正在接手的和已经负责运维的系统的复杂度
|
|||
|
|
|
|||
|
|
## 我绝不放弃我的代码
|
|||
|
|
|
|||
|
|
SRE推崇保证所有的代码都有必须存在的目的的实践。
|
|||
|
|
|
|||
|
|
## 负代码行作为一个指标
|
|||
|
|
|
|||
|
|
添加到项目中的每行代码都可能引入新的缺陷和错误。
|
|||
|
|
较小的项目容易理解，也更容易测试，而且通常缺陷也少。应该按需删除无用的代码。
|
|||
|
|
对于增加新功能的需求，应该持保守态度。
|
|||
|
|
|
|||
|
|
## 最小API
|
|||
|
|
|
|||
|
|
不是在不能添加更多的时候，而是在没有什么可以去掉的时候，才能达到完美。
|
|||
|
|
书写一个明确的，最小的API是管理软件系统管理简单性必要的部分。
|
|||
|
|
|
|||
|
|
## 模块化
|
|||
|
|
|
|||
|
|
在二进制文件之间或二进制文件与配置之间推行松耦合，是一种同时提高开发人员灵活性和系统稳定性的简化模式。
|
|||
|
|
|
|||
|
|
模块化同样适用用分布式系统与数据的设计。
|
|||
|
|
|
|||
|
|
## 发布简单化
|
|||
|
|
|
|||
|
|
简单的发布流程要比复杂的发布流程更好。如果发布是按更小的批次进行的，我们就可以更有信心地进行更快的发布，因为每个变更在系统中的影响都可以独立理解。
|
|||
|
|
|