如何发现问题
服务端开发实践分享
引入
过去，我们常常讨论：如何解决问题？
往往一个项目上线前，反馈很好，稳定性很高。
但是，上线后，卡顿、炸服、宕机，常有的事。
问题还是有的，只是我们没有发现。
没有问题，才是最大的问题。
换个思考方向：如何发现问题？
铺垫
问题被发现的来源：以bug为例
- 测试提单
- 用户反馈
这样子太被动，我们要化被动为主动。
目标：
- 在测试提单前，解决掉，不给测试提单的机会。
- 在产生影响前，解决掉，不给用户吐槽的机会。
做了哪些？
- 提前沟通
- 静态分析
- 代码审查
- 日志系统
- 日志推送
- 监控系统
- 数据链条
- 内部测试
一、提前沟通
主动提前去沟通需求。
思考：为什么要做这个需求？ 开发要学会如何决策。
程序对项目负责，不是对策划负责。
需求文档中最重要的部分：设计思考。
出发点：万物生于有，有生于无。需要改，请趁早。
二、静态分析
bug有多高级，原因就有多低级。
一次10分钟的检查，能规避掉很多因手误产生的bug，节约大量调试时间。
工具：Cppcheck、TScanCode、Luacheck
出发点：快速发现低级错误。
三、代码审查/Code Review
代码审查是真正的白盒测试。
没有经过代码审查，仅凭测试很难保证代码质量。
代码审查目的：相互学习。
找问题是副产品。
出发点：换一个角度看事物，避免思维定式。
四、日志系统
把日志打好、打全。
好的标准：针对简单的业务，能通过日志100%确定原因。
如果没有这一行日志，会不会影响定位问题？如果会，那就加上。
出发点：日志是调试的最佳利器，没有之一。
五、日志推送
在错误发生时，及时提醒开发，从而快速修复。
内网：信鸽 外网：Sentry
不同的场景下，选择不同的工具。
出发点：互联网服务 核心价值观之一：“不要我等”。
六、监控系统
基础层面：
如：机器、mysql、redis、process
业务层面：
如：在线人数、进程间的连通性、登录耗时、资源使用量
用途：压测、日常检查、报表输出
出发点：错误在一个时刻点看不出来，但在一段时间内就很明显了。
七、数据链条
客户端的表现，正常的；服务端的日志，也正常的；但是，数据就是不对。
原因：数据出错后，不会立即显现，需要过一段时间才会暴露。
记录所有的数据变化：结构化、统一化。
保证出问题时，可以回溯历史，获得出错时间点的上下文。
出发点：数据链，是环环相扣的。
八、Dogfooding / 内部测试
因微软而广为人知，一封题为“Eating our own Dogfood”的邮件，目的：提高内部使用自家产品的比重。
这个方法常被用来作为彰显对自家产品信心的手段。
在体验的过程中，发现了一些问题，尤其是细节上的处理。
本质：同理心。
出发点：如果打算让顾客买我们的产品，那么至少我们也要愿意使用这些产品。
效果
上面的这几点，是已经被验证过行之有效的，也是比较容易落地的。
实际上，一开始代码写的也有问题，只是提前发现了，然后及时修复了。
屠龙刀固然厉害，用的最多的还是菜刀。
核心
问题意识：发现在早 预防在先 解决在小
培养问题意识：
- 发现问题的能力
- 提出问题的能力
- 分析问题的能力
- 解决问题的能力
- 总结问题的能力
发现问题的能力：防患于未然
标签：发现,审查,出发点,代码,问题,如何,日志 来源： https://www.cnblogs.com/txtp/p/16626696.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。