》本文作者拥有4年开发经验和期间参与过多个项目团队的开发负责人目前是Kindling开源团队的产品经理，作者曾因操作笨拙造成线上P0失败，导致月薪被扣10%，——年底表现1，上级领导也被扣分。全公司邮件批评，大规模社区死亡现场。作者想告诉普通开发同学如何在黄金时段10分钟内快速排错他自己的悲惨经历。“如果你问我，你见过凌晨4点的太阳吗？只记得凌晨1:00被生产环境的一条警告短信吵醒；凌晨2:00被运维电话吵醒；在地铁上、演唱会上、火锅店里用电脑查bug；……..P0故障描述&排查过程相信很多一线开发同学都对上面的场景感触很深。生产环境不是天堂，各有各的难处。我当时记忆中的P0故障现象是：我们电商平台晚上8点。促销开始后，客服收到不少用户反馈系统响应很慢，大量用户下单失败。我们看到监控行情和日志都没有错误和警告，接口的响应时间也没有波动。但是在客户端看到大量的超时错误，怀疑是服务挂了。重启服务后客户端短暂恢复，5分钟后再次出现超时错误。面对“高明”的bug，我们通常的套路是：查看监控面板、基础资源（网络、内存、并发）等是否有异常，查看日志，查看数据库，查看测试/本地环境是否正常可以根据场景进行复制。具有完整调试基础设施的公司可能可以访问Trace跟踪。可以查看Trace详情，也可以寻求资深大佬的帮助。我当时也用了这套“组合拳”。眼泪。眼看利差范围越来越广，其他普通订单也受到波及，P1升级到P0只能“被强人破”，立马回滚。是不是很奇怪？如果是这样，您接下来如何检查？最后只能按照本次迭代发布代码，仔细对比与之前稳定版的变化。相信很多开发者都采用过对比修改过的代码内容的方法来推断失败的原因。小发布还好，但是我们这次推广是大迭代，改动量大，这个操作费时费力。最后发现原因是我在本地调试的时候测试了某个场景，把服务端的最大线程数改的很小，但是我提交代码的时候没注意提交了代码。线程资源不足，请求只能排队等待。做codereview的leader没注意，所以他的月薪也被扣了10%。当时我们的监控市场还缺乏对应用所用线程池关键指标的监控。同样的问题，如何在10分钟内快速排查今天我模拟了当时的场景，连接Kindling程序相机TraceProfiling工具，在客户端可以看到用户感觉请求慢如下图：你怎么看这张图？序号为1的线程是执行这个请求的主线程。我们可以看到，这个请求在第2点已经被负责IO的线程读入，但实际上是由第3点服务器上的任务线程执行处理。4表示请求执行完成，IO流几乎同时返回给客户端。这表明请求很慢，因为请求正在队列中等待资源。当请求流IO进来时，系统没有足够的资源来处理它。而普通监控系统的响应时间是从CPU执行计算的那一刻开始的，所以虽然客户端感知到缓慢，但从服务端看还是平静的。但是当时没有程序摄像头TraceProfiling工具，10分钟内检测不到。故障时间越长，问题越大。话虽如此，程序相机工具的功能远不止于此：比如上图中的三角图标表示这里有打印业务日志，点击后可以在事件详情中查看；橙色方块表示这是一个网络事件，点击Afterwards，还可以查看消息。如果net事件是访问数据库，我们还可以看到sql语句的具体执行情况……也就是说，它把你需要查看的所有数据信息都附加到了相应的线程上，保留了下来。以往我们查看日志时，都是登录日志系统，根据时间或者TraceID等关键字进行筛选；在检查生产数据库时，我们必须经过各种审批流程。更详细的程序相机的监控和排查能力介绍，请参考：eBPF程序相机——努力解决未来可观测性领域最具价值和挑战性的问题。我们刚入行的时候，经常会做本地调试，误提交代码，合并错误的分支，覆盖别人的代码等等。排查问题就像一只无头鸡，尤其是遇到无法通过日志或本地复现发现的bug时，更是欲哭无泪。TraceProfiling就是帮助开发者摆脱与生产bug的“纠缠”。真实还原程序执行现场，收集所有bug的“罪证”，供您整理展示。后续我们会陆续发布相关系列文章，以大家在生产环境中会遇到的常见故障场景为例，实现黄金10分钟内快速排查。如果对Kindling官网的Kindling项目开源地址有任何疑问，或者想加入kindling开源社区交流程序相机TraceProfiling工具，欢迎联系小编~小编kindling公众号
