1.无度量不DevOps

DevOps的推广打破了开发，运维之间的壁垒。全员以产品交付为目标，提高效率，完成业务。久而久之消费者就会形成一个潜意识就是：买了这个产品我们企业就DevOps了。（哇，开香槟，散花~）。真是这样的吗？的确DevOps提供了一个新的视角去审视整个公司的人员配置，业务流程，企业文化。打通信息壁垒后，把以前的信息孤岛变成高速公路。但是不是路通了就可以高枕无忧了？Not Yet，高速路也会堵车啊！所以不知道大家是否想过一个问题，到底怎么样才算DevOps了？你的企业DevOps到什么程度？特别是在微服务，微应用时代，一切都在加快，我们用哪些属性去评价一个产品的核心价值，如何准备把握市场动向并且控制风险？如果你心里还没有答案，那就请听我们对这些问题的解答。

2.DevOps衡量模型GRE

通过GRE理论可以很好的回答上面的问题（DuangDuangDuang敲黑板，作者这里不是要出国考研哦: P）

GRE理论是围绕DevOps生命周期内的核心数据做文章，以软件过程为上下文，通过软件度量这种精确制导武器，向用户展现DevOps系统的业务价值。下面我们将一一阐述这三个维度的内涵。

2.1 维度1：Goal （确立目标）

维度Goal：诸多公司拥有大量的数据，但是数据散落在不同的地方，格式并不统一。你和同事之间的沟通成本也许很高。以前经常头痛花费大量的时间去汇总五花八门，格式不一的数据向领导汇报，比如报告上的3天，到底是自然天还是人天？通过DevOps平台+文化的实施，特别是元数据平台的实施，形成各个部门，各个链路的契约。如果你已经感受到这种好处，那恭喜你！DevOps已经在贵公司开始生根发芽。

2.2 维度2：Redo （执行监控）

维度Redo：当数据的统一消除了信息壁垒后，以前的乡间土路都变成了高速公路，但是修路不是目的，真正的目的是有质有量的提高资源周转效率。当你的下属用“差不多”来回应一件事情的进展状况，你是否想知道自己的业务目标完成了多少？

“持续改进理论”是敏捷方法一直提倡的。开发敏捷提倡以不断迭代的方法完成开发目标，以最少的缺陷，在既定的时间与资源内，完成最多的功能。而DevOps的一个非常重要的贡献就是将企业由传统的开发敏捷向业务敏捷转型。过去比较成熟的软件开发工具能提供的数据仅限于开发与测试领域，与业务目标的联系有比较大的鸿沟。

DevOps的索伦之眼将业务到开发的链路打通，现在可以从企业实际的业务目标出发，发现问题，在业务系统内找到反应这些问题的关键数据。用户可以不断监控过程数据，降低成本，持续改进。如果DevOps成功的帮助贵企业从开发敏捷到业务敏捷转型，那说明DevOps已经融入到您企业日常运转的血液中。

2.3 维度3：Excel （精益预测）

维度Excel：黎叔曾经说过：“21世纪最宝贵的是什么？是人才！”那一个人才的最大价值是什么呢？是经验！作为一个管理者，你是否觉得项目的状态很容易变成一笔糊涂账，往往临近计划结束才知道里程碑无法达成？各位看官，如果已经做到了Goal和Redo，那其实已经在业务领域，以及时间维度内积累了大量的数据。将这些数据连接起来就是趋势，客观数据组成的趋势图是管理者做出判断的可靠依据。

比如说随着时间的发展，我们会看出问题的项目中问题的数目骤增，这时候就需要判断是否要介入来控制事态的发展，以此控制风险。当然那个预警线，什么时候做出，代价最低，需要其他数据积累，分析支持才能够给出：比如同等规模的项目，在计划三分之一处，Bug数量已经大于平均每个功能点5个时进行干预，这样，Bug的回归曲线会在项目结束时达到合理的收敛范围内。当一个企业运用宝贵的经验，在了解现状的基础上，对企业的未来发展做出准确的研判，规避风险，使其立于不败之地，这才是DevOps的最高境界。

