很多系统出事故之前，看起来都很正常。

服务器亮着绿灯，交换机没有告警，业务系统能登录，CPU、内存曲线也没什么异常。

甚至每天的巡检表上，可能还整整齐齐地写着两个字：

正常。

直到某一天，一根光纤断了。

接入交换机与核心网络失联，下面十几台服务器同时掉线；服务器访问不了存储，虚拟机跟着中断，业务系统一个接一个出现异常。

大家开始冲进机房、查日志、打电话、联系厂商。

最后发现：

设备其实没坏。

真正的问题是——这条链路从设计之初就是单点。

这也是运维工作中最值得警惕的一件事：

“现在能用”和“出了问题还能用”，完全是两回事。

所以，真正有价值的运维检查，不能只看设备有没有红灯，也不能只问业务能不能访问。

要往深处查。

我更愿意把它总结成五个字：

五查

查硬件、查软件、查网络、查供应链、查管理。

它们查的不是五张表，而是一个信息系统从“设备”到“人”的完整生命链条。

一、查硬件：不要只看“坏没坏”，更要看“坏了怎么办”

很多人的硬件巡检，是这样的：

服务器电源正常。

磁盘正常。

交换机正常。

存储正常。

UPS正常。

于是得出结论：

硬件正常。

但真正应该问的问题，其实是：

如果现在坏一块，会发生什么？

比如一台服务器有两个电源模块，但两个电源插头最后接在同一个PDU上。

看起来是双电源，实际上还是单点。

服务器有两张网卡，但业务只配置了一张。

看起来有冗余，实际上另一张只是摆设。

两台交换机都买了，但服务器所有链路全部接在其中一台。

设备数量翻倍了，可靠性却没真正翻倍。

所以“查硬件”，至少不能只检查设备健康状态，还应该检查：

电源有没有冗余、链路有没有冗余、磁盘有没有冗余、关键部件有没有备件、设备有没有超过生命周期、故障后能不能快速替换。

运维最怕的不是设备坏。

硬件本来就一定会坏。

真正危险的是：

我们明明知道它迟早会坏，却默认它永远不会坏。

二、查软件：系统今天能启动，不代表明天还能安全运行

软件的问题比硬件更加隐蔽。

一台服务器可能连续运行三年没有重启，看起来稳定得不得了。

但你仔细一看：

操作系统早已停止支持；

数据库版本已经进入生命周期末期；

Nginx几年没升级；

Python、中间件存在一串历史漏洞；

虚拟化平台版本落后多个大版本；

甚至软件授权什么时候到期，都没人说得清楚。

这类问题有一个共同特点：

平时几乎没有感觉，出事的时候往往一起算账。

所以“查软件”，不能只问：

“这个软件现在能不能用？”

而应该继续追问：

它是什么版本？

有没有高危漏洞？

有没有补丁？

厂商还支不支持？

授权什么时候到期？

配置有没有备份？

升级失败能不能回滚？

系统崩了之后能不能重新部署出来？

特别是基础平台。

操作系统、数据库、中间件、虚拟化平台、云平台、容器平台，这些东西平时安安静静躺在底层，业务部门甚至感觉不到它们的存在。

但底座一旦出问题，上面的业务往往一个都跑不了。

越是不被业务感知的东西，越可能是最不能出问题的东西。

三、查网络：最大的风险，往往藏在那根“从来没断过”的线里

网络是最容易产生“虚假安全感”的地方。

一条链路运行了三年，从来没有断过。

于是所有人慢慢接受了一个事实：

“它应该不会断。”

可对于网络运维来说，这句话本身就很危险。

因为网络设计真正应该考虑的，从来不是：

它会不会断？

而是：

它断了以后，业务还能不能跑？

核心交换机是不是双机？

接入交换机是不是双上联？

服务器是不是双网卡？

存储网络有没有冗余？

管理网络和业务网络有没有合理隔离？

一台交换机故障，会影响多少服务器？

一根光纤中断，会影响多少虚拟机？

一个核心节点宕机，会不会导致整个区域瘫痪？

这些问题，单靠每天Ping一下IP是查不出来的。

Ping通只能证明：

这一秒，它是通的。

却不能证明：

这个架构是可靠的。

所以网络检查最重要的一件事，就是寻找两个字：

单点。

单核心、单上联、单网卡、单电源、单出口、单存储路径……

