往年的故障处理分析案例

在这五年我已经遇到了 300 多次网络故障，都已经是轻车熟路了。我也把以往的经历都总结到内部公司的知识库的。但我离职后也想把知识库拷贝到自己博客，不然以后那个云笔记的权限被回收了，我就没法查阅过往经历了。我就挑了近几年遇到的故障难题且不涉及内部架构的，单独挑出来说说吧。

**但是，我的总结可能未必是对的，可能有实际有出入，就当看个乐子就行了。**

## 网络故障

### 两芯损耗问题

现象： A-B 机房是有双链路保护的，但是某天突然有频繁的闪断现象，经过供应商抢修后损耗比以前大了 3db 左右，并且某一端的端口 CRC 一直在频繁增加中。

处理方法：供应商当时很偷懒不想修复，就让我们换模块解决，因为我们是 40km 的模块，换成 80km 确实可以缓解但本质下治标不治本。一直跟他们强调这个损耗问题，让他们报上实际双路由的物理距离，计算两芯光衰差值。计算后差值比较大几乎无法使用，因此以此数据可以说服供应商尽快优化。最终供应商在某个接入间发现光缆损坏，修复后恢复正常。

首先确定整条链路的光衰，对比两芯的光衰差值是不是一样。不一样的就与供应商沟通可能是差值较大的一芯。如果两芯没问题，可以问问供应商链路的实际传输距离是多少，该距离乘上0.3的值为正常的光衰，如果实际的值大于距离乘以 0.5 则可以用这个与传输商说“这边观察到该链路的光衰是XX,正常情况下光衰是不会大于XX,麻烦查看一下"。

#### 计算

**模块损耗的临界值**

- 40km 的收发光临界值：-16 dbm（收光）
- 80km 的收发光临界值：-24 dbm（收光）

**损耗范围**

- 光缆正常损耗 0.3db/km
- 可接受的损耗范围 0.6db/km

*一般可以用 0.5 db/km 来计算*

尾纤有两芯，可以理解成来的方向和去的方向。
假设 A - B 端检查有无损耗，我们就要比较 a 芯 与 b 芯的光衰差值，

- a 芯 = A端发光 - B端收光
- b 芯 = B端发光 - A端收光
- 差值损耗 = a 芯 - b 芯

假设 A - B 端的物理距离有 4km，利用差值进行对比
- 正常产生的损耗为 1.2 dbm
- 实际可接受的损耗为 2.0 dbm
- 超过 2.4 dbm 这个值就用不了，在 2.0 ~ 2.4dbm 看看有无可优化空间。

通过差值对比，可以判断究竟有无链路损耗，如果超过了损耗值就会出现异常。

### SYN_FLOOD 攻击

背景与现象：由于公司的 DDoS 防火墙是基于 16 年的华为防火墙，研发人员逆向研究了半年防火墙，做了一台可以部署在第三方服务器的检测清洗的防火墙设备。基本流量不大的攻击都能抵御得了。但自从某一年突然来了很大的流量攻击，攻击类型是 SYN_FLOOD。由于服务器性能有限，原来 100G 的攻击流量在防火墙只识别到 400M，一直没达到 2G 的阈值。而且 400M 的 IP 在排行榜也不是第一名，让值班人员误杀了多个 IP 也无法封堵成功。

处理方法：没办法，只能找电信的人在出口确认流量，确认有 IP 达到了 100G 的流量，封堵后故障解除。

此次 SYN 攻击影响非常巨大，长达一小时的出口网络瘫痪。事后故障总结的时候，SYN 攻击直接把公司的防火墙的 CPU 直接满负荷（1000 负载），检测防火墙已经形同虚设，导致"眼睛失明"。且攻击故障异常恐怖，值班人员通过 Netflow 抓包也无法第一时间获取所有数据包信息。对最终被攻击的客户服务器其实只有 10M 的流量，服务器扛得住，但我们的互联网出口无法成功抵御到。因此这次故障只能借助上游的力量来处理。

### 不起眼的错误包也是异常点