3.GRE理论的关键：从开发敏捷到业务敏捷

说了这么多你一定很好奇，一个DevOps平台是如何帮助我完成GRE方法的呢？我们一开始就说了，最重要的是对业务目标的追求。业务目标到各个DevOps生命周期是一个分解的过程。这里举一个例子，业务目标：降低成本。

以上对各个部门提出的问题最终会落实到一个度量点上，而这些度量点最终就是该领域部门使用的业务系统直接或者间接的产出。细心的看官已经看出，其实成本本身就是一个度量值。也就是说度量值是可以分层的，一个度量点可能由众多度量点组成。根据普元对DevOps的实施经验，我们推荐以下全生命周期度量属性：

可以看到，以前和开发时期割裂开来的，真正反映产品业务特征的运维数据被重视起来。而且通过统一的DevOps平台，这些数据可以按照统一的格式，既定的时间自动获得。特别是以前无法被度量的用户感知质量，例如：“用户停留指间”，“功能使用率”等。通过对这些感知质量的度量，可以帮助产品的设计者知晓如何在产品的规划中改进产品，也会帮助产品管理者做出资源配置的正确判断。

对于一个企业的管理者来说，最关心的恐怕就是如何将有限的人力物力投资到最有潜力的产品上，从而获得最大的收益。按照ROI模型，一个理想的产品生命周期大致会经历：孵化->增长->稳定->EOL(End of Lifecycle)四个阶段。在孵化期，企业会对产品的投入较高，但是所获取的利润较少。接下来企业最希望看到的是所投资的产品会被市场接纳，也就是进入投资与盈利双高的增长阶段，这个时期是产品发展的黄金时期，积累口碑，占领市场，获取最大的用户群都在这一时期完成。等待产品功能被一定用户验证之后，产品的开发任务就会保持收敛，更多的是售后支持与维护工作，而前端的销售还会一如既往的拓展新的市场，因此产品会进入投资少而受益高的稳定期。

科技的发展日新月异，不论多么伟大的产品可能都将最终面临被市场淘汰的命运，也就是进入EOL的阶段。值得注意的是，有很多产品都无法完全经历上面四个周期，甚至在孵化期就会被市场淘汰。将DevOps全生命周期的重要度量属性连接起来，提供从业务到开发各种视角的参数，使得管理者能准确把握产品市场定位，在产品发展的每个时期进行资源的合理配置，预测风险促使产品在每个不同象限的过度，懂得取舍保持相对的利润最大化。如果DevOps帮助一个企业做到了这些，就真正的完成了从开发敏捷到业务敏捷的转型。

4.微服务世界中的度量属性

相信大家都会感到，如今软件的开发速度明显的加快了。从物理层角度来看，软件的基础模块功能逐渐被DevOps平台提供的各种成熟的中间服务替代，开发者只需要关心核心的业务，这大大降低了软件开发的复杂度，也加快了进度。从市场需求来看，更加注重用户体验等使得复杂的产品没有了市场。用尽量便捷的步骤以及功能满足用户对大的需求，化整为零。这是微服务，微应用的设计理念。

·     Time to Market：从产品的需求定义到上线的时间。

·        Ratings：用户踩，或者顶的次数。

·        Ranks：级别。

·        User Residence：从用户创建一个应用到销毁的持续时间。

·        User Expansion：用户数变化。

·        Spending：平均用户消费。

·        Response latency：调用一个服务到收到一个回复的时间。

·        Language adoption：不同微服务，不同语言用哪种开发最快。

·        Dev period per function：每个功能平均开发时间。

·        Function hit：每个服务请求，或者点击次数。

·        Deploy Speed：应用部署速度。

·        Crash Times：应用出现错误的次数。

