如何发现问题

如何发现问题

服务端开发实践分享

引入

过去，我们常常讨论：如何解决问题？

往往一个项目上线前，反馈很好，稳定性很高。

但是，上线后，卡顿、炸服、宕机，常有的事。

问题还是有的，只是我们没有发现。

没有问题，才是最大的问题。

换个思考方向：如何发现问题？

铺垫

问题被发现的来源：以bug为例

• 测试提单
• 用户反馈

这样子太被动，我们要化被动为主动。

目标：

• 在测试提单前，解决掉，不给测试提单的机会。
• 在产生影响前，解决掉，不给用户吐槽的机会。

做了哪些？

1. 提前沟通
2. 静态分析
3. 代码审查
4. 日志系统
5. 日志推送
6. 监控系统
7. 数据链条
8. 内部测试

一、提前沟通

主动提前去沟通需求。

思考：为什么要做这个需求？ 开发要学会如何决策。

程序对项目负责，不是对策划负责。

需求文档中最重要的部分：设计思考。

出发点：万物生于有，有生于无。需要改，请趁早。

二、静态分析

bug有多高级，原因就有多低级。

一次10分钟的检查，能规避掉很多因手误产生的bug，节约大量调试时间。

工具：Cppcheck、TScanCode、Luacheck

出发点：快速发现低级错误。

三、代码审查/Code Review

代码审查是真正的白盒测试。

没有经过代码审查，仅凭测试很难保证代码质量。

代码审查目的：相互学习。

找问题是副产品。

出发点：换一个角度看事物，避免思维定式。

四、日志系统

把日志打好、打全。

好的标准：针对简单的业务，能通过日志100%确定原因。

如果没有这一行日志，会不会影响定位问题？如果会，那就加上。

出发点：日志是调试的最佳利器，没有之一。

五、日志推送

在错误发生时，及时提醒开发，从而快速修复。

内网：信鸽 外网：Sentry

不同的场景下，选择不同的工具。

出发点：互联网服务 核心价值观之一：“不要我等”。

六、监控系统

基础层面：

如：机器、mysql、redis、process

业务层面：

如：在线人数、进程间的连通性、登录耗时、资源使用量

用途：压测、日常检查、报表输出

出发点：错误在一个时刻点看不出来，但在一段时间内就很明显了。

七、数据链条

客户端的表现，正常的；服务端的日志，也正常的；但是，数据就是不对。

原因：数据出错后，不会立即显现，需要过一段时间才会暴露。

记录所有的数据变化：结构化、统一化。

保证出问题时，可以回溯历史，获得出错时间点的上下文。

出发点：数据链，是环环相扣的。

八、Dogfooding / 内部测试

因微软而广为人知，一封题为“Eating our own Dogfood”的邮件，目的：提高内部使用自家产品的比重。

这个方法常被用来作为彰显对自家产品信心的手段。

在体验的过程中，发现了一些问题，尤其是细节上的处理。

本质：同理心。

出发点：如果打算让顾客买我们的产品，那么至少我们也要愿意使用这些产品。

效果

上面的这几点，是已经被验证过行之有效的，也是比较容易落地的。

实际上，一开始代码写的也有问题，只是提前发现了，然后及时修复了。

屠龙刀固然厉害，用的最多的还是菜刀。

核心

问题意识：发现在早 预防在先 解决在小

培养问题意识：

1. 发现问题的能力
2. 提出问题的能力
3. 分析问题的能力
4. 解决问题的能力
5. 总结问题的能力

发现问题的能力：防患于未然