故障处置全流程之 coredump 场景

现状：coredump 导致的故障集中在策略算法团队的高频变更服务

从统计数据来看，coredump 主要集中在策略算法团队，且主要是几个核心的高频变更的服务上。从原因上也容易理解，在千行代码 bug 率保持不变的情况下，变更的次数多，错的机会相应也会更多，而集中在策略算法团队上，主要还是因为这些团队使用 C++的比例更高一些。

如何发现 coredump 导致的故障？服务可用性和 core 事件关联

首先，最有效和最直接的方法，必然是通过 coredump 的监控来发现，这样，问题和原因都清楚，止损方案也就较为明确。任何导致故障的问题，都会对业务指标造成影响，只是说业务指标异常你无法快速定位原因，再一个就是将问题扼杀在萌芽中，因此在此处，我们仅讨论如何更好的发现 coredump 报警。

coredump 监控的主要问题是：概率性的 coredump 场景可能无法触发 coredump 报警。该问题有如下的前置条件：集群规模较大，至少是几百台的规模，且 coredump 监控设置了防抖策略，例如连续 5 分钟都有 core，或者是在一定的时间内 core 的数量/比例达到一定的阈值才报警。如果只有两台机器，那基本上不会有这样的烦恼。

因此，我们可以采取 coredump 信息和服务可用性结合进行关联报警，从而减少上述的问题发生。服务 core 之后，会有一个将 core 信息 dump 到磁盘的过程，然后重启，因此，在这段时间内，该实例是不可用的，因此在 qps、请求成功率、请求耗时上都会有变化，大概有如下两种可能

• 服务全部 core 掉，那么 qps 掉 0，请求成功率掉 0，请求耗时掉 0

• 服务部分 core 掉，那么请求耗时会增加，qps 可能下降或者不变，请求成功率下降但不会掉 0

最终的解决方案：服务可用性报警关联 core 事件

变更时间的分析

• 回滚的变更事件查询范围，不仅仅需要关注线上，也需要关注线下，因为有的 case 就是线下连到线上导致的问题

• 变更信息的推送，不仅要推送变更信息，也要提供变更的执行人等信息，便于快速决策处置和一键拉群

• 变更事件应该分类，人工更新和自动化更新，有 5min 定时自动更新的配置，这个量较大，会淹没人工变更的信息

• 变更事件还需要包含数据类变更，数据是不是有新的生产和发布，例如索引的更新

• 配置出 core 的问题，还有可能是上下游的变更导致的

止损决策的分析

• 对于数据类变更，降级可能更加有效一些，因为重新生产、发布、更新数据的耗时会比较长，且可能涉及到服务重启

• 对于 coredump，可以分为两个 AZ，采取不同的策略，观察效果，加速止损

• 部分 coredump 的场景，不是回滚，而是直接删除数据，通过 pssh 的方式删除 &&重启服务（应该走降级，通过开关来解决）

• 对于降级操作，研发有些时候会填写回滚（对于 Kconf 的配置，很多时候关闭了，但写的是回滚，统计上需要注意）

• 短时间内无法定位原因，先降级，先停掉一些非必要的数据依赖，期间继续对 core 进行分析

定位的分析

• 容器云环境下的 core 分析，gdb 工具缺乏，也影响了定位时长

• coredump 文件的分析本身还是比较耗时和繁琐