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

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

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

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

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

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

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


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

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

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

#geektime

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

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

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

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

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

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

https://dropbox.tech/infrastructure/how-we-migrated-dropbox-from-nginx-to-envoy Dropbox是如何从Nginx迁移到Envoy的 Nginx应该是没办法满足中大型公司的需求和灵活性，越来越多的公司开始迁移到Envoy这种动态配置为主的HTTP服务器。Dropbox这里对比了内部两种服务运维的差别以及特性。另外，文章说xDS APIs已经成为事实标准，也是另一个关注的理由。