现象：有客户反馈一整个晚上网络质量不佳，一直存在丢包现象。接到报障后，值班人员检查了沿途传输的流量、光衰、网络质量与 CRC 均正常。最后逼得领导层，领导一查看是出口的错误包有明显上升，换了模块后就好了。

我们以前以为传输质量不佳就是传输存在 CRC，但是错误包跟 CRC 一样，出现数据错误的包也会重发的。然而当时经验不足，就没想到是因为这个原因导致异常。那时候都被领导骂的狗血淋头了。有些交换机没法拿 CRC 用来监控数据，因此在我们的 Cacti 中只能拿错误包当 CRC 监控。

该图实际上丢失包，但丢失包不影响网络质量，我没找到配图，你们就假装这条黄色线就是错误包吧。正常来说错误包应该为 0 才可以，如果有过突升或持续上升，说明传输质量有问题，必定是哪一端有损耗。

![](https://cos.lowb.ren/typecho/uploads/2023/10/4129076379.png)

此外，我也遇到接入层到汇聚层的链路异常问题，也是错误包。往往看到 A 端有错误包的话，我们就考虑更换 B 端的光模块或者换条尾纤是否正常解决异常。如果不行，也有可能是板卡的问题。

### 出口故障的依据

使用互联网出口，有时候拨测全国的 IP 都有问题，最开始的话肯定是用 `mtr` 进行故障定位，但 `mtr` 的资料在另一台电脑还没找出来我就不详情说了。简单来说，通过 `mtr` 测试对端 IP，看哪一跳开始出现 **连续丢包** （就是从这一跳开始到最后一挑的 IP 都大于 0% loss）或者往下不可达的话，这里就是问题点了。

看一个路由追踪图，我们要拆开数据来看

- 本地互联（本地路由）
	- 172.16.0.5 （NAT 网关或者其他设备）
	- 192.168.1.5（核心层地址，就当他是吧）
- 互联网出口互联（外网网关）
	- 172.88.1.1（运营商与我们设备的互联 IP）
- 骨干传输（沿途传输）
	- 5.5.5.5
	- 8.7.8.4 （随便输的）
- 对端内网互联（对端的网络环境）
	- 183.5.4.2 （对端网络的互联）
	- 183.5.4.80 （对端网络的网关）
- 目标 IP
	- 183.6.5.10 （对端 IP）

![](https://cos.lowb.ren/typecho/uploads/2023/10/46543684.png)

一般来说，出了本端互联后丢包的话，都属于外网的问题，包括骨干网与对端网络问题。因此通常如果有资源的话，我们也会在对端IP 测本地 IP 的路由追踪图，根据两份追踪图可以更准确了解具体问题点在哪。我大多数见到的运营商故障就分为 普通故障、省内故障、全国故障 这三大类。

当然，有些客户比较离谱，用移动的IP报障到电信有丢包，其实也能跟上游报障，但没法保证能修好，也有可能是电信的问题，也有可能是移动的问题。我们一般忽悠客户跨网无法保证稳定的网络环境，或者直接甩锅说是电信或联通的问题，嘿嘿。或者说，有些客户说你这个路由图怎么走到美国了，明明两端都是国内的IP。我只能说不要太相信 IP 归属地，有些互联 IP 不一定是公网 IP，而且 IP 可以任意 anycast 广播到其他 BGP 节点，所以只能当参考。

如果出口互联有问题的话，假设我们的出口是冗余的，不同的出口端口都有独立的互联地址，我们也要看清楚是哪个端口有问题，也许那个端口的流量已经掉光光了，但路由依旧走有异常的出口。

#### 还有，不要太迷信路由追踪图的 loss 值

有些客户就说，怎么这个骨干一直丢包呢？但看图下面都没连续丢包，`因为 ICMP 本身就是优先级比较低的队列，设备会优先处理其他高优先级流量，再处理 ICMP，所以这种 jitter 并不能说明故障`。这套说辞换通俗点来说，就是骨干设备为了性能会舍弃一些低优先级的数据包如 ICMP，因此不是真正的丢包。

### 有些 IP 突然无法访问外网

这种情况也有客户报障过，说自己的 IP 平日都用得好好的，下午突然没法用了，当时我们经验不足，网管又说检查不了问题，最后通过数据检查确实是网管做数据有问题。如果遇到这种问题，我一般这样确认：

1. 确认客户防火墙是否限制了（让客户做mtr，我们自己看）
2. 检查交换机的 QoS 策略中，ACL 是否正确放行了 IP（有些策略是通过 IP 进行限速的，有时候网管同事写错反码或漏IP）
3. 确认运营商路由是否正常（有可能回收路由做错了，如果交换机网关能ping通客户IP，外网不可以的话基本是这样）
4. 接笔记本或换 IP，确认究竟是否是设备系统异常。
5. 检查交换机是否做过 ARP 绑定，或者有可能 ARP 欺骗。（前者的话一般是割接没解绑导致，或者用户的安全狗做ARP保护了；后者的话就是中间人攻击，可以用交换机强制绑定）

基本遇到都是这样，排除自己的问题才好报障到上游，当然我也遇到过上游不给我们处理的事情，可能是钱没给到位。

### 一个环路导致整个网络的瘫痪

以前有过一例非常严重的故障，就是因为一个传输出现环路，导致从某市机房到其他机房的网络完全瘫痪。虽然不是我值班，但是一定要定位好故障问题点。

事件全貌我找不回来了，这个我要翻翻以前的记录才行。但是作为监控的话，故障来了会有很多告警，我们一定要抓住主要与次要的点。我们要关注的告警，如果是我的话我就会这样看

1. 查看日志，看故障来临的首个时间点来看。
2. 查看可能是问题点的告警，优先级：物理端口、环路、路由、虚拟链路。
	- 以前做了公网隧道，如果物理传输有问题的话，公网隧道也会有一堆告警，但虚拟链路是衍生告警，不是最主要的。
	- 环路会有环路保护（如果配置了），会自动关闭有异常的链路，除非没配置。但都是关键点，有环路导致数据包一直在循环乱成一锅粥。
	- 路由告警肯定会有一堆，但是可能物理因素导致的，跟第一条的隧道一样可能是衍生问题。
3. 看网络情况，全部节点有问题的话，那肯定是内部有问题，不可能所有出口有问题，除非大灾难来了。

当时值班人员整麻了，我介入了后才好分析问题，但无论情况多糟糕，要找到问题点，才好方便升级问题，不要当无头苍蝇，会耽误很多没必要的时间。

### 排障不仅抓宏观，还要抓微观

#### 注意核心层-汇聚层-接入层的流量

有时候看问题太过宏观了，反而没从微观角度寻找问题。

之前有客户丢包，我们太关注大网和出口流量，或者直接看客户的接入端口流量都很正常。值班人员一直查不出问题就跟客户说没事，但实际上我一查接入层到汇聚层的流量都跑满了，肯定会塞。相当于小出口的流量都瓶颈了。

#### 交换机也是有性能瓶颈的

不要以为交换机的几十 Tbps 就很无敌，也要关注 CPU 占用。

之前某个机房的有很多客户报障有丢包，我们也像上面一样，流量都关注没问题，mtr 看确实在内部有问题，但内部端口都正常，一直查不出问题。网管排障后发现，因为有客户流量比平时跑得高，但就只跑了 6G 而已，还没到端口 10G 的上限哦。然后偷偷给客户限速，发现丢包问题缓解了！

后面网管关闭了交换机的镜像流量，初步判定可能是板卡的端口只能处理 5G 的流量；也有可能镜像流量太大了，还是多个观察组，CPU 有点扛不住了。后面割接，换上更换的交换机，镜像流量使用物理分光器，不使用交换机的镜像功能。

#### 检查路由表哦

这里的路由表就是交换机的路由表，我一般在核心层或者出口层 `dis ip routing-table x.x.x.x` 查看下一跳地址是什么，检查是不是指空了，或者路由指到了不存在的设备。这些问题都是有过的，很多事情都是以前人为问题没有清理干净数据，交付的时候才发现有问题。

#### 直通的安全设备也是隐患点之一

为了安全，有些客户是部署了安全设备，例如安恒或者深信服这些。这些安全设备都需要做直通，就是所有流量一定要经过安全设备才可以。有些客户购买了我们的安全产品一年，所有流量都要经过虚拟防火墙，保证他们的安全。

但有一晚深夜，还好是我值班，其他同事值班完全不知道什么事。有个买了我们下一代防火墙的客户突然报障，问我们出口是否正常，今晚突然服务挂了一阵子。但我检查出口和传输都没问题。客户突然又说又挂了赶紧确认，我再检查下一点告警都没有。惹得客户都不开心（还好我是见过客户本人，比较好沟通）。

我想是不是安全资源池问题呢？因为客户他也认为可能是安全资源池的问题，刚好又故障复发了，这下子可以当场抓老鼠了。一登录我什么都不用看了，看到 CPU 和内存的图表都占满了，再通过客户今天的报障期间查了下历史图标。正好有异常的时候，图表的 CPU 和 内存都是高占用的。已经确认是安全资源池的问题。

深夜也没工程师鸟人，客户也扛不住先睡了。下一天客户让我们先取消引流并让我们上报给工程师。工程师看了下以为可能是客户有恶意流量，给他设置好安全策略好。第三天又复发了，刚好又是我值班，我也配合客户确认，CPU 又上升了。还好是白天班，工程师也一起确认了问题。工程师把 AF 进程导出给技术做黑盒测试。发现进程确实有内存溢出的 Bug 问题。修好了后客户就再也没问题了。

![](https://cos.lowb.ren/typecho/uploads/2023/10/2325723299.png)

所以路由追踪图的任何一个细节都不要放过。勿以善小而不为。

## 设备问题

### 交换机电源更换

现象：交换机出现掉电情况，但还好是双电源模块只坏了一个，但在实操中不知道如何更换。

双电源备份的其中一个电源掉电，如果电源是连接市电的话，理论可以不会受到影响，不过如果市电也断电的话，会单电源（UPS）能支撑的时间会少很多，或者直到单电源支撑不了了（电源模块2也坏了、哪一天机房又停电了UPS撑不住、UPS供电异常等等），后果将会不堪设想。当另一个电源也掉电，那交换机没有供电而停止工作，从而影响使用该交换机的客户。

如何更换呢？我们从命令行与实际情况确认究竟是哪个电源有问题。但一开始，先确认交换机信号，就像下面这台是 S6800，更换电源就要找兼容 S6800 的电源模块。命令输入 `dis version` 确认设备信息。

![](https://cos.lowb.ren/typecho/uploads/2023/10/1728339131.png)

实际去到设备面前，我们要看右侧的 `PWR` 有没有橙色灯。因为有些设备是做了热备或者 IRF，我们未必去对正确的设备，所以物理层的确认也是很重要的。如图所示，`PWR2` 灯就橙灯了，我们就要找到 PWR2 机子背面是哪一块。

![](https://cos.lowb.ren/typecho/uploads/2023/10/3723150694.png)

有些 6800 背面已经表明哪个模块是 PWR1/PWR2，但其他交换机可能未必会标记，会有一个箭头指着哪个是 1 哪个是 2。本来想配个图的，但我没存下来，网上文档也没标记，因此要从实际设备为主，肯定是有个标识的。

### 光纤模块

公司为了降本，一般能用库存的模块就用，没有的话就先拆掉空闲服务器的模块，拆东补西。导致有时候我借公司的服务器没有模块用，申请模块的时候又很无知，不知道单模和多模的区别。借了插进去识别不了，一直 UP 不起来，原来不同的模块也有兼容性问题。

服务器一般用多模的服务器模块（主要型号：Intel）；接线的话，交换机端接交换机模块，而服务器接服务器模块，不能混搭。同时除了模块，也要注意服务器有没有装网卡驱动，应用是否支持该厂商的板卡这些问题。以前我辛辛苦苦借到了一张博通的万兆网卡，结果部署应用一直起不来，后面厂家说只适配了英特尔的...

**多模和单模的区别**

- 单模适合长距离传输，传输速率要求高（长途传输等，适合长距离）
- 多模适合传输速率低，传输距离较短的网络（服务器都是用多模，因为短）

### 阵列或者一些厂商的存储

怎么做阵列我就不展开了。我就说下我遇到过关于硬盘的破事。

#### 预算充足的话建议不要上 Raid5

曾经有几台安全设备，以前的同事都给他们做 RAID5，RAID 5 的空间利用率比较经济，虽然坏一个盘还是能撑得住。但是实际上，我遇上几次掉一个盘，第二个盘也准备掉的问题（5盘组RAID5）。当初我们巡检可能不及时，或者真出现坏盘了，我们没法第一时间知道（R410 没有 IDRAC 或业务不重要），就一个坏盘冒红灯了，我们过了很久才知道坏了。

知道了后就赶紧换一块，REBUILD 完了以为可以收工了，没想到第二块盘也掉了，强制上线也不行。同事建议直接重做算了，反正数据也不重要，可以远程同步回去。最后直接重做阵列，全部硬盘换了，做个 RAID 1 放心点。

我还以为是个例，网上也有讨论 《[关于为什么RAID5往往掉一个盘后第二个盘也立刻挂掉的原因分析](https://www.bilibili.com/read/cv2384532/)》。大概就是说只要有一个扇区有问题，剩下的硬盘没法提供足够的 CRC 数据了，数据没法正常读取成功了。这篇文章分析很到位，因此建议能不RAID5就先不 RAID5。

#### 内存插槽

服务器的内存插槽不能随便插，拆下盖板，盖板背面就有一个内存说明图，按照顺序装内存才能成功识别。有些机房同事是新人什么都不知道，直接全部插上去，开机就 BIOS 报错了。

有时候想扩容内存，但不知道目前服务器装了什么内存条，频率多少都不知道。用 `dmidecode -t memory` 可以确认。

还有一个内存故障，可以查阅我之前写的文章：[硬盘不行就不要依赖 swap 了](https://lowb.ren/archives/dont-rely-on-linux-swap.html)

确实不能用 swap，别人 K8s 安装都要求不要开启 swap 了。

#### 不要省事（深信服 CSSP）

之前部署了一套深信服安全资源池，但是是第三方服务器，深信服只能提供软件上的支持。那时候在机房申请了几块 500G 硬盘凑个 2T 空间就先交差了。但部署完后，暂时没客户要用到安全资源池，就放置了大半年没管。去年九月的时候，有客户先申请使用，我本想着用旧的 CSSP 来交付，但领导说旧的要给钱，新的你不用？那我就索性在新的 CSSP 开租户给客户。

客户要求要 AF 和 日志审计，开完 AF 想开日志审计，但一直出错但又不告诉具体原因。问了厂商才知道，日志审计要预留 1T 的空间，但在服务器的硬盘虽然有 10 块硬盘，但要为了冗余与备份，实际只能用 1.5T 左右，系统又要吃一定空间，开不了哦！

深信服安全资源池都是单硬盘直通的，就是不需要做阵列，第三方服务器的话，所有硬盘都要单盘 Raid0 或者做 JDOB。当时我还以为要做阵列。比较麻烦的是，换硬盘都要重新做 RAID0，机房人员还比较水，还得接 KVM 让我远程操作。我也很水！我也是让同事一起看才放心做。

本以为再插几块硬盘就可以解决，但是！没硬盘槽了！！而且这大半年，系统已经坏了两块硬盘了！我用聊天记录的形式来回忆当时的情况吧。

##### 事情经过

> 我：李工啊，我们这 CSSP 还有救吗，能加硬盘来缓解吗？
> 李工：HCI 的硬盘扩容要保证全部硬盘正常才可以扩容哦！
> 我：那我先把坏的硬盘拆下来重建吧。
> 李工：你换好就直接点击 "硬盘修复" 来自助恢复数据吧。

我让机房更换好硬盘，其中有一块硬盘是 1T 的，直接在 HCI 重建硬盘，但是重建到一半报错了，也不知道原因。

> 我：李工啊，好像又出幺蛾子了，怎么报错了
> 李工：我让技术看看吧。可能要在后台强制上线哦，你新换上的硬盘没法恢复坏掉硬盘的数据哦。
> 我：没问题，反正业务还没上线，只开了一个模块。

李工让技术在后台重新上线，都重新恢复上线了。但有个问题还没解决，还是不够空间啊！

> 我：李工啊，我更换了一块硬盘是 1T 的，正常来说能多出 500G 够开模块吧，怎么 HCI 的总空间还是 1.5T 呢？
> 李工：啊，如果你之前的硬盘是 500G，那你的 1T 硬盘重新上线后只能当 500G 用，因为元数据是当这块 1T 硬盘是 500G 的哦。
> 我：我超，辛苦半天瞎折腾！

那段时间客户一直催着问日志模块开好没，要开始等保了啦！我都有点想逃避了，不知道怎么回客户。想了想...客户的业务也没正式用，那就亡羊补牢吧，直接重新部署 CSSP 吧！骗客户说要升级安全资源池版本，实际上也是升了，一举两得。

> 我：李工啊，要不要加个班，我想定个时间重新部署安全资源池，顺便升个级吧，从根本上解决问题，不然客户多了也撑不下。
> 李工：对啊，太折腾了，重新做呗，我去申请个加班费先。

![](https://cos.lowb.ren/typecho/uploads/2023/10/1559793559.png)

这次我直接借了几块 1T 硬盘，总空间到 5-6T，这下用到公司倒闭也可以，从根本上解决了问题。取消引流，找到 USB-KEY，重新配网，重新导入模块的数据，搞定了~

所以搞项目一定要想得长远一点，我这次确实太省事没有考虑到这些问题。

## 沟通的艺术

沟通这块一直是我的软肋，有时候电话沟通的时候太紧张，或者太直白，或者听得大家一头雾水。所以我才玩 VRChat 来训练自己的沟通，也在做了一年的服务台才知道怎么更好的沟通。

1. 开头一定要先自我介绍，不要先问对方是谁谁谁
	- 人家以为你是诈骗电话会挂。最好先说我们是哪家公司，让客户马上想起是跟他有关的。（因为固话没有归属地）
2. 客户很急也不要跟他一起急，故障已经发生了就要有条有理来处理
	- 故障已经发生了，我们不是神仙，没法下一秒立刻能处理完。所以要好好安慰客户，把手里知道的情况跟客户说说，骗一下也行，至少让他看到点眉头。如果自己也急了，很难静下心去处理问题。
3. 说话不能说太直
	- 这是我一直的老毛病，最近面试也是一样，不会圆滑，我家人也在说我这个诟病。其实我也意识到，就是因为自己急了想到什么就说什么，不经过加工就说出来。
4. 沟通一定要有思路，方便自己全面了解事件全貌
	- 一定要避免这种情况，想到什么就问客户，显得自己很没条理，客户也嫌烦。
	- 帮客户处理故障一样，首先问清楚，什么现象、时间点、路由追踪图、持续时间、源IP目的IP，有没有做过什么特殊操作等等，先把这些基础问题甩给客户，方便我们上报问题。可能有些问题就是客户自己的问题，我们啥都不知道直接上报到供应商，供应商就觉得我们很 low-level . 
5. 大家都是人
	- 不要因为对方的身份多高就畏惧，很多事情能正常沟通的，自己不要害怕。
6. 立场要坚定点
	- 不要太优柔寡断，明明是对方的问题，自己却被客户的无理解释说服了。到头来还是客户或者供应商有问题，会让自己很憋屈。

## 最后

有一些小故障我就不单独拿出来讲，我都忘了，或者不值得说。

多多总结与反思，做自己的知识库，这样温故而知新，更好的了解过去，应对未知的未来。

往年的故障处理分析案例

1 条评论

评论已关闭