背景介绍

公司要发展是为了保持竞争力、实现可持续发展并满足市场需求。随着市场环境的不断变化，公司需要不断创新、拓展业务范围、提高产品质量和服务水平，以适应不断变化的市场需求和客户需求。只有不断发展的公司才能在市场中立于不败之地，实现可持续发展。而业务是公司发展的基础和核心，公司通过不断拓展和优化业务来实现发展目标。
随着业务多模式发展，二手车业务已经从相对简单的业务逐步转变为包含交易业务交易、O2O、信息业务等。随着业务的发展，用户在业务中的生命周期获得了延长，用户端和商家端在业务上结合得越发紧密。在此基础上，还有新旧业务功能持续集成，以此来产生协同效应。越来越多的业务流程也导致了管控难度的提升以及流程上下游之间衔接点的增多。在这个业务发展的背景下，技术系统在支撑业务功能迭代时发现，由于业务的广度和深度的增加，技术系统在实现业务目标时，服务与服务之间的调用链路增长，关系增多，业务目标服务与服务之间的转化难度也在逐步提升，技术系统领域的复杂度也产生了新的增长。这些技术系统的问题会直接反映在业务目标的转化上，体现在是否更快速、更高效。

意义价值

技术团队的目标是开发新功能和保障技术系统稳定运行。业务的实现严重依赖于技术系统的运行状况，而越是复杂的技术系统，就越需要技术团队来掌控其运行状态。只有当技术团队很好地掌握了技术系统的运行状况时，才能助力业务目标的实现。提高技术团队的掌控能力需要深入洞察技术系统的运行状态。随着技术系统的复杂度不断提高，技术团队面临着三个关键性洞察力问题。从业务视角来看，技术层面的监控系统缺乏对业务的深度监测和评估，链路监控无法实现对业务转化链路的串联监测，而仅有的基础资源类监控指标无法反映业务结果。

业务部门的技术团队作为为商业侧服务的技术团队，其目标都是支撑业务实现商业价值。技术团队的核心问题在于提升商业转化路径上各个业务节点的技术质量。技术团队在技术层面需要提升对技术系统的洞察力，在业务层面需要确保商业转化路径的质量。上述两个方面的诉求归根结底都与技术系统的质量相关，既横向保障业务在商业转化路径上的质量，又纵向保障技术系统在系统调用链路上的质量。综上所述，技术团队的任务是实现商业价值，而商业价值的实现路径需要有很好的质量保障。技术团队需要解决的问题是提升系统的洞察力，以夯实实现商业价值的基础。

实践操作

实现商业价值

那么业务侧的技术团队如何实现商业价值？技术团队可以通过优化业务流程、开发和实施高效的业务流程来提高公司的整体运营效率。也可以通过创新产品或服务、研发新技术或新产品来满足市场需求，从而带来商业价值，或者通过降低成本、优化技术方案来降低公司的运营成本等多种方式来在实现商业价值中做出贡献。通过拆解技术团队的日常工作，技术团队在实现商业价值中的核心是两个事项：编写代码和运行代码，然后实现新功能、改进现有功能、修复错误、提高性能或降低成本等。所有这些产生商业价值的事情只有在代码运行时才能提供，而不是在编写时就可以提供。因为即使代码设计模式适用、代码注释详尽、数据算法高效，如果没有运行，对于业务而言仍然没有实现任何商业价值。运行中的代码才是有商业价值的。因此，为了为业务提供最大价值，技术团队需要尽可能深入地了解代码运行时的状态，而技术系统的度量指标通常是实现这一要求的唯一方法。

行业解决方案

服务于业务侧的技术团队，希望能够通过对技术系统的持续改进在实现商业价值中做出更多的贡献。结合团队的诉求和现实情况，行业内有各种各样的监控系统，能够实现技术系统端到端的监控，比如Prometheus等。同时，汽车之家内部也有一些自研的监控系统，基本能够实现全覆盖的监控。然而，技术系统的持续改进与带来商业价值之间总是缺乏一个有效的链接。我们逐渐认识到单纯部署一个或是几个监控系统不能解决我们的诉求，我们需要的是一种能够建立在基于数据的决策思想之上的方法，旨在提高软件质量、性能和可维护性，在整个软件开发生命周期中持续收集、分析和利用各种度量和指标，通过与业务侧深度协作，通过有益的决策来推动持续改进。这与度量驱动开发（Metrics-Driven Development，简称MDD）的理念不谋而合。
度量驱动开发主张整个应用开发过程由指标度量驱动，通过实时度量指标来驱动快速、精确和细粒度的软件迭代。度量驱动开发的理念，不但可以让技术团队实时感知技术系统的状态，及时跟踪定位并解决问题，而且可以帮助业务和运维团队一起关注相关的业务指标。

