在讲具体的方法之前，我们需要一些数据来做为支撑，建立一个基线，让我们整个目标能够更加聚焦一些。

在软件工程领域，评估一种方法是否能够有效的检测出软件缺陷有一个量化的指标：缺陷清除效率(Defect Removal efficiency, DRE)。

在后面的文章中，我们将质量体系的建立分为三个阶段，一步一步的迭代加强某一个方面，最终建立起我们的整个体系。这么做是有一些内在的理论逻辑的。可能您并不会完全赞成后面某一些阶段的某一些做法，但是读懂这些流程设计的背后逻辑，这样您可以会根据自己的情况测试更适合您的流程。

提高软件质量是一个非常复杂且艰难的过程，需要非常强大的决心和耐性才有可能完成。支撑这些的决心和耐心的前提是要对质量的意义有一个深刻的认识。只有深刻的意识到软件质量对于一团队意味着什么，会带来什么样的收益和价值，才可能坚持得下去。

这一章节就是专门来回答这个问题：质量到底意味着什么？高质量软件的收益是什么？是需要真的花大力气投入么？

一问到怎么提高软件团队的工程质量，我们天然的会蹦出一堆方案。方案审查、代码审查、单元测试、功能测试……。如果将这些事情都做好了，工程质量显然问题不大。但真实情况是，我们大部分团队的资源是有限的。大部分时候，我们都处于疲于奔命、到处救火、各种延期的状态。这些方案审查、代码审查、单元测试听起来很美好，但是真正能够贯彻执行下去的团队，却少之又少… …

The cost of all Azure Cosmos DB database operations is normalized and expressed in terms of Request Units (RUs). RU/s is a rate-based currency, which abstracts the system resources such as CPU, IOPS, and memory that are required.

Azure Cosmos DB requires that specific RU/s are provisioned.
These ensure that sufficient system resources are available for your Azure Cosmos database all the time to meet or exceed the Azure Cosmos DB SLA. It is possible to provision throughput at two distinct granularities: the whole database or individual containers.

In the last weeks multiple of my customers have asked why the official documentation around RUs has changed and there are no longer samples or calculations in it.

I would personally just summarize it like this:

Reality is the only thing that’s real!