“本文作者是曾有 4 年开发教训，期间负责过多个我的项目团队的开发 leader，现任 Kindling 开源团队的产品经理。作者曾因一次愚昧的操作引发了线上 P0 故障，导致月工资扣了 10%，年底绩效 -1，连带下级 leader 也被扣钱，全公司邮件通报批评，大型社死现场。作者想通过本人这次悲催的经验，通知一般开发同学如何实现在 10 分钟黄金时间内疾速排障。”
如果你问我是否见过凌晨 4 点的太阳？
我只记得已经在凌晨 1 点被生产环境的告警短信炸醒；
在凌晨 2 点被运维的电话喊醒；
在地铁上、演唱会上、火锅店里端着电脑查 bug；
……
P0 故障形容 & 排查过程
我置信很多很多一线开发同学对于上述场景深有感触，生产环境非乐土，各有各的苦，我过后背的这个 P0 故障景象是：晚 8 点咱们电商平台开启促销流动后，客服收到很多用户反馈说零碎响应特地慢，大量用户下单失败。咱们看到监控大盘和日志，没有报错和告警，接口响应工夫也没有什么稳定，然而咱们看到客户端呈现大量超时报错，所以狐疑服务 hang 住了，重启服务后，客户端短暂复原，5 分钟后又呈现 timeout 谬误。
面对“精彩纷呈”的 bug 们，咱们通常的惯例操作是：
- 看监控大盘，根底资源（网络、内存、并发量）等等是否有异样
- 查日志
- 查数据库
- 依据场景看测试 / 本地环境是否能复现调试
- 基建齐备的公司可能接入了 Trace 追踪，能够查 Trace 明细
- 寻求资深大佬的帮忙
我过后也用了这一套“组合拳”，查了一会无果，我真的是欲哭无泪。眼瞅着波及范畴面越来越广，其余一般订单也受到影响，P1 降级 P0，只能“壮士断腕”，立刻回滚。
是不是很诡异？如果是你接下来怎么查？
最初我只能依据本次迭代公布代码，和上一稳固版本认真比对变更，我置信很多开发都用过比对变更的代码内容去倒推故障起因的办法，小公布还好，但咱们这次促销流动是大迭代，变更量大，此操作费时费力。最初定位到起因是过后我在本地调试的时候自测某个场景，把服务器的最大线程数改的特地小，然而提交代码的时候没留神提交下来了，导致大量用户申请发过来之后，服务端线程资源不够，申请只能排队期待。做 code review 的 leader 也没留神，所以他的当月工资也被扣了 10%。而过后咱们的监控大盘也短少对利用所用线程池的要害指标的监控。
同一问题，怎么在 10 分钟内疾速排障
明天我模仿了过后的场景，接入 Kindling 程序摄像头 Trace Profiling 工具，能够看到用户在客户端感触到的慢申请如下图：
这个图怎么看？序号 1 线程是本次申请执行主线程，咱们能够看到本次申请，在 2 处就曾经被负责 IO 的的线程把申请流读进来了，然而在 3 处才开始由服务端的 task 线程真正执行解决。4 示意申请执行完结，IO 流近乎同时返回客户端这阐明申请慢是因为申请在排队期待资源，申请流 IO 进来的时候零碎没有足够的资源去解决它。而一般监控零碎对于服务响应工夫是从 CPU 执行计算这一刻开始的，所以这就造成了尽管客户端感知到了慢，但从服务端看起来还是惊涛骇浪。然而当年并没有程序摄像头 Trace Profiling 这个工具，10 分钟内基本查不进去，故障工夫越长，锅越大。
话说回来，程序摄像头工具的能力远不止此：
比方上图中的三角形图标就示意，此处有打印业务日志，并且点击后可在事件详情中查看；橙色的区块示意这是 net 事件，点击后也能查看报文，如果这个 net 事件是拜访数据库，咱们也能看到具体执行的 sql 语句 …… 也就是说，它把你须要查看的各种数据信息，都残缺附着在对应的线程上，保留下来。像以前咱们查日志都是登陆到日志零碎，依据工夫或者 TraceID 等关键字去筛选；查生产数据库的话还要走各种审批流程，等审批下来，饭碗都快没了。对于程序摄像头更具体的监控排障能力介绍可参考：eBPF 程序摄像头——力争解决可观测性畛域将来最有价值且最有挑战的难题
刚入行的时候咱们常常干出把本地调试代码误提交、merge 错分支、把他人的代码笼罩掉等等这些蠢事。排查问题也像无头苍蝇一样，尤其是遇到通过日志、或者本地复现都查不出起因的 bug 时，更是欲哭无泪。Trace Profiling 就是为了帮忙开发从与生产 bug“纠缠恶斗”中解救出来，它实在还原了程序执行现场，把 bug 的“立功证据”都收罗起来给你整顿展现。咱们前期会持续推出相干系列文章，以大家在生产环境中会遇到的常见故障场景为例，实现在 10 分钟黄金期内疾速排障。
Kindling 官网
Kindling 我的项目开源地址
有任何问题或者想退出 kindling 开源社区交换程序摄像头 Trace Profiling 工具的小伙伴，欢送分割小编～
小编
kindling 公众号