我们担心这样的症状：

• 故障定位慢：线上出了bug，要花很长时间才能定位出问题的代码以及对应的开发者。
• 获得真实反馈慢：代码写完了要等苹果审核发版，错过了这个版本又要等一个月公司才会发下个版本。
• 本地测试难：稍微有点价值的测试都不是本地可以用 JUnit 写出来的。
• 听不见炮火：管你前线洪水滔天，我这后台模块是管不着的

Feedback 的愿景是尽量减少获得反馈的摩檫力。业务逻辑拆分为什么会影响到 Feedback 呢？这仍然是要归结为人的沟通效率问题。能用标准化的方式解决的，就可以减少沟通。能尽量减少信息传递次数的，就可以有效减少传递过程中的信息衰减。

度量指标包括：

工单流转时长

企业的外部用户创建的工单，如果最终发现需要开发来处置，到转到对应的开发手里。这个从工单创建时间，到开发开始处置的时间差，就是工单流转延迟。 度量这个指标主要是为了避免后台模块缺乏对企业最终用户的体验缺乏同情心，减少中间的层次。 这里工单指的是偶发的个案。对于大面积故障造成的工单，一天之内的工单合并为记录为一条。也就是数据采样的时候，一天只抽取一条工单纳入指标。

故障定位时长

孤立的一个进程很难完成所有工作。业务逻辑不可避免地要拆分成多个进程。如何找到出问题的进程。 一个进程也很难仅由一个 Git 仓库构建而来。业务逻辑不可避免地要拆分成多个 Git 仓库。如何找到进程的问题是哪个 Git 仓库造成的。 故障定位延迟是指故障从开始定位，到找到根本原因所花的时间。进程边界，Git 仓库的边界，越不依赖人的经验，越不依赖人的现场沟通，就越可能降低故障定位延迟。

代码集成时长

从修改一行代码，到把这行代码修改和其他进程集成到一起，用真实流量验证，这个端到端的延迟是多少。 开发自己的笔记本能把所有的进程都能启动起来是一种办法。 开发能用单元测试模拟试也是一种办法。 每个小时上一次线也是一种办法。 只要能对刚才改的那行代码，集成起来不出问题有信心就可以。 所以我们没有把“本地开发环境设置时间”做为一个指标，因为能够本地启动进程是手段，而集成到一起测才是实际目的。