本周工作思考
- 构建自助问题排查系统的探索和思考
- 随着前端稳定性项目的推进，代码报错类问题已经得到有效的监控和解决，按照现在的方式继续深入推荐，不管是新功能上线还老功能的深度使用，都得到了有效的控制
- 目前项目的深入深入我们也注意几个点：一是我们目前没有完善自助问题排查工具，二是现在Sentry上的问题解决难度变大了，三是如何保持住这种治理效果
- 在技术上，前端上深度依赖浏览器的能力，比如富文本编辑能力、Fetch/Ajax为代表的短连接网络技术、以Web socket为为主要技术长连接能力、以Canvas为主要技术的前端绘制能力、音频播放能力、视频播放/字幕能力、视频录制/媒体管理能力、音频录制能力、PDF展示能力，需要和APP绑定使用的Webview技术，基于腾讯云和AWS的前端资源管理能力（Blob大文件上传下载等），当然这里还有其他的，比如部分功能会依赖web worker，webassembly，SVG，对浏览器来说，这些能力实现就是异常复杂，加之用户的环境千差万别，用户可能会遇到各种各种的问题，我们经常在Sentry上看到一个从来没见过的报错，观察一两周也就只有这一个报错，这类报错我们从现有的观测系统上判断用户是正常使用的，也就是说报错是偶然发生而且不影响用户的使用。当然也有一些这类报错，我们没法做出这样的判断，因为报错时间后，就没有相关日志了，我们没法判断用户是因为报错而无法使用了，还是在我们的观察窗口期用户只是没有使用而已，或者使用了，我们的日志因为未命中采样策略而没有上报，这类问题问题就是难度比较大的情况之一。还有这个报错频繁发生，但是因为报错是来浏览器的报错，或者没有任何代码信息和堆栈信息，我们也无法判断和排查这类报错，只能通过监控系统来判断这类报错有没有影响用户的使用
- 在和CO的伙伴们在问题排查问题的时候，特别是一些疑难问题，我也发现问题排查效率不高的情况，这类情况我以前认为是流程问题，后来我仔细观察发现，很多情况是的原因是客观的，首先客户反馈的问题不一定是及时的，CO的伙伴收到反馈，然后理解，确认，整理，这个过程的时间也是必不可少的，最后到工程师这边，工程师理解，复现，排查，定位，也需要一定的时间，如果是简单的bug，到这一步，后面就是bug修复发布流程，这个时间是可控的。目前不少问题是无法复现的问题，为了解决问题，需要寻找客户复现的潜在因素，可能就需要和用户这确认信息，这个中间又需要经过CO伙伴和用户，其中CO伙伴可能要理解一些基本的专业知识，比如浏览器兼容性，视频录制等，因为CO伙伴可能要给用户解释工程师为什么需要这个信息，这个信息怎么提供，这个信息是否是隐私数据等等。基于这些情况，我觉得优化流程流程并不能解决问题，真正要解决这类问题，就需要自主化的排查诊断排除工具，CSS伙伴不应该为解决这类问题而去理解浏览器兼容性，视频录制的这些知识，她们应该将精力用在如何维护好客户关系，深度挖掘产品的使用价值上，从这个角度出发，我们在修复Sentry问题的同时，也开始利用现有的经验和AI编程能力逐步的开发和完善一些问题排查工具，总结常见问题排查步骤，利用工具实现问题排查，省去中间不必要的沟通，从而提高整个团队的专业性和服务效率。