我们更加关注一个应用花费多长时间占领市场，用户对一个应用的直接感知评价，用户对那哪些功能感兴趣，以及通过用户对一个应用实际的停留时间判断产品对市场是否有价值。可以看到微服务世界中的核心度量更加敏捷，也更加贴近用户第一手的使用感受，使得度量对产品的衡量更加准确，体现业务价值。

5.基于GRE模型的质量反馈系统

根据前面描述的度量理念，我们以微服务架构设计了普元的DevOps 质量反馈系统（QAF：QualityAssurance Feedback），这个系统的设计目标是通过建立统一的数据度量体系，提供动态以及可追溯的全领域洞察能力。通过QAF，用户可以按照统一的模型对数据进行访问（实现Goal度）；实时掌握，监控在制品的生产情况（Redo维度）；还能查看历史数据，查看问题发展的趋势，甚至根据分析模型预测某些问题的发展状况（Excel维度）。

QAF的数据分为三类，第一类是直接通过RESTAPI来访问数据源，获取的原始业务数据。第二类是利用Data ETL抽取数据，在经过数据清洗后放入数据仓库中形成行星架构（Star Schema）。第三类是在前两种的基础上，按照度量标准，直接将度量点及其状态展现给用户。ETL规划模块（ETL Governor）会按照设计进行每天多次的抽取，这样数据仓库报表也几乎可以接近实时。QAF预制了普元DevOps系统的数据模型，此外用户还可以通过标准接口将自身的业务系统数据纳入进来，通过可视化ETL（DI Studio）来进行ETL定制设计。数据导出以及数据可视化可以灵活的生成各种各样的报表，以适合不同用户的需求。数据反馈模块（Event Center）会根据度量数据区预制的事件触发条件进行不同的事件处理。

通过QAF，用户不仅可以实时看到普元DevOps平台中软件生产交付的方方面面，还可以清晰的看到这些过程数据如何实现企业的业务价值，让DevOps在客户手里清清楚楚，有度有量。我们会在以后的章节，详细描述度量的实现方式，以及QAF领域系统的实现架构与具体技术。（胡帅原创）

1.无度量不DevOps

DevOps的推广打破了开发，运维之间的壁垒。全员以产品交付为目标，提高效率，完成业务。久而久之消费者就会形成一个潜意识就是：买了这个产品我们企业就DevOps了。（哇，开香槟，散花~）。真是这样的吗？的确DevOps提供了一个新的视角去审视整个公司的人员配置，业务流程，企业文化。打通信息壁垒后，把以前的信息孤岛变成高速公路。但是不是路通了就可以高枕无忧了？Not Yet，高速路也会堵车啊！所以不知道大家是否想过一个问题，到底怎么样才算DevOps了？你的企业DevOps到什么程度？特别是在微服务，微应用时代，一切都在加快，我们用哪些属性去评价一个产品的核心价值，如何准备把握市场动向并且控制风险？如果你心里还没有答案，那就请听我们对这些问题的解答。

2.DevOps衡量模型GRE

通过GRE理论可以很好的回答上面的问题（DuangDuangDuang敲黑板，作者这里不是要出国考研哦: P）

GRE理论是围绕DevOps生命周期内的核心数据做文章，以软件过程为上下文，通过软件度量这种精确制导武器，向用户展现DevOps系统的业务价值。下面我们将一一阐述这三个维度的内涵。

2.1 维度1：Goal （确立目标）

维度Goal：诸多公司拥有大量的数据，但是数据散落在不同的地方，格式并不统一。你和同事之间的沟通成本也许很高。以前经常头痛花费大量的时间去汇总五花八门，格式不一的数据向领导汇报，比如报告上的3天，到底是自然天还是人天？通过DevOps平台+文化的实施，特别是元数据平台的实施，形成各个部门，各个链路的契约。如果你已经感受到这种好处，那恭喜你！DevOps已经在贵公司开始生根发芽。

2.2 维度2：Redo （执行监控）

