微软的数字化转型案例——探针平台

观点

颠覆一直是业务转型的催化剂。为了走在最前沿，我们正在变得更加敏捷、高效和创新。这意味着改变我们的系统和流程，以支持并快速适应新产品、服务、商业模式、法规以及其他任何我们遇到的事情。
微软支持向云迁移，因为它为我们提供了支持下一代业务应用程序所需的基础架构。它还提高了协作和生产力，使我们的员工更加成功。

Microsoft Digital

目标：满足各个团队的数据需求，缩短可视化报告的处理难度和周期，加强数据可视化的实时性和时效性；
特点：

• 丰富、可靠的数据；
• 方便的数据获取接口；
• 简单灵活的报表、看板的生成模板；

数字探针能力

概述

聚合干净、互联、权威的数据，创建扎实可靠的数据底座，使得数据易发现、易消费，任何团队都能利用这些数据产生洞察，并由此引导开发出符合团队利益的智能体验；
开发AI模型，利用丰富的数据，加速、增强专家决策；
使用分析服务，汇总员工所处的职业生涯（职位）、所处的流程、所做的行为和提出的见解，评估总体的战略进展；
Microsoft Digital创建了一个统一的遥测平台（UTP），以在所有相关业务级别，提供端到端的企业运行状况监视和数据驱动的决策功能。该平台可帮助Microsoft Digital获得有关整个业务的功能，客户体验，使用模式和有效性的关键见解。

应用遥测

As is：
一个复杂系统中集成了大量应用，应用间功能的配合复杂，还可能存在功能重叠，单凭采集的应用日志信息难以快速定位问题根因。员工需要在不同的应用日志、报告中切换比对，才能理解应用间如何配合，因此效率极低；
不同的应用往往来源于不同的设计，采集到的应用日志、报告数据也遵从不同的标准和分类原则，即使意义相同的数据也难以进行对比；（举例：相同数据的多种表现形式）

To be:
扩展为标准化的系统监测和数据采集方法；
追踪、汇总、组合所有应用的全局信息，检查并理解整体业务流程（跨应用级）的健康状况。（举例：当一个销售在“客户关系管理”应用发现一个交易机会，就应该链接到“客户计划”应用，确定这个交易机会对团队的贡献，再做下一步动作。）

创建可定制的遥测框架

遥测是我们更加了解客户的第一步
遥测的第一步是为数据建立统一的字段模板，用于确认和标记跨系统的数据类型，这里分为了三个部分：
系统级：基本由日志系统自动生成，例如用户名，客户端IP和事件时间戳；
特定领域：字段命名和数据类型由数据分析团队负责审视和发布，事件字段内容由事件作者编写的代码填充；
自定义：事件作者对该字段拥有完整的控制权，包括定义字段命名和数据类型；微软提供一个 NugGet 包，这个包提供遥测功能的应用插件部分，工程师可以引用这个包发送遥测数据的自定义字段给遥测客户端；
遥测环境最重要的一方面是为所有应用创建统一的用户ID和行为ID，微软称之为Cross-Correlation Vector;

构建方法

按照模板定义遥测框架
使用Azure数据工厂，在不同的遥测数据源与Azure数据湖之间传输、转换数据
创建遥测数据流以提供端到端的业务流程环境
内置遥测扩展（插件）到应用来获取数据，如果应用不支持内置，遥测扩展则用于挖掘应用产生的数据；
数据工厂将生数据（raw data）传入数据湖；
生数据在数据湖中，通过基于数据湖原生查询语言 U-SQL 的一个个任务，被转换为统一数据格式输出（common schema output）或聚合输出（aggregation output）；
输出（数据）由 U-SQL 的统一接口消费，用于生成可视化报表（MS Power Query 或 MS Power BI）

提供易用且有价值的数据表现形式

Azure App Insights 遥测聚合：提供看板的核心数据；
Azure Data Explorer：实时数据的分析工具
数据工程师能够通过可交互的方式浏览、分析数据，来解决业务痛点、监控基础设施、改进应用组件和提升客户体验；
Kusto 查询语言 -- 能够使数据工程师以所需的任何格式，快速访问实时数据的视图和见解；
Azure Data Explorer 看板 -- 能够为业务团队和用户体验团队提供近乎实时的数据可视化呈现；
Power BI 看板：帮助员工从丰富的遥测数据中，通过对数据不同维度的可视化，获取潜在的、更深层的洞察见解；

上图是Power BI遥测看板中，可视化了的13款应用间数据流向，其中包含了更完整的业务场景。

践行以客户为中心

传统的业务研发模式：技术团队聚焦于实现技术方案，业务团队借助工具为客户提供有价值的产品；
使用 Azure，能够节省额外的部署、管理传统数据中心的时间和精力，用于投入更多资源到应用开发的改进和创新；
针对业务流程的应用遥测能够为我们提供以客户为中心的见解，并且我们可以使用内置的工具、看板来获取这些见解，而不需要重复搭建；

一些经验总结

数据存储需要弹性、可扩展；
统一的数据格式很重要，但仍然不应该取代数据采集过程 -- 数据清洗、转换在实际中在所难免；
首先确认我们需要从数据中获取什么样的见解，再去做可视化 -- 不要让数据的格式和组织决定我们从数据中获得的见解。

原文

https://www.microsoft.com/en-us/itshowcase/understanding-our-business-with-app-telemetry

个人理解

我们需要一种手段，可以监测跨‘节点’的业务流程，来帮助：
快速理解发生的某个事件对整体业务方向的影响是什么，是否与目标相匹配；
决策下一步的行动；
在软件研发领域，遥测可以用来做“进阶版的精准测试”：代码修改对于软件功能、质量有哪些影响；
在云服务领域，遥测就是在做“自动化的运维平台”：各种事件对于服务功能、性能有哪些影响；

数字探针的应用——SAP中的应用

概念

• SAP：企业流程管理软件提供商，提供组织间高效数据处理与信息流转的解决方案；中心化的数据管理；
• ERP：全称Enterprise Resource Planning，支持企业所有的核心领域，包括采购、生产、原料管理、销售、市场、财经和HR
• IDoc：SAP的消息载体，全称Intermediate Document，用于流程间传输业务交易数据；

SAP账务处理流程监控

步骤	描述
1	通过IDoc收到用户交易请求；流程会触发例测检查当前流程是否需要遥测，如果需要，则抛出事件“Idoc_Created”，创建流程对应的消息体，然后根据调用系统的交易ID设置XCV——XCV将贯穿该整笔交易过程；
2	对于订单到支付流程，IDoc会经过SAP标准过程处理，完成后触发发布IDoc处理完成事件，事件信息中包括IDoc，XCV和一些指标；
3	IDoc处理成功后，SAP将提交销售订单到数据库。如果订单生成成功，则触发“Order Create”事件，事件信息包括订单创建包括订单创建时间，XCV，以及应用相关的一些具体信息；
4	创建账单文档并生成客户发票，完成后触发事件“Billing Document Created”，事件信息包括账单文档创建时间，XCV等；
5	账单入账，完成后触发事件“Billing Document Posted to Accounting”，时间信息包括帐单文档创建时间，XCV等；

例：假如步骤5失败，系统会立即检测到故障：账单已生成但入账超时，通知各个角色处理应对。
通过业务流程级别的追踪，微软做到了对SAP这个黑盒的一些重要洞悉：

• 根据预定义的业务流程规范，监控流程异常；
• 衡量每个步骤的执行时间；
• 随着数据的积累，可以尝试流程挖掘等技术，识别流程瓶颈并优化流程；
• 记录来自外部的交易信息并实现可追溯；