工程师如何反馈、排查与解决问题

反馈问题

• 一般的流程
  • 平常业务开发上线以及服务维护的过程中，我们写的服务可能总是有这样或者那样的问题，有些是产品考虑不周导致出现问题，有些是技术实现有问题，又或者是线上环境问题
  • 这个时候，各路人员都过来反馈问题了，说这个地方不对，显示的东西不正常，那个地方点不了，跟预期不一致
  • 然后一般我们能怎么做呢？就问反馈的人，是哪个页面，怎么访问的，然后具体的交互和行为是怎样的，然后我们就根据反馈的步骤，尝试去重现
• 是否能够更好的地来反馈问题，帮助后续的问题排查呢？
  • 一般我们提供服务，用户遇到问题也是会反馈问题的，做的比较好的公司或者产品，其实是会提供 FAQ 以及反馈问题的模板的
  • FAQ 是帮助理解这个服务或者产品的一些常见异常情况，而反馈问题的模板则是为了在收集反馈时让用户把必要的信息都提供出来
  • 类比这种方式，我们可以有些借鉴
• 更好地反馈问题
  • 类比 FAQ
    • 其实是我们应该对产品的提供的功能有个基本的了解，了解它可能的一些异常情况，才能确保说我们反馈的问题不是一些就是正常的一些产品现象
  • 类比问题模板
    • 其实就是要把问题说清楚
    • 一般我们描述一件事情的时候，需要说清楚时间、地点、人物，还包括事件的过程，如何开始的，发生的整个过程以及最后产生的结果
    • 对于技术问题来说，我们可以把问题的细节讲得更清楚，那我们要讲清楚哪些细节呢
  • 反馈示例
    • 前端、App问题
      • 哪个页面、如何进入的这个页面、操作是怎样的、期望的行为是怎样的、现在出现的现象又是怎样的，使用的是那种操作系统，是什么浏览器，浏览器的版本是什么，App的版本是什么
      • 可以的话，最好提供截图或者交互的视频
      • 对于 Web 页面、H5页面而言，最好能把对应的网页地址发出来
    • 接口问题
      • 哪个接口、如何访问的（从App/Web/命令行）、传了哪些参数、接口期望的返回是怎样的，出现问题时，接口又是怎样返回的
      • 同样，也要将具体的接口地址提供出来
  • 重点
    • 反馈问题是为了让查问题的人能够尽快去定位问题、然后解决问题
    • 提供网页、接口地址时，一定记得发出文本链接，不要发截图
• 其他
  • 有种情况是，非技术人员的问题反馈问题，这个时候，很难要求他们像上面描述得那么详细的，这个时候我们就需要去尝试引导他们，把我们需要的细节他们都提供出来
  • 作为老板，反馈问题时可以直接说那个页面有问题，访问慢之类的；但是作为几个技术人员，简单这么说就是显得非常的不专业了，我们是那些个需要后续排查、解决问题的人，我们应该把需要的信息说清楚，方便他人，也方便自己
  • 反馈问题，本质上是个沟通问题，能把问题沟通清楚最重要

排查问题

• 当我们收到一个问题的反馈之后，就要开始来定位问题、排查问题，那我们排查的思路应该是怎样的呢？
  • 首先，先明确到底是什么问题：这个真的是个问题吗，还是只是一个正常的结果，只是不常见；这个问题是用户操作不合理导致的，还是真就是Bug；确认是问题，那就要去明确是代码问题，还是设计问题，还是某个具体的 JS 的问题或者 CSS 问题等，或者接口出错的问题
  • 之后，尝试重现问题：一个无法重现的问题，我们一般不能称之为问题，只有能重现了，我们才能说这是个问题，我们才能往下去排查问题的原因在哪；但问题不能重现不能成为我们不去排查问题的理由，需要想办法去重现，通过反馈的问题的细节和积累的经验来推断、尝试重现问题
• 问题重现之后，我们该怎么办
  • 排查问题不能说靠去线上 debug 来去定位，如果是在没办法了，这也是一种方法；但一般来说是不靠谱的，很可能还会影响到线上业务
  • 我们需要提前准备好排查问题需要的工具
    • 监控
      • 基础设施的，比如机器的 CPU/内存/负载，数据库的CPU、内存使用率，负载均衡的新建连接数、并发连接数等
      • 应用的，比如CPU、内存、线程数、协程数、GC次数、接口响应时间等
      • 业务的，比如一小时内产生的登录数、订单数、某个业务的访问量等
    • 日志
      • 开发人员需要通过日志把程序里的一些特殊行为、异常行为记录下来，帮助来排查问题
      • error 日志、warn 日志、info 日志等
      • 有条件的话，还可以基于日志做监控
    • 链路追踪
      • 当系统足够复杂或者依赖的服务太多时，要定位一个问题很麻烦
      • 链路追踪的好处就是能帮我们直接定位接口的时间主要消耗在了哪个服务的哪个过程里，会节省很多的时间
    • 拨测
      • 接口拨测，模拟用户的行为，提前或者和用户同时发现问题
      • 面向业务过程的更好，比如一个完整的登录和退出的流程，支付和退款的流程
  • 有了这些提前准备的工具之后，大部分时候，通过监控、日志、链路追踪我们可能就已经能知道问题在哪里了，所以，工欲善其事必先利其器，做好这些准备是很重要的
• 当然，排查问题，有些疑难杂症，还是得靠经验，当一个人有很多排查问题的经历之后，可以对很多问题进行预判，然后很快地定位到问题

解决问题

• 这里说的是解决问题，不是修复Bug，需要明确这两者的区别，修复Bug只是解决问题的一种方式，核心是要解决问题
• 当我们明确问题之后，根据问题的优先级，主要是看重要程度与紧急程度，如果是重要且紧急的问题，则要马上解决，如果是不重要且不紧急的，则慢慢解决
• 解决问题的时候，优先要考虑的是，恢复业务或者说恢复服务的正常，如果对应程序的Bug很快能改好，则改完马上上线（也要看各个公司的发布流程），如果Bug不好改，则需要思考能否有其他方法来规避这个问题，暂时让系统恢复正常
• 解决完问题之后，很重要的就是懂得去复盘这个问题，弄清楚产生的原因，从中学到教训，避免下次再犯同样的错误，尽量做到不贰过
• 如果是碰到不会的问题，学会寻找他人的帮助，不管是自己的同事、上级还是外部的人