带着问题去读源码，最好是带着问题的答案去读源码

了解一个软件的设计可以从三个部分着手：模型、接口和实现。这三者的关系就好比你去看代码，你会先去看有哪些类以及它们之间的关系，这就是看模型；然后你会打开一个具体的类，看它提供了哪些方法，这就相当于看接口；最后，你再来打开一个具体的方法，去看它的代码是怎么写的，这就是看实现。

那 SOLID 原则是什么呢？它实际上是五个设计原则首字母的缩写，它们分别是：
单一职责原则（Single responsibility principle，SRP）
开放封闭原则（Open–closed principle，OCP）
Liskov 替换原则（Liskov substitution principle，LSP）
接口隔离原则（Interface segregation principle，ISP）
依赖倒置原则（Dependency inversion principle，DIP）

OKR 也就是目标与关键成果法，是在硅谷互联网公司很流行的绩效制定方法。简单来说，O 代表目标，也就是我们要做什么，KR 代表关键结果，用于验证我们是否已经达到了目标。

部署频率：指应用和服务向生产环境部署代码的频率。

变更前置时间：指代码从提交到成功运行在生产环境的时长。

服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。

变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例

DevOps 本身也包含了改善软件从业人员的生存状态，提升他们的幸福水平的理念。、

而我们在应对高并发大流量时也会采用类似“抵御洪水”的方案，归纳起来共有三种方法。


Scale-out（横向扩展）：分而治之是一种常见的高并发系统设计方法，采用分布式部署的方式把流量分流开，让每个服务器都承担一部分并发和流量。

缓存：使用缓存来提高系统的性能，就好比用“拓宽河道”的方式抵抗高并发大流量的冲击。

异步：在某些场景下，未处理完成之前我们可以让请求先返回，在数据准备好之后再通知请求方，这样可以在单位时间内处理更多的请求。

#geektime

重流程管控不利于软件交付效能的提升，轻流程管控也不会影响软件交付质量，关键要看公司是否选择一种“更好”的做法来实现管控的目的。 #devops #geektime

公司内部经常会争论是否需要更加严格的审批流程，希望借助严格的审批流程，促使软件交付更加有序和可靠。很多系统和需求在提出的时候，都是以这种思想为指导的。我一直对这种流程的有效性抱有怀疑，加入更多的领导审批环节，除了出问题的时候大家一起“背锅”之外，并没有带来什么增值活动。

不应该将质量依赖于检验工作，因为检验工作既昂贵，又不可靠。最重要的是，检验工作并不直接提升产品质量，只是为了证明质量有缺陷。而正确的做法是将质量内建于整个流程之中，并通过有效的控制手段来证明流程自身的有效性。

质量管理大师爱德华·戴明博士经典的质量管理 14 条原则

内建质量扭转了看待产品质量的根本视角，也就是说，团队所做的一切不是为了验证产品存在问题，而是为了确保产品没有问题。

问题发现得越早，修复成本就越低；质量是每个人的责任，而不是质量团队的责任。