| 2022-02-01
没有 CEO 会在不了解收入、流失率或烧钱率的情况下，还能够经营自己管理的公司。但在「 move fast 」的竞争里，当市场发生变化时，他要能立即推出一个产品更新（就像之前一样）。如果速度足够快，他就可以利用这些很小（通常以小时为单位）的变化，就能在任何无法快速调整的竞争对手面前，获得关键的市场份额。
为了最大限度地提高速度，CEO 们应该考虑一些「非传统」的指标，比如变更前置时间（ commit-to-deploy time ）、构建时间（ build time ）、排队时间（ queue time ）和测试覆盖率（ test coverage ）。
这些指标可以让CEO们更清晰地了解他们的软件开发的路线轨迹，以及可能阻碍他们前进的因素。
但是，在了解这些指标含意之前，需要记得下而五个重要事项。
研发效能度量中最重要的事情
- 研发效能度量是需要结合上下文的。
- 研发效能度量是有成本的。
- 仅有度量数据是不能产生改善的。
- 度量数据自身的质量本身也是非常关键的。
- 度量（即便不考核）会带来人的行为改变，这种改变可向「好」，也可向「坏」。
变更前置时间 「 Commit-to-Deploy Time ( CDT ) 」
变更前置时间是指：一次代码变更从提交到部署所需的时间。在这两点之间，它可能会经历集成、测试和预生产测试，当然，具体经历哪几个阶段取决于你的组织流程。测量 CDT 的目的是了解代码从部署流水线的一端到另一端需要多长时间，以及遇到了哪些障碍（如果有的话）。
在理想情况下，如果您已经实现了持续集成（CI）最佳实践，并且您有足够的自动化测试覆盖率，你可以在几分钟完成从提交到部署就绪的状态。假如恰巧系统是微服务架构，甚至几秒钟内完成这一过程。但是，如果你的整个过程中在很大程度上是依赖于手工验证的过程，这很可能意味着这一部署时间会长一些，也意味着你的组织流程还有改进空间。
大多数快速发展（ fast-moving ）的组织（如 Facebook 、亚马逊）每天部署数百次。对于较小的组织来说，「每日部署」是一个很好的目标。你每个提交的变更越小，它们投入到生产环境的速度就越快。一旦发现它们出错了，修复的速度也就越快……总有出错的时候。更频繁的部署也会让你的团队习惯于这么做，这也可能让团队会做得更好更快。
那么，如何测量 CDT 呢？使用「时间戳」。对于每一次通过代码审查并合入的代码变更提交，记录它发生的时间。使用 git 意味着您可以免费获得这种粒度的变更信息。在部署方面，你也会做同样的事情————注意：部署意味着你的用户可以看到或使用它。「平均前置时间 CDT 」实际上取决于应用程序的大小和复杂性。但是，「少即是多」，所以你需要尽可能做一些改进来缩短这个时间。这些改进可能更多是在技术方面的的改进（例如，我们的测试是不稳定的），或者是面向过程（例如，我们在应该使用单元测试的时候却使用了更为复杂的集成测试），或者技术或流程这二者的某种组合。无论如何，您的目标应该是逐步提高变更前置时间。
构建时间 （ Build Time ）
浪费时间最糟糕的情况之一（但有些不可避免）是 SRE 工程师和开发人员坐在一起等待测试完成。这些测试工作的规模越大、内容越全面，花费的时间就越长。无论你把这些测试工作堆得有多高，你只能看着高薪员工在那里被微博或朋友圈，或者无聊的GIF分散注意力，而不是设计或编码。
让我们看看成本：如果有两个开发人员在等待测试，他们每小时都要支付50元（每年约10万元），那么10分钟的构建时间将使您损失大约17元的生产率。虽然缩短这10分钟似乎是一个很蠢的改变，但如果每个开发人员每天运行五次这种类似的测试工作，那么每周总计833元（每年43000元）。在更大的背景下，有些测试很可能需要一个小时才能执行。除了这些明显的直接成本外，还有难以量化的「丧失机会」的成本，即：不能更快地进入市场的成本，以及开发人员等待、然后跳回开发的心理「转换成本」。
构建时间实际上包括测试的运行，以及运行这些测试所需的任何准备工作。这些准备工作包括创建一个测试数据库，在该数据库中植入测试数据，以及在测试套件之间设置/拆除数据库，这样就不会污染数据。
和 CDT 一样，「好」的构建时间取决于上下文，但这个时间几乎总是越短越好的。将相关测试放在一起可以防止不必要的设置环节和拆卸环节。「CI 最佳实践」还建议首先运行那些运行比较快的测试，并且一旦有错误出现，尽快发现它们，并取消构建，马上修复它们。
排队时间（ Queue Time）
比构建时间更微妙的是，工程师在构建执行之前的等待时间。这个指标高度依赖于组织的规模，以及同时并行开发的特性的数量。讽刺的是，在每次提交时运行构建，这恰恰是开发人员应该做的事情，这可能会进一步加剧这种情况。
但是的长时间排队，成本是非常昂贵的。虽然开发人员可以在另一个项目上工作，但这也冒着失去刚刚所编功能的需求上下文的风险。
如果他们并没有将注意力转到下一个工作项目上，而是将注意力集中在等待测试的这次变更上，那么，比构建时间更糟糕的是，如果工程师因为发现测试失败而中断了这次构建，这就让“最大构建时间”缩短；而排队时间不允许这样的捷径。
对于每一个要被测试的变更，应跟踪它从队列尾到队列头部所需的时间。这可以简单到让工程师记录他们在构建开始执行之前等待的时间。
保持较低的排队时间，让工程师的工作可以持续吧～
主干变红的频率（ How Often Master Is Red ）
开发人员使用「主干分支」作为所有新工作的起点。这是真相的主要来源，所以如果它变成「红色」，就意味着每个人都陷入了困境，因为没人能发布代码，整个部署流水线嘎然而止。假如变红时，恰好有人要发布一个密钥安全修复的代码变更，他们不得不等到主干被修复。
在很多组织中，如果主干上的代码出现故障，可能需要几个小时才能修复。这不是你想看到的情景。如果组织不关注尽快修复红色的主干，这表明了以下几点：
- 如果你的测试套件不稳定或者测试不可靠，主干就很容易会变红。
- 代码库的测试覆盖率也会影响主代码变红的可能性：不良的测试覆盖率会导致构建失败。
- 长期存在的特性分支很可能会以因最后的合并冲突而失败。变更集越大，你的代码就与其它地方的代码差异越大。帮助避免这种情况的一个 CI/CI 原则就是：每次提交少量变更，而不是进行「大爆炸式」的合并。
让主干处于不好的状态也可能仅仅表明了开发实践或开发文化不好。你的组织可能没有足够的紧迫感，在第一时间修复主干——这个「真北之源」。当主干变红时，它为代码提交造成了瓶颈，让修复时间变长，而且让开发延迟了。
持续交付的一个原则是强调始终保持软件「绿色」，即：软件一直处于可部署状态。如果它不是绿色的，你在它坏掉的那一刻就应该修复它，而不是让它流连忘返。无论谁破坏了它，都应该全心专注于修复这个问题，如果需要，还可以从其他团队成员那里获得帮助。这与看板方法中的「红色按钮」有些相关：任何人都可以而且应该在发现缺陷时按下红色按钮，以便尽快修复问题。也就是说，一旦按下红色按钮，每个人都需要尽快让「装配线」再次启动。
你如何衡量这个呢？ 每次主干变红时，启动一个累积计时器。将这个数字除以今年迄今为止的剩余时间。这是主干花费在「红色」的时间百分比。要获得更详细的信息，您可以按月或按天细分。或者：计算从红色回到绿色的平均时间。 这应该不超过一个小时。
让主干保持绿色就是为了防止瓶颈和保持公司的敏捷性。
工程开销（ Engineering Overhead ）
工程开销包括员工人数，以及在一些花费，如购买的 License 和 AWS 等，当然，也包括工具的维护成本。虽然很多 CEO 会跟踪每个席位的工具成本，但他们并不关注配置、维护或监控这些工具需要多少时间。你的工程团队中是否有人主要负责维护每个人都使用的工具？工程师在这种类型的流程工作上花费了多少小时而不是构建功能？
如果一个工具需要一直花费大量时间和精力才能发挥期功能，你可能需要重新评估它的价值。工程师花在工具上的时间减少了他们花在产品上的时间。工程师希望使用最好的工具：不要以牺牲基础设施或工具的质量为借口。
其它指标
以上就是 CEO 应该知道的五个较大的非传统指标，但为了确保他们保持竞争力，还应该回答以下几个问题：
- 开发人员每天向主干合并多少次？
- 代码库多久处于可发布状态？
- 代码测试测试覆盖率是多少？
- 是否优化了我的工具和基础设施？
- 通过替代工具（基础设施解决方案）的潜在速度增益和节省是什么？