人生总是充满惊喜，这次的故障排查就像一部短篇侦探小说 —— 表象迷惑，真相隐藏，转折不断。

平静的暴风雨前夕

2024年2月10日，这个本该平静的周末清晨，成为了一段意想不到的故障排查之旅的开端。

第一幕：蛛丝马迹

10:00，例行查看服务器状态时，1panel面板突然无法访问。有趣的是，博客和Navidrome服务看似一切正常，只是速度略显蹒跚 —— 现在想来，这个微妙的"略显"正是灾难的预兆。

SSH连接失败后，不得不祭出VNC大法。系统负载70%，看起来有点高，但也不至于触发警报。直到查看UFW状态时，一个意外的发现让整个故事出现了转折：

To                         Action       From
--                         ------       ----
22                         Reject       10.1.2.1

第二幕：真相浮出水面

原来，服务器的内网地址竟然被Fail2ban拉入黑名单！这源自于服务器当前的架构特点：服务器采用IPv4 NAT + IPv6独立IP的配置方案，平时的SSH连接都是通过内网端口映射实现的。

第三幕：峰回路转

当以为问题告一段落时，更大的挑战接踵而至。博客加载速度持续下降，Jetpack甚至发来了宕机警报。重启服务器后，情况不但没有好转，反而在GRUB引导界面石化了。

最终，上游服务商道出了真相：同一台机器上，有用户在5分钟内产生了超过500G的磁盘读写，导致服务器被强制停机。据说是在解压"颜色视频"，但如此惊人的IO量着实令人费解。

后记与思考

  1. 这次事件的复杂性在于多个问题的叠加效应，某种程度上干扰了问题定位的准确性。
  2. 硬盘滥用问题在两天后再次出现，15分钟内产生2T读写，真是令人费解的邻居。
  3. 7iNet的服务确实经济实惠，但对运维能力有较高要求。
  4. IPv6的应用现状：
    • 中国在IPv6推广方面反而强于欧洲
    • BT/PT追踪器仍主要依赖IPv4
    • 欧洲地区IPv6部署相对滞后
  5. 感谢 @piowonsler 提供的 IO 性能测试数据：
~> sudo hdparm -Tt /dev/vda1 

/dev/vda1:
 Timing cached reads:   15286 MB in  1.99 seconds = 7670.11 MB/sec
 Timing buffered disk reads: 100 MB in  3.01 seconds =  33.20 MB/sec
 ~> sudo hdparm -Tt /dev/vda1

/dev/vda1:
 Timing cached reads:   16274 MB in  1.99 seconds = 8165.37 MB/sec
 Timing buffered disk reads: 218 MB in  3.03 seconds =  72.02 MB/sec

总结

  1. 服务器监控：及时发现异常的重要性
  2. 安全配置：Fail2ban的误判问题需要注意
  3. IO监控：磁盘读写监控的重要性
  4. 网络架构：IPv4/IPv6混合部署的优劣权衡

Cherish those who deserve it.