我还是无法忘记那个午夜，当 oncall 的告警响起

Hello，大家好！我是 Java 工程师蔡姬，此蔡姬非彼菜鸡！很高兴在这里和大家分享自己的观点和经历。

今天中阳老师给大家分享了什么是好内容，以及长期价值主义。

好内容首先是对别人有帮助的内容，帮助可以是情绪价值，读完你的文章感觉很愉悦，也可以实用价值，读完你的文章感觉有启发。当然，这一切都建立在内容准确可靠的前提下，它需要是易懂的，可读性好的。很重要的一点就是在产出内容的过程中和读者进行互动，接收反馈，并在后续的内容生产中进行迭代。很有一种把内容当成产品来做的意味。

而长期价值主义，在我看来则是能够鼓励自己坚持内容创作的动力。通过内容创作，我们不仅可以提升专业素养，还可以增加个人影响力，获得更多更好的职业发展机会，认识更多志同道合的朋友，比如正在一起参加行动营的你们，哈哈！这一切都将成为内容创作的动力来源。

总结完毕，接下来就是作业时间！今天，你打卡了吗 —— 最近一次工作中解决难点的经历：

在那个静谧的午夜，蔡姬的卧室被月光柔和地照亮。然而，这宁静被一场突如其来的告警所打破，让他从梦境中惊醒。匆匆起床，夜已深，而问题的谜团在他面前展开。

时光停留在某个工作日的午夜，地点是家中的卧室。蔡姬，作为这场夜间事件的主人公，迅速将自己卷入了一场系统问题的漩涡。

“张三”是一款面向 To C 场景的 Java 后端服务，而问题的核心是系统平均负载的逐渐攀升，最终停留在异常的高水平。这不寻常的现象成为了蔡姬深夜的谜团。

“张三”服务分布在多个线上集群，以 A、B、C... 为代号。A 集群只有一台实例，专用于线上验证；而 B、C... 集群则拥有多个实例，硬件配置均相同，每个实例独立部署。

迷雾的更深处揭示了问题的更多细节。异常的实例正是 A 集群的那一台。从某一时刻开始，这个实例的系统平均负载缓慢攀升，越过了预设的阈值，引发了警报。而其他集群的实例却依旧正常运行，没有受到此次事件的牵连。

为了解开谜团，蔡姬开始了系统排查的征程：

起初，他怀疑是不是有人在三天前提交了修改，将 A 集群单独部署用于验证。但历史部署记录显示上次改动已经是一个月前的事情。

转而，他将矛头指向了线上配置项的修改。然而，经过检查，最近并没有对配置项进行调整。

于是，他通过 SSH 登录到问题实例，查看日志，却发现并无异常或错误的迹象，请求依然能够得到响应。

负载均衡的配置也在排查范围之内，策略显示各实例均分。

然而，事情并未如他所期望的那样简单。通过 top 命令观察问题实例，他发现最近 1 分钟、5 分钟和 15 分钟的 Load Average 都持续维持在相对高的水平，但总 CPU 利用率却异常地低，不到 1%。更奇怪的是，没有一个进程占用高 CPU。内存使用状况则正常。

随即，他的怀疑又转移到了 IO 等待上。即便通过 top 命令找不到 "D"（不可中断）状态的进程，他并未停下进一步排查的步伐。

通过 vmstat 观察到，"r" 的数量持续大于 CPU 核数，结合低下的 CPU 利用率，他更加确信这是由等待 IO 导致的系统负载高。然而，这并未解释为什么 top 命令未找到 "D" 状态的进程。

在疑惑之际，他转向了 Arthas 工具进行排查。令人意外的是，他发现服务间调用延迟异常升高。他的怀疑目标直指网络 I/O。为验证猜测，他尝试更换机器，然而问题依然顽固存在。

最终，通过 Wireshark 工具的进一步确认，他确定了问题的根源——集群网络瓶颈。深夜的系统之谜得以解开，而他也因成功破解这一难题而获得了宝贵的经验。

以上。

我是 Java 工程师蔡姬，期待和同路人有更多的交流和思维碰撞！