17 数据可视化：可视化监控真的重要吗？
你好，我是三桥。
许多前端同学都有参与可视化前端产品的经历，比如设计数据可视化工具、产品报表可视化工具、商业智能BI工具、可视化大屏等等。
一说到可视化解决方案，你可能会马上想到一些框架，例如ECharts、antv、chart.js、D3.js等。这些框架都是预设好的UI组件库，我们只需要根据业务需求创建出符合业务需求的可视化界面即可。
从技术角度来看，使用这些框架基本上不会有难度。从项目角度来看，可视化产品是公司自上而下的决策，有专属的团队负责，前端同学的职责就是按照项目管理流程来执行。换句话说，前端同学的主要任务就是实现可视化界面，其它的事情，我们不需要关心。
不过，实际情况远比这复杂得多。
如果是由前端团队提出并希望实施可视化监控需求，其他团队和角色可能对需求的理解存在偏差。例如，老板可能认为它对营收没有帮助，不必实施；业务团队可能认为需求价值不高，最好不做；但是，前端同学认为这能帮助快速解决线上问题，应该优先处理。那么，我们应该如何判断可视化监控的重要性呢？
可视化监控真的重要吗？
回答这个问题之前，我们先要搞清楚什么是前端全链路可视化监控。
可视化是将数据转换成图形或图像，在屏幕上显示。监控是指对系统、网络、应用进行实时监测和收集数据的过程。
因此， 可视化监控是采用图形化显示数据，通过图像帮助我们快速了解系统运行状态，以便及时发现并处理问题。
以错误信息统计为例，我们来看看它能带来什么好处。下面是一天中每小时错误总数的折线图。
从图可以看出，当天错误数的峰值是17条，出现在下午5点，而最小错误数出现在凌晨4点。
有了这张可视化监控的折线图，我们要做什么呢？是要每小时都检查错误有没有超过我们的预期吗？
但是每小时检查一遍似乎又太麻烦了，甚至影响工作和生活。既然这样，那要不加个阈值监控呢？一旦超过阈值，就发出一次预警通知，省心省力。
好，有了阈值监控，我就没有动力去看图表了，因为有了预警通知，我就可以去做更重要的事情了。而且，当真的出现线上故障发出告警通知时，接下来我应该是去查看日志，而不是去看图表，因为图表不能帮助我们定位问题。
那么，我们什么时候才需要看图表呢？
我觉得有两种情况。一种是在查找问题时，我们需要从全局的角度来看折线图，例如分析今天和昨天的数据，并且对比数据差异。另一种是，当我们在做复盘或汇报问题的时候，用图表可以更直观地展示问题，而不是一堆文字和数字。
通过这个过程，我们可以得出一个结论： 我们更关心问题发生的时刻。
也就是说，当产品出现故时，第一件事情一定是接收预警通知，然后才是去看日志和图表。所以，查看图表是一个主动的行为，要是频繁查看，就会影响到工作效率了。
如果一定要看，就在团队最显眼的位置摆放一台大屏幕显示器，放上日志监控的可视化图表，每个人经过的时候都能瞅一眼。这样，大家都能感受到监控的重要性了。
因此，前端全链路的可视化监控是很重要，但并不紧急。
可视化监控是重要不紧急
重要不紧急，说明可视化监控在项目中，不属于高优先级的事项，但又不能不做。
如果要做，对于前端团队来说，需要考虑的因素非常多，但主要原因有3点。
优先级不高，但不能不做
作为研发团队成员，我们总会遇到这样的工作难题：经常同时并行4个任务，例如 紧急需求、正常需求、线上问题、团队技术需求。
这就需要用到四象限法则这个时间管理的小技巧了。
通常， 线上问题 分为两种：线上故障和常规线上问题。线上故障是需要立即处理，因为系统已经无法使用了，这是非常重要且紧急的任务。常规的线上问题，比如用户反馈的问题，如果有其他解决方案，修复任务就不那么重要和紧急了。
正常需求任务 也可以分为紧急和常规两种。紧急需求通常是对时间有要求或突发性的需求，需要权衡在紧急和常规需求之间的做出优先排序。咱们的时间是有限的，无法同时完成两种需求。紧急需求虽然很重要，但并不一定非常紧急，不过优先级比常规需求高。
接下来说说 技术需求。假设把技术需求分为团队技术需求和可视化监控需求，那么可视化监控的需求优先级会更高。因为只要能够保障系统的稳定性，减少线上问题，团队就有更多的精力去完善系统和进行技术优化。
所以，可视化监控的需求比技术需求更重要，但它们都不是团队最紧急的任务。
最后，通过四象限图来表示这些工作任务的优先级位置。
也许前端同学会吐槽，紧急需求、普通需求和线上问题已经足够多，哪里还有时间去搞其他技术需求呢？
有这样的想法一点也不奇怪，毕竟我们的主要工作就是为了产品服务，需求和问题优先是常态。
我认为，是否要投入开发可视化监控以及如何做，都是优先级的问题。我有两点建议。
首先，团队需要提前制定好月度、季度以及半年计划，定期回顾工作，在工作中安排一些提效的工作。其次，善用70/20/10的方法来管理工作时间。尤其是10%时间，建议安排一些非业务需求的工作。
只有规划好计划和时间，即使优先级较低的事项，也能够一步步地朝着目标前进。
不会马上带来收益
前端团队想要执行可视化监控通常也是一件很困难的事情，主要有3个原因。
首先，从研发角度来说，可视化监控是需要投入人力和时间成本的，并且它的价值不会立即呈现出来。如果管理者或业务方认为需求没有价值，那么你的资源申请也会被拒绝的。
其次，从管理者角度来说，管理者需要从全局视角来看问题，他们需要通过评估问题的严重性来分配资源，甚至需要结合图表、问题和结论来进行复盘或报告。
最后，可视化监控是一件长期、持续的工作，需要不断根据业务的变化来优化可视化数据告警阈值。
其实，还有一种角色是值班人员，他们需要通过实时的可视化大屏幕来监控系统运行情况。
要真正解决价值收益的问题，我的做法是这样的。
- 与业务目标对齐，明确可视化监控对业务的价值和收益，例如通过减少线上问题来提升用户满意度，减少用户流失率，提升页面加载速度等。
- 要明白前端全链路的可视化监控是一件长期、持续的工作，要做好长期工作规划，优先确保快速发现问题，再进行可视化的工作。
总的来说，可视化监控是一个辅助发现和解决问题的工具，它的投入是长期的，因此它不需要立即安排任务。
业务变化的影响
我们都明白，产品业务总是在变化。用户量的提升和产品功能的增多等因素，都会影响可视化图表的波动和阈值的设定。
还有我们之前说的错误数统计，如果我们设置的阈值是10，每天大约会有2-3次告警。如果下个月因为用户量暴增，每天的告警频率超过10次，而我们认为这是正常现象，那就需要调整阈值来减少告警的频率。
再退后一步，我觉得前端团队自研一套可视化前端界面是不太现实的。人力和时间成本都是问题，而且开发一个可配置的可视化界面并非一时半刻能完成的。
那么，我们应该如何应对业务的不断变化，来调整可视化监控的需求，避免过多的资源投入？我有两个建议可以参考。
第一，如果一定要自研，我建议采用最小可行产品的原则，每次迭代都以最小的业务流程来满足可视化的需求。等业务稳定后，再来慢慢优化和改进成一个低代码的可视化插件。
第二，如果我们已经对接了第三方日志服务，我们完全可以直接使用它们提供的仪表盘能力。有了仪表盘，我们就能设定不同类型的图表来展示数据的状态。
不管怎样，业务的变化是无法避免的。对于前端同学来说，可视化监控的需求其实并不强烈，反而实时告警更加重要。
好了，虽然前端全链路的可视化监控的优先级不高，但这并不意味着我们不做。短期的工作可能无法快速带来价值，但我们可以通过一点一滴的努力，采用最小可行性原则和高效的方法来实现监控的目标，而不总是追求自主研发。
总结
总结一下，这节课我们明确了可视化监控的概念和重要性。对于前端全链路来说，监控的目的是快速发现问题，但可视化监控的价值并不明显，因此我们认为它是重要但不紧急的任务。
“重要不紧急”的原因包括优先级不高、短期无法产生价值和业务持续变化。因此，前端同学应该根据团队业务的实际情况来决定是否实施可视化监控。
在老板或管理者角度来看，解决问题的关键不在于图表做得有多精致，而在于能否快速发现和解决问题，包括解决问题的思路、方法以及速度。
因此，使用第三方日志服务和它的仪表盘能力，是实施可视化监控的最佳方案之一，同时还能提高监控的效率。
再次强调， 可视化监控是一件重要不紧急的事项，是一件长期性、持续性的工作，不管是个人还是团队，都要根据实际情况制定相应计划。
下节课，我们继续学习前端全链路监控体系中的告警功能。
思考题
现在给你布置两道思考题。
第一，不妨思考一下，这节课提到的可视化监控，除了它是一个辅助发现和解决问题的工具之外，你还会用过哪些工具来帮忙解决问题呢？
第二，文中提到的工作优先级排序，在你的工作中你又会怎么排序呢？不妨和我交流一下。
欢迎你在留言区和我交流。如果觉得有所收获，也可以把课程分享给更多的朋友一起学习。我们下节课见！