度量驱动开发（Metrics-Driven Development）的理念理早是在2011年3月12日Etsy公司举办的一次技术交流会上，由Etsy核心平台部负责人Mike Brittain提出的。

应用可观测性

业界对于度量驱动开发有许多应用的案例和实践，来自Gartner的《2023年重要战略技术趋势》中的“应用可观测性”也介绍了类似度量驱动开发一致的理念。

“应用可观测性是指，以高度协调和整合的方式 在业务职能部门、应用和运维(I&O)团队中应用可观测的数据，尽可能缩短行动与响应之间的延迟，实现业务决策的主动规划。”
引用

Prometheus

Prometheus官网的宣传标语是From metrics to insight（从指标度量到洞察力）。

度量驱动开发

度量驱动开发的理念是需求阶段就考虑设置关键指标监控项，随着应用上线，通过指标了解系统状态，通过对现状的数字化和可视化，帮助业务对未来进行规划和预测，进而实现业务改善。而且度量驱动开发是一种文化的纽带，对于敏捷开发、持续集成、持续交付，以及各个职能岗位提升合作共赢的意识具有很大的帮助。

• 对业务而言，可以实时掌控业务各项指标，通过数据做出决策。
• 对研发而言，可以实时感知应用各项指标、聚焦应用优化。
• 对运维而言，可以实时感知系统各项指标、快速定位问题。

度量驱动开发可使所有可以测量的东西都得到量化和优化，进而为整个开发过程带来可见性，帮助相关人员快速、准确地做出决策，并在发生错误时立即发现问题并修复。我们希望通过感知技术系统的运行状态，并且不断根据运行时的数据提供改进策略，将上线、监控、调试、故障调查及优化等纳入设计阶段，而不是等到系统部署后再去补充。相对于通过制定各种复杂、严格的研发规定，以及各种评审会议来确保技术系统的安全可靠、稳定运行，度量驱动开发的理念的特别之处在于，通过采集必要的监控信息，通过持续交付方式进行快速迭代并进行反馈和修正，所有决定都是基于对不断变化的情况的观察做出的。

团队实践探索

技术团队在采用度量驱动开发的实践探索过程中，总体分为4个阶段，首先，依据业务的范围进一步圈定核心领域。其次，通过核心领取构建度量指标体系。再次，通过对于度量指标的监控协同业务侧推动部分指标的改善，我们在此采用了最小可行产品（Minimum Viable Product，MVP）的策略，通过构建具有最少功能的版本，尽早地推出产品以测试反馈并验证概念的可行性。最后在验证效果后建立可视化的技术系统来推动整体的实践探索更具易用性、扩展性的落地和发展。

度量驱动开发那么首先需要解决的问题就是度量，也就是度量指标体系的构建，回顾探索实践的过程，在实践探索的过程中遇到的困难的也是度量指标体系的构建。度量指标体系的构建我们的目标是做到覆盖尽可能全面的覆盖，我们对于全面覆盖总结为横向和纵向2个方向上的覆盖。首先，横向需要满足业务的广度尽可能的纳入更多的核心关键业务，其次，纵向需要将业务-技术纵深进行深入的挖掘覆盖尽可能多的核心关键技术系统。

团队在度量指标体系的构建中，围绕业务流程的服务树，通过业务流程中各个关键节点的指标的下钻和穿透到极致，再通过参考Google SRE中提出的系统监控的四个黄金指标，构造业务-技术的全覆盖度量指标体系。

• 延迟（Latency）：衡量服务请求所需时间。例如，从技术视角所关注的HTTP请求平均耗时，而在业务视角下为用户完成下单操作的所需时长。
• 流量（Traffic）：衡量服务的容量需求。例如，从技术视角下每秒处理的HTTP请求数或者数据库系统的事务数量，业务视角下用户完成下单的数量。
• 错误（Errors）：衡量服务错误发生的速率。例如，技术视角下HTTP 500错误数等显式失败，返回错误内容或无效内容等隐式失败，业务视角下用户下单失败数量等。
• 饱和度（Saturation）：衡量当前服务的饱和度。例如，技术视角下内存、CPU、I/O、磁盘使用量，业务视角下的任务的完成率、优惠卷的使用量等。

技术在系统建设阶段完成了一个覆盖业务上用户端到商家端，技术上客户端到服务端的全景监控系统的建设，核心功能包括数据可视化、业务链路定制和监控预警。首先，我们复用公司的数据处理能力，包括数据收集、清洗、转换和存储等基础数据处理服务，通过复用它们，我们能够迅速获取数据处理能力，确保数据的准确性和一致性。另外，我们通过接入前端性能监控、云监控以及质量罗盘等监控系统，我们实现对整个技术系统的实时监控。在系统建设的技术选型上，我们选择了低代码平台作为开发工具。低代码平台提供了可视化开发环境，减少了开发工作的复杂性，不仅加快了构建和迭代速度，还提高了系统的灵活性和可扩展性。全景监控系统的建设不仅有助于团队更好地理解和管理其业务和技术系统，还为未来的创新和扩展奠定了坚实的基础。

