前记
品质性能问题是大型软件的重中之重，本文从“发现问题、分析问题、解决问题、预防问题”的品质环节聊聊。
Part 1：发现问题
最直接的问题来源是用户反馈。处理问题总少不了畏难或者怕麻烦的情绪，但我们可以按照一定的方法论去拆解问题。首先问题是什么？（定义问题），从用户视角看本质只有这几个问题：
- P0 可用性问题：白屏（或者花屏）、崩溃、卡顿
- P1 性能体验问题：加载慢（耗时）、能耗（电量、发热）
- P2 资源占用高问题：内存、CPU、GPU、IO、磁盘占用、流量带宽
问题来了，先不要受外部压力干扰，从几点去评估问题的严重程度：
- 是否影响用户使用核心功能：即 P0、P1 的问题会直接影响用户使用
- 复现频率：频率高还是很低
- 影响范围：是一个用户还是多个用户
- 其他影响：影响用户付费意愿，KP用户
复现频率是压舱石，决定了问题能否排查出来以及问题严重程度。很多问题虽然很难排查，线索很少，但是复现频率很低，这类问题一般采取增加更多排查信息，等待后续复现的流程。
Part 2：分析问题
关于分析问题我总结的方法论是“事实、探索、假设、验证、推论”来缓解我在分析问题中的畏难情绪。
- “事实”是问题是什么，有哪些可观测的数据，比如 dump，trace，日志 等等。有多少事实才能得到多少推论。在 AI 时代之前，问题分析的上限是工程师的经验，有的时候还需要一些运气和灵感。在 AI 时代，问题分析的上限则变成了当前有多少事实。当然工程师的经验仍然重要，正确引导 AI 减少弯路，同时审查结论的正确性。
- “探索”即是做一些前置的调研，这个根据你对这个问题的了解程度决定，如果你很有经验，很可能就直接跳过这一步骤。相反你可能需要补充一些前置知识
- “假设”即提出可行性方案，这个问题有多少可能性，系统环境问题？三方软件问题？业务逻辑问题？
- “验证”针对每一个 IF 分支验证结论，保持中立
- “推论”根据验证结果得到推论，不管验证结论是否符合预期，得到的验证结论是否完整，而这是我们目前能得到的推论。
解决品质问题对于我而言经常有一个困扰：是不是我能力不足，所以我无法得到更精确的结论，是不是我不够仔细，所以忽视了什么更多的细节。但是随着处理更多问题，我逐步的发现问题结论的上限本质就是受约束于前面的步骤，更重要还是“事实”本身。问题分析经验固然重要，但是更重要的是有多少线索才能得出多少结论。有很多难以复现的问题就是受限于丢失现场，缺失线索而无法定位到根因，这是世界规律使然。
针对不同的类别问题，分析工具可能会更多，但核心的工具是这些：
- 日志：无疑是所有问题的初始判断开始，它能定位时间，关联业务逻辑，异常点附近的变化等等，但也仅限如此
- DevTools & Chromium performance：想要更多前端的细节，前端问题分析绕不开的两个工具
- Dump 文件：进程某一时刻的堆栈，适用于分析 crash，也可以辅助分析卡死问题。如果有 fulldump 可以更好去看变量值
- Trace 文件：进程一段时间的堆栈情况，etl 或者 instruments trace 、 spindump 里还可以看到等待链的情况，以及进程的 IO 更详细的性能使用
上面提到的是单个用户的问题分析，还有一类是对某个群体或者数据整体的波动的分析，这类问题需要关联多维度进行归因，必要的时候需要老一批典型特征的用户日志进行单点分析：
- 软件、系统版本关联
- 功能开关关联
- 用户设备负载关联（高CPU、高内存、高IO）
- 软件自身负载关联（高CPU、高内存、高IO）
- 用户设备参数关联（CPU核心数目，低端/中端/高端机型）
Part 3：解决问题
如果问题分析清晰，那么问题解决自然不成问题。但想要解决的好需要走的更远一些。
- 是否存在同类问题：解决一批问题
- 能否产生更多价值：比如上游贡献，沉淀分析过程进行分享
- 避免后续问题的出现：这正是 Part 4
Part 4：预防问题
到了最后一个小节，但本小节是构成品质工作体系的关键步骤。
Part 1 里主要介绍来自用户反馈的问题，但让我们先重新挖掘一些发现问题的所有阶段，以及针对这些问题设定可观测的手段：
开发阶段：
- Code Review
- 静态检查
- CI 性能指标巡查：Pinpoint
回归阶段：
- beta 告警
- 性能指标基线
线上阶段：
- 数据大盘：数据归因
- 线上告警
- 竞品评测
- AB 实验：分析某个优化对性能的改善
- 用户反馈：即 Oncall 机制
观测到问题后进入 Part 2 分析问题流程，最终进入解决问题和预防问题的链路，形成品质问题的收敛和不断增强。
后记
看到最后，也许会发现问题和预防问题本质没有区别，只有有更多的观测手段，才能更早拦截到问题。而问题分析和问题发现的差异也仅仅是对软件可观测的内容有差异而已。
简而言之，所有品质方向工作正是围绕软件的可观测部分展开，构成问题发现和问题解决的闭环而已。
本文简单介绍品质工作的一些整体思路，对于可观测性和问题分析具体步骤介绍的甚少，比如每个问题指标的定义、采集方式，又或是每个问题使用哪些工具以及分析流程。如有建议，欢迎指出。