很多重大故障，并不是发生了多么复杂的技术问题。

恰恰相反。

它可能只是：

一个最普通的设备坏了，而整个系统没有给它第二次机会。

四、查供应链：设备买回来只是开始，不是结束

这一项，是很多技术人员最容易忽略的。

我们习惯研究CPU、内存、带宽、IOPS，却经常忘记另外几个问题：

这台设备是谁采购的？

原厂维保到什么时候？

软件授权什么时候到期？

坏了以后找谁？

有没有备件？

厂商还能不能提供这个型号？

操作手册在哪里？

密码忘了怎么恢复？

如果设备已经停产，替代型号是什么？

甚至还有一个非常现实的问题：

凌晨两点出了故障，厂商电话到底打给谁？

如果这些问题回答不上来，那么这套系统在管理意义上，其实还没有真正进入“可运维”状态。

尤其是运行五年、八年甚至十年的信息系统。

最危险的未必是今天设备坏了，而可能是：

设备坏了以后才发现——

型号停产了。

备件没有。

维保过期了。

原来的厂商人员离职了。

授权文件找不到了。

甚至当初负责采购和建设的人都已经换了岗位。

这时候你才会发现：

供应链，本身就是可靠性的一部分。

五、查管理：前四项的问题，最后往往都会追到这一项

这是“五查”里最容易得罪人的一项，却可能也是最重要的一项。

因为很多事故复盘到最后都会出现类似的问题：

为什么单点链路长期存在，却没人提出整改？

为什么设备维保过期半年，没有人发现？

为什么软件存在高危漏洞，没有升级？

为什么配置文件没有备份？

为什么监控已经告警，却没有人处理？

为什么发生过一次的问题，半年后又发生第二次？

这些问题已经不是单纯的技术问题。

而是管理问题。

资产有没有台账？

系统有没有责任人？

账号权限谁负责？

配置有没有定期备份？

变更有没有审批？

巡检到底是在真正检查，还是在机械打勾？

告警有没有闭环？

故障有没有复盘？

整改有没有责任人和完成期限？

同类型设备有没有举一反三？

应急预案到底演练过，还是只存在Word文档里？

一个成熟的运维体系，最重要的能力不是“永远不出故障”。

这几乎不可能。

真正重要的是：

同一个坑，不要掉进去第二次。

五查真正查的，其实不是设备

把这五项重新放在一起：

查硬件——设备会不会成为单点。

查软件——版本、漏洞和生命周期有没有失控。

查网络——一条链路、一台设备故障会不会扩大成系统级事故。

查供应链——出了问题以后，有没有人、有备件、有授权、有技术支持。

查管理——这些风险到底有没有人发现、有人负责、有人整改、有人闭环。

你会发现：

所谓“五查”，表面上是在检查五类对象，实际上是在回答同一个问题：

如果明天真的出故障，我们准备好了吗？

这才是运维检查真正应该回答的问题。

别让“全部正常”，成为最危险的巡检结果

我一直觉得，运维领域有一句很值得警惕的话：

“目前运行正常。”

这句话当然没有错。

但如果一份巡检报告从第一页到最后一页全是“正常”，反而值得再看一眼。

因为一个运行了几年、几十套系统、几百台甚至几千台设备组成的信息环境，不太可能真的没有任何风险。

没有发现问题，有时候并不代表没有问题。

也可能只是：

检查的深度还没有碰到问题。

真正高质量的巡检，不应该只是证明系统今天还能运行。

而应该主动去寻找那些：

今天没有发生，但一旦发生就会让我们措手不及的事情。

所以，与其每天机械地问：

设备正常吗？

网络正常吗？

业务正常吗？

不如再多问一句：

如果它现在坏了呢？

顺着这个问题继续往下查。

查硬件。

查软件。

查网络。

查供应链。

查管理。

最后形成风险清单、责任清单、整改清单，逐项销号。

这可能才是“五查”最大的价值。

因为运维真正的水平，从来不是事故发生以后，多少人连夜冲进机房抢修。

而是有一天，一根光纤真的断了、一台交换机真的坏了、一块磁盘真的掉了——

监控弹出一条告警。

业务依然正常。

运维人员看了一眼：

“知道了，冗余已经切过去了，明天换。”

那一刻，可能才是一个运维体系真正成熟的样子。