本周工作思考
- 部分前端库增加cursorignore文件的考虑
- 本周的处理线上问题和时候，把涉及到的仓库增加了cursor文件，主要是防止cursor的索引文件的时候去把安全敏感文件加到索引里面，这个事本身的处理比较简单，主要是从安全角度出发的考量。从Cursor的公布的技术文档上看，codebase会把编码后存储到其服务器上，本身不涉及到明文存储，不过其文档中也提示用户把敏感信息放在cursorignore里，尽管如此，cursor也不保证这类信息不会被大模型使用。
- 对我们来说，尽量保证敏感数据不直接存储在需要使用Cursor的代码库中，我们是自己的数据安全的第一负责人。
- 在MCP，A2A，各种Agent和各种大模型技术和工具井喷式出现的时候，各家工具商对用户数据的安全重视程度不同，特别存在很多黑盒的情况下，大模型如何利用这类敏感信息，我们只能按照这些供应商对外提供的协议或者技术文档上来的对策，或者说很多这些工具的提供商也没法明确，这就要求对数据安全有一定的敏感性和主动的防范意识。
- 本周Sentry问题排查进展
- 随着对Sentry使用深入理解，我们对Sentry的整体设置做了一些优化，增加了更多的Tag和用户信息，对Sentry的可观测性思想也有了深入的认知，在具体的使用上针对了基于umuI，企业ID，数据大盘都对用户的使用情况有了一定的观察和洞察，比如在遇到Issue时，我们可以判断用户是否还在继续使用，用户是否自我修复的能力，是否影响到了用户体验，用户的使用旅程到底是怎么样的。
- 在问题修复上我们已经进入对困难问题的修复阶段，这类问题往往没有具体的错误的代码位置，或者有具体的代码位置但不知道怎么改，还有就是改动影响较大，特别是视频类（视频小节，视频作业，音视频录制），文档类（文档小节，图文小节）这类问题涉及到比较复杂的技术和业务，虽然知道问题在哪，但是真正解决还要做不少的代码分析和排查。我们目前基于报错数量和遇到此类问题的用户数量排序做优先级，踏踏实实的解决好这类难点问题。
- 为了排查问题，除了和大模型聊，我也经常去翻阅网上相关资料获取去Sentry的论坛寻找一些线索和答案，我发现很多开发者也会面临着和我们一样的各类问题，大家通过Sentry或者其它工具都在不断地解决这些问题，不断提升各自公司的产品质量和用户体验，这也体现一个趋势：用户对互联网产品的质量和用户体验的要求是在不断提高的。
- Sentry问题的排查是一种事后解决策略，它的最好结果是减少损失，而不是避免损失。很多思考和经验也不断的提醒我们，重视事后解决的同时，更要重视事前预防，把需求理解透，挖清楚，代码设计好，大模型利用好切实提高业务和代码质量，这样才能让Sentry问题排查更有价值。