维度Redo：当数据的统一消除了信息壁垒后，以前的乡间土路都变成了高速公路，但是修路不是目的，真正的目的是有质有量的提高资源周转效率。当你的下属用“差不多”来回应一件事情的进展状况，你是否想知道自己的业务目标完成了多少？

“持续改进理论”是敏捷方法一直提倡的。开发敏捷提倡以不断迭代的方法完成开发目标，以最少的缺陷，在既定的时间与资源内，完成最多的功能。而DevOps的一个非常重要的贡献就是将企业由传统的开发敏捷向业务敏捷转型。过去比较成熟的软件开发工具能提供的数据仅限于开发与测试领域，与业务目标的联系有比较大的鸿沟。

DevOps的索伦之眼将业务到开发的链路打通，现在可以从企业实际的业务目标出发，发现问题，在业务系统内找到反应这些问题的关键数据。用户可以不断监控过程数据，降低成本，持续改进。如果DevOps成功的帮助贵企业从开发敏捷到业务敏捷转型，那说明DevOps已经融入到您企业日常运转的血液中。

2.3 维度3：Excel （精益预测）

维度Excel：黎叔曾经说过：“21世纪最宝贵的是什么？是人才！”那一个人才的最大价值是什么呢？是经验！作为一个管理者，你是否觉得项目的状态很容易变成一笔糊涂账，往往临近计划结束才知道里程碑无法达成？各位看官，如果已经做到了Goal和Redo，那其实已经在业务领域，以及时间维度内积累了大量的数据。将这些数据连接起来就是趋势，客观数据组成的趋势图是管理者做出判断的可靠依据。

比如说随着时间的发展，我们会看出问题的项目中问题的数目骤增，这时候就需要判断是否要介入来控制事态的发展，以此控制风险。当然那个预警线，什么时候做出，代价最低，需要其他数据积累，分析支持才能够给出：比如同等规模的项目，在计划三分之一处，Bug数量已经大于平均每个功能点5个时进行干预，这样，Bug的回归曲线会在项目结束时达到合理的收敛范围内。当一个企业运用宝贵的经验，在了解现状的基础上，对企业的未来发展做出准确的研判，规避风险，使其立于不败之地，这才是DevOps的最高境界。

3.GRE理论的关键：从开发敏捷到业务敏捷

说了这么多你一定很好奇，一个DevOps平台是如何帮助我完成GRE方法的呢？我们一开始就说了，最重要的是对业务目标的追求。业务目标到各个DevOps生命周期是一个分解的过程。这里举一个例子，业务目标：降低成本。

以上对各个部门提出的问题最终会落实到一个度量点上，而这些度量点最终就是该领域部门使用的业务系统直接或者间接的产出。细心的看官已经看出，其实成本本身就是一个度量值。也就是说度量值是可以分层的，一个度量点可能由众多度量点组成。根据普元对DevOps的实施经验，我们推荐以下全生命周期度量属性：

可以看到，以前和开发时期割裂开来的，真正反映产品业务特征的运维数据被重视起来。而且通过统一的DevOps平台，这些数据可以按照统一的格式，既定的时间自动获得。特别是以前无法被度量的用户感知质量，例如：“用户停留指间”，“功能使用率”等。通过对这些感知质量的度量，可以帮助产品的设计者知晓如何在产品的规划中改进产品，也会帮助产品管理者做出资源配置的正确判断。

对于一个企业的管理者来说，最关心的恐怕就是如何将有限的人力物力投资到最有潜力的产品上，从而获得最大的收益。按照ROI模型，一个理想的产品生命周期大致会经历：孵化->增长->稳定->EOL(End of Lifecycle)四个阶段。在孵化期，企业会对产品的投入较高，但是所获取的利润较少。接下来企业最希望看到的是所投资的产品会被市场接纳，也就是进入投资与盈利双高的增长阶段，这个时期是产品发展的黄金时期，积累口碑，占领市场，获取最大的用户群都在这一时期完成。等待产品功能被一定用户验证之后，产品的开发任务就会保持收敛，更多的是售后支持与维护工作，而前端的销售还会一如既往的拓展新的市场，因此产品会进入投资少而受益高的稳定期。