实践成果

完成度量指标体系构建

完成基于业务的度量指标体系构建，完成设计近400个相关数据指标，实现了业务流程和技术系统的全面覆盖，具有重要意义。这一成果为业务提供了全面的数据洞察，帮助业务和技术人员更好地理解业务进展和技术系统，从而做出更明智的战略决策、提高效率、优化资源分配、改善客户体验，最终实现竞争优势和可持续增长。这些指标不仅提供了深刻的业务洞察，还为数据驱动的决策和创新奠定了坚实的基础。

形成改善的度量指标

商业价值提升，用户买卖车信息的处理效率提升240%，用户卖车信息的从车辆信息的提交再到将车辆信息通知商家进行处理这其中要经历很多业务流程以及技术系统，通过对车辆信息数据处理流程时长的监测发现问题点，通过与业务方协作的方式，改进车辆信息数据的处理流程，提高了数据留转与处理的时效，通过技术系统的改善提升了业务的运转效率，提升了商业价值。
商业价值挽回，拦截异常车况报告解析订单2000单，在车况报告解析积压和延时的及时预警发现问题点，通过对异常情况的的及时跟进处理拦截异常订单，实现商业价值的挽回。

未来展望

度量驱动开发（Metric-Driven Development，MDD）在软件工程领域扮演着关键的角色。它强调了度量数据在软件开发过程中的重要性，这些度量数据可以是关于代码质量、性能、可维护性、进度等各个方面的信息。首先，度量驱动开发有助于质量的改进。通过定期收集和分析度量数据，技术团队可以更好地了解软件质量的状态。这包括了解代码质量、性能表现、可维护性等各个方面。当度量数据揭示出问题或潜在的缺陷时，团队可以采取措施来改进质量，确保软件达到高标准。其次，度量数据可以用于目标设定。技术团队可以根据度量数据来设定明确的开发目标。例如，他们可以使用性能度量来设定性能目标，代码质量度量来设定代码质量标准。将这些目标加入到技术团队开发过程中的指导原则，有助于确保项目朝着期望的方向前进。此外，度量数据可以提供决策支持。项目管理和决策制定者可以根据度量数据做出明智的决策。例如，他们可以根据度量数据决定是否进行技术债务的偿还、是否进行性能优化、是否进行安全漏洞修复等关键决策。持续改进是度量驱动开发的核心原则之一。通过分析度量数据，团队可以识别问题的根本原因，并采取措施来不断改进开发流程、工具和实践，以提高效率和质量。最后，度量数据还有助于提高透明度和沟通。团队成员可以共享度量数据，让每个人都了解项目的状态和质量，有助于更好地协作解决问题。

通用化建设

下一个阶段重点建设的方向是监控工具的通用化建设，通用化的工具建设将更加灵活，允许团队根据其特定需求进行定制和扩展，能够满足不同团队和业务的需求。通用化的工具建设将更易于扩展，支持集成新的数据源、第三方插件和自定义脚本，以适应不断变化的技术栈和复杂性。这将为团队提供更大的灵活性，使他们能够构建适合其独特需求的度量驱动开发的解决方案，从而更好地理解和管理他们的技术系统和业务。

智能化建设

人工智能在软件领域有广泛的应用场景，比如AIOps等，未来支持度量驱动开发的工具系统需要更加自动化和智能化。机器学习和人工智能技术将用于分析监测数据，自动检测问题、异常和趋势，并提供实时的反馈和建议。通过机器学习和人工智能技术的应用将更有助于更精准的定位问题，更快地响应和解决问题，减少人为干预的需求，提高效率、可用性和安全性，降低成本，推动团队更好地进行资源利用。

写在最后

正如现代管理学大师彼得·德鲁克所说的“如果你无法度量它，就无法改进它”，度量帮助我们更深刻认识软件工程领域中的方方面面，设定改进方向，并衡量改进效果。

参考文档

Metrics-Driven Development https://legacy.devopsdays.org/events/2012-italy/proposals/MetricsDrivenDevelopment/
An Intro to Metrics Driven Development: What Are Metrics and Why Should You Use Them? https://www.freecodecamp.org/news/metrics-driven-development/
Metrics-Driven Development https://sookocheff.com/post/mdd/mdd/
Metrics-Driven Development https://www.infoq.com/articles/metrics-driven-development/