03 全链路流程：前端全链路的关键路径有哪些？
你好，我是三桥。
上节课，我们从不同角度感受了前端全链路的重要性。用户虽然不关心全链路，但他们关注“我使用的产品必须稳定、快速、好用”。所以，咱们作为前端同学，必须要有意识地使用前端全链路，把它看作一种“重要功能”。出现问题的时候，就能快速定位问题，甚至提前发现问题。
我们在第一节课讲到了前端处理问题的四个维度，分别是数据维度、交互维度、性能维度、兼容维度。
我们前端全链路的方案，就是要去发现这四个维度的问题。
那具体的发现过程是怎么样的呢？这就是咱们这节课重点内容了。
我们说过，前端全链路不是个标准、也不是某个技术点，它主要是一套协同解决问题的方案。既然是一套解决方案，那么我们就可以用产品设计的思维去设计前端全链路的实现方案。
前端全链路的实现方案中有三个关键要素：数据指标、监控、决策。这三个要素之间相辅相成，形成了一套完整的前端解决方案。
讲一个前端全链路小故事
问题来了，怎么处理三个要素之间的关系，又怎么在三个要素的基础上设计一套全链路解决方案呢？
我们先从通过前端全链路发现的一个小问题开始说起。
相信做过前端项目的你一定做过H5列表页，比如图片展示列表、作品展示列表，图片详情页等等。每个列表项一般都会有标题、描述、作者、图片这几个要素。
发现问题的经过是这样的。当时，其中一个经过多次迭代页面的Vue历史项目，在上线接入了前端全链路的功能。这样，我们就能自动监听H5页面中图片是加载成功还是失败了。失败的话，就会记录一条日志，然后上报给后端。
在上线后，通过日志异常预警通知，我们发现了大量异常日志，每天至少超过1000条。
通过筛选和分析每天的日志，我们发现其中有70%的日志都是前端资源异常的日志。接着，我们又细分了前端资源中的异常日志，发现图片资源加载异常占比接近80%，其余的问题只有20%。
当时我就比较好奇，为什么有这么多图片加载异常的错误日志呢？接着，我对这80%的图片异常日志进行筛选和分组，最后得出一个结论：图片地址已失效无法访问。而这些图片都是用户上传的作品图片。
然后，我拿着整理好的数十个已失效图片地址，找运维同学一起排查原因，最后得出的结论是以前做过一次数据迁移，而部分图片数据在迁移过程中丢失了。
面对这样的结论，我也评估不了这些图片带来的问题是否会影响用户体验。最终，我把问题反馈给了产品经理。反馈之后，我提出两个解决这个问题的方案。
- 监控预警告警中，移除这些异常图片加载的报错提示。但这不是解决问题的根本方法。
- 在数据库中删除已失效的图片数据，仅保留用户成功加载的部分。
产品了解了问题的背景后，发现这些图片以及对应的H5页面都是历史需求中的过程页面，是用户打卡分享转介绍的活动。缺失的用户图片无法恢复，可以考虑删除。
和产品商量后的决策，就是删除我们数据库中的图片数据。
关于这次问题，我们做对了什么？
你可能会觉得这是一件很小的事情呀，没什么特别重要的地方。但这个故事里，我们在前端全链路里做对了三件事情。
- 第一件：用数据和日志记录用户行为。
记录用户行为，就是把我们认为可能有问题的地方捕捉下来，并用约定好的数据结构和数据规则存储到监控系统上，俗称服务器。
这样的功能，对于前端同学来说，无非就是在前端代码里生成数据和发起一次POST请求。
在上述例子中，我们的方案是，在全链路SDK里面给图片Img元素加上了onerror事件。这样，在判断图片加载失败时，就会自动上报一条异常日志。
有了日志后，就需要一套程序（比如定时器），对日志进行清洗、整理、分析，再通知给我们。
我们再来回到三要素中数据指标与监控的关系。
你看， 数据指标和监控的关系，更像是前后端互相配合的关系 。 简单来说，就是前端把数据传递给监控，监控则提供API接口给数据指标存储起来。前端和后端同学通过完整的前端全链路实现方案，实现一套通用前端全链路功能。
至于数据指标，就非常好理解了。它的意思就是 给前端全链路定义一些数据结构和数据规则。相当于根据产品需求设计需要关注的业务流程日志、异常日志以及性能日志，并通过约定的格式要求传回服务器。
- 第二件：通过监控，从日志中发现可疑问题 。
我们做对的第二个地方，就是不断把收集回来的错误日志实时通知到前端同学。可能你会问，这么多日志，又忙于需求，怎么可能做到每条日志都去分析呀？
你的疑问是对的。其实我要表达的一个观点是， 不用怕日志多，也并非每条日志都要去分析，而是我们要对每个时刻日志预警和告警的量级进行一个初步评估。
假设在一个工作日的早上，我们收到的日志只有几条，但有一天，异常日志量突然涨到几十，甚至几百、几千条，这时候，我们就需要重视了。
这种时候，我们就要去翻一翻日志库，做一次初步的分析。想想这些暴增的异常日志通知的背后到底发生了什么？如果能够快速判断到问题，我们就可以快速响应。
再回来上述的例子，虽然例子中是一件很小的事情，但防患于未然，而且只要一点一滴地解决潜在的问题，那么异常通知的池子就会越来越少，异常日志越少，我们就能越安心地做需求。
我们再次回到前端全链路三要素中监控与决策者之间的关系。
从上图我们可以理解， 监控相当于一台自动化运作的机器，用于发现问题，并把信息通知给决策者。决策者会通过一种方式接收监控的信息，比如钉钉，然后根据反馈的日志进行分析，找出问题根源，给出解决方案。
有时候，决策者并非一定是前端同学，在成熟的研发团队里面，只要这个环节设计得合理，完全可以交给测试同学负责。当然，如果真是代码逻辑引起的问题，前端同学也要参与解决，走不掉的。
- 第三件：多方协同，找出最合适的优化策略 。
我们做对的第三件事，就是找相关联的同学一起讨论问题。通过一起分析日志，找到原因是图片资源已经被删除了。而这些图片已经不重要，那就可以通过彻底 删除的方式解决问题。
在这里会有一些前端同学问，这种合作不是很正常的吗？确实是正常的，但有一点要注意的是，产品同学是为产品和用户负责的，我们前端同学不仅为产品负责，还要为自己的代码负责。我们实现的前端全链路解决方案，其实就是产品功能之一，只不过这个功能是为研发团队服务而已。
产品是不可能没有缺陷的，只有大和小的区别，有严重的和不严重的区别。只要发现问题，首要的任务就是分析问题的严重性。如果需要多方协同决策，就一起商讨解决方案。如果发现这个问题会影响用户使用，那一般都会提技术需求进行迭代优化。
OK，再来看看数据指标与决策者之间的关系。
在这个环节里，我们可以看到，决策者既有可能来自一个人，也有可能来自多人。决策者依据监控系统提供的信息进行分析，并给出问题的严重性以及处理优先级别，最后通过决策给出最优解。
另一方面，决策者有时候从监控中发现可疑问题或者无法找到问题的根源时，就需要对数据进行更细化地捕捉，从决策上判断是否需要对此前定义的数据规则进行更新。
前端全链路的三要素
通过例子，我们说明前端全链路中3要素之间的逻辑关系，但你可能会觉得，这些流程日常工作中都存在，而且每个要素我都明白啊，但应该从哪里入手设计前端全链路的方案呢？
别担心，接下来，我给你再细化3要素的14条路径。
前面已经说到了，数据指标的定义就是基于项目的实际情况设计一套前后端通用的全链路数据结构和规则约定，是整个前端全链路的核心数据模型。
在前端技术领域， 数据指标 非常广泛，但不外乎3个维度：交互、性能、数据。再细化下来， 就是7种类型数据：PVUV指标、基础数据、性能指标、行为动作指标、脚本异常日志、接口状态日志、资源状态日志。其中，基础数据是一套前端通用数据，用来记录其关联的数据，例如UserAgent、URL、UserId等等。
至于 监控 的核心职责就是发现问题并通知决策者，同时还能让我们通过日志库快速定位问题。而且并非一定要实现一套完整的系统，只要能够把流程走通，就能非常高效地处理问题。只要团队有足够的资源，就可以在监控这个要素中增加可视化分析报表。
很显然，这个要素中，存在3个主要路径：日志分析、设置阈值监控、通知。
第三个要素， 决策。顾名思义，就是指处理问题时需要做出的关键性选择和决定，指导产研同学的工作质量和产品的质量。你也可以这么理解，决策者在这里基本上是指产研同学。谁能做最终的决策者，完全依赖于问题的类别以及严重性。如果问题跟产品功能相关，那么最佳的决策者就是产品。假如是性能问题，那么前端同学就是最合适的决策角色。
你看，夹在中间的前端同学，每做一件事情，都需要决策。做决策就需要沟通、协调，通过决策找出最佳优化策略以及问题解决方案。一个良好的决策能够提高解决问题的效率，提早发现潜在问题。
在“决策”要素中，有4个关键路径帮助我们完善前端全链路的协作机制，分别是协同决策、最优策略、风险预判以及反馈机制。
最后总结一下，三要素，14个路径如下图所示。
总结
本节课，我们用一个发现图片资源加载失败的例子，拆解了前端全链路分析问题的过程。
在这个过程里，我们用数据指标、监控、决策三个关键要素去分析问题的完整链路，最终完美解决了问题。
在课程的最后，我们给三个关键要素下了定义，同时给出了3要素下的14条有效路径。接下来的课程中，我们将围绕这14条路径去学习落地前端全链路的完整过程。
最后咱们再强调一遍，前端的问题从来不是单一维度的，在解决问题的过程中，更需要我们具备“全链路”的思维。 前端全链路作为一套快速定位问题的解决方案，更像是技术专项的形式和产品思维角度去实施全链路的整合。 把技术和产品结合起来，才能真正满足用户的需求。
思考题
最后，留一道思考题给你。我在本节课中提到的14条路径里面，你最想学习哪一条路径？你所选择的这条路径，是希望解决你工作中的什么问题呢？
欢迎你在留言区和我交流。如果觉得有所收获，也可以把课程分享给更多的朋友一起学习。我们下节课见！