科技的发展日新月异，不论多么伟大的产品可能都将最终面临被市场淘汰的命运，也就是进入EOL的阶段。值得注意的是，有很多产品都无法完全经历上面四个周期，甚至在孵化期就会被市场淘汰。将DevOps全生命周期的重要度量属性连接起来，提供从业务到开发各种视角的参数，使得管理者能准确把握产品市场定位，在产品发展的每个时期进行资源的合理配置，预测风险促使产品在每个不同象限的过度，懂得取舍保持相对的利润最大化。如果DevOps帮助一个企业做到了这些，就真正的完成了从开发敏捷到业务敏捷的转型。

4.微服务世界中的度量属性

相信大家都会感到，如今软件的开发速度明显的加快了。从物理层角度来看，软件的基础模块功能逐渐被DevOps平台提供的各种成熟的中间服务替代，开发者只需要关心核心的业务，这大大降低了软件开发的复杂度，也加快了进度。从市场需求来看，更加注重用户体验等使得复杂的产品没有了市场。用尽量便捷的步骤以及功能满足用户对大的需求，化整为零。这是微服务，微应用的设计理念。

·     Time to Market：从产品的需求定义到上线的时间。

·        Ratings：用户踩，或者顶的次数。

·        Ranks：级别。

·        User Residence：从用户创建一个应用到销毁的持续时间。

·        User Expansion：用户数变化。

·        Spending：平均用户消费。

·        Response latency：调用一个服务到收到一个回复的时间。

·        Language adoption：不同微服务，不同语言用哪种开发最快。

·        Dev period per function：每个功能平均开发时间。

·        Function hit：每个服务请求，或者点击次数。

·        Deploy Speed：应用部署速度。

·        Crash Times：应用出现错误的次数。

我们更加关注一个应用花费多长时间占领市场，用户对一个应用的直接感知评价，用户对那哪些功能感兴趣，以及通过用户对一个应用实际的停留时间判断产品对市场是否有价值。可以看到微服务世界中的核心度量更加敏捷，也更加贴近用户第一手的使用感受，使得度量对产品的衡量更加准确，体现业务价值。

5.基于GRE模型的质量反馈系统

根据前面描述的度量理念，我们以微服务架构设计了普元的DevOps 质量反馈系统（QAF：QualityAssurance Feedback），这个系统的设计目标是通过建立统一的数据度量体系，提供动态以及可追溯的全领域洞察能力。通过QAF，用户可以按照统一的模型对数据进行访问（实现Goal度）；实时掌握，监控在制品的生产情况（Redo维度）；还能查看历史数据，查看问题发展的趋势，甚至根据分析模型预测某些问题的发展状况（Excel维度）。

QAF的数据分为三类，第一类是直接通过RESTAPI来访问数据源，获取的原始业务数据。第二类是利用Data ETL抽取数据，在经过数据清洗后放入数据仓库中形成行星架构（Star Schema）。第三类是在前两种的基础上，按照度量标准，直接将度量点及其状态展现给用户。ETL规划模块（ETL Governor）会按照设计进行每天多次的抽取，这样数据仓库报表也几乎可以接近实时。QAF预制了普元DevOps系统的数据模型，此外用户还可以通过标准接口将自身的业务系统数据纳入进来，通过可视化ETL（DI Studio）来进行ETL定制设计。数据导出以及数据可视化可以灵活的生成各种各样的报表，以适合不同用户的需求。数据反馈模块（Event Center）会根据度量数据区预制的事件触发条件进行不同的事件处理。

通过QAF，用户不仅可以实时看到普元DevOps平台中软件生产交付的方方面面，还可以清晰的看到这些过程数据如何实现企业的业务价值，让DevOps在客户手里清清楚楚，有度有量。我们会在以后的章节，详细描述度量的实现方式，以及QAF领域系统的实现架构与具体技术。（胡帅原创）