1.3.1　MDD理念综述

MDD（Metrics-Driven Development）主张整个应用开发过程由指标驱动，通过实时指标来驱动快速、精确和细粒度的软件迭代。指标驱动开发的理念，不但可以让程序员实时感知生产状态，及时定位并终结问题，而且可以帮助产品经理和运维人员一起关注相关的业务指标，如图1-6所示。

图1-6　基于MDD思想的DevOps

MDD理念最早是在2011年3月12日Etsy公司举办的一次技术交流会“Moving Fast at Scale：a microcon-ference at SXSW”^[1]上，由Etsy核心平台部负责人Mike Brittain提出的。其实技术领域有很多驱动开发的理念，如表1-2所示。

表1-2　驱动开发理念

MDD可使所有可以测量的东西都得到量化和优化，进而为整个开发过程带来可见性，帮助相关人员快速、准确地做出决策，并在发生错误时立即发现问题并修复。MDD可以感知应用的“脉搏”，并不断根据运行时的数据提供改进策略。MDD的关键原则如下。

·将指标分配给指标所有者（业务、应用、基础架构等）。

·创建分层指标并关联趋势。

·制定决策时使用的指标。

TDD主张在业务代码之前先编写测试代码，MDD则主张将上线、监控、调试、故障调查及优化等纳入设计阶段，而不是等到实施后才补充。相对于通过制定各种复杂、严格的研发规定，以及开无数的评审、研讨会议来确保软件的安全发布、稳定运行，MDD理念的特别之处在于应用程序本身。在MDD理念下，采集必要的监控信息，通过持续交付方式进行快速迭代并进行反馈和修正，所有决定都是基于对不断变化的情况的观察做出的。在软件的设计初期就包括Metrics设计，设计一套规则来评价系统的稳定性、健康状态，并监控其他考核目标，将这些作为服务本身的KPI。因此，通过应用MDD理念，可将Dev与Ops之间或多个Dev团队之间出现的责任博弈降至最低，甚至使矛盾完全消失，这也有利于团队稳定发展。因此，MDD可以用于决策支持、预测趋势、测试系统的补充、关联性分析等。

依照MDD的理念，在需求阶段就可以考虑设置关键指标监控项，随着应用的上线，通过指标了解系统状态，通过对现状的可视化和具体化，帮助用户对未来进行规划和预测，进而实现业务改善。传统模式中，Dev和Ops是割裂的，而MDD是DevOps文化的纽带，对于敏捷开发、持续集成、持续交付，以及各个职能岗位提升DevOps意识有很大的帮助。

·对软件研发人员来说，可以实时感知应用各项指标、聚焦应用优化。

·对运维人员来说，可以实时感知系统各项指标、快速定位问题。

·对产品经理、商务人士来说，可以实时掌控业务各项指标，通过数据帮助自己做出决策。

在Prometheus官网（https://prometheus.io/）的首页展示的宣传语是From metrics to insight（从指标到洞察力），如图1-7所示，由此也可以看出Prometheus与MDD的关系。

图1-7　Prometheus官网宣传语“From metrics to insight”

MDD理念的监控分层主要有3种，这3种监控分层对应着图1-1所示的5层轻量监控体系中的部分模块：

·Infrastructure/System Metrics：如服务器状态、网络状态、流量等。

·Service/Application Metrics：如每个API耗时、错误次数等，可以分为中间件监控、容器监控（Nginx、Tomcat）等。

·Business Metrics：运营数据或者业务数据，比如单位时间订单数、支付成功率、A/B测试、报表分析等。

业界有很多Metrics实现方案，比如dropwizard-metrics、prometheus-metrics等，我个人推荐用开源产品Micrometer来实现Metrics监控，本书后续章节会重点对此展开介绍。

[1] https://codeascraft.com/2011/03/01/moving-fast-at-scale-sxsw/。