本文是对2018年8月9日公司邮件系统邮件流故障的故障发现、故障处理和故障修复过程的一个记录和总结反思。帮助自己总结经验，吸取教训，同时也作为一个反面供其他运维或管◆理员学习的教材。

故障排除

昨天下午 18:50 左右完成了团队的培训分享会后，我收到了同事的反馈，他们有几个无法接收外部电子邮件（上图）。好的，但无法接收外部邮件。

因为公司的邮件系统是公∴司自己搭建的，所以需要自己运营和管理。测试了几个外部邮箱后，发现确实无法接收外部邮件。这些外部邮箱包括网易、阿里企业邮箱和微软邮箱。

因为邮件服务是企业的核心服务之一，有同事反映遇到卐了问题，这个故障应该是重要的紧急故障，必须尽快排除才能恢复服务。

注1：问题严重或有应急处理流程的，应向上级报告，并按流※程下达通知。

注2：以下是个人观点和经验总结，如有错误请指出。

故障排除

面对故障，最重要的是尽快通过排除法进行故障排除，以最快的速度恢复服务。所以首先要做的是排除故障。由于已经是下班时间，事故⊙虽然严重，但尚未造成重大影响。

特别是由于缺乏亲身的运维经验，凭经验不能一下子发现问题服务器运维，只能根据以往的经验和结合一一〖检查。

经初步测试，内部邮件收发正常，内部到外部邮件正常，但接收异常。于是开始下面的调查。

在进行故障排除之前，有必要了解最近】的更改，例如软件配置以及导致更改的操作，尤其是当两个或多个管理员共同管理时。因此，服务器由一个人管理，最近没有进行○任何更改。是突然出现的问题，所以我直接开始排查：

检查域名解析，查看mx记录是否有问题。使用该︾命令在多个外部服务器上测试 MX 记录，以及相关的 A 记录和 CNAME 记录。

注1：服务〗器可以使用-q=直接查询，Linux命令需要交互查询，即先执行再setq=mx或=mx，再查询

注2：查询mx记录时，只需要查询邮件服务器fqdn域名的上级域名即可。例如，您只◤需要查询 mx 记录。

经排查，排除域名解析问题。

检查外部和内部通信问题，检查防火墙阻塞和防火墙与服务器之间的网络链接问题。使用25命令检查25端口的开放情▆况，经测试排除防火墙问题。

注1：25端口是约定的接收外部邮件的端口

注2：如果25端口正常，目标是邮件服务器，应该提示“,:43:58+0800”。

要确认它不是防火墙或网络设备错误，请重新启动防火墙或网络设备。通常，没有软关机和重启功能的防火墙需要断电或切ㄨ换电源状态10s以上。检查后不是网络设备问题。

以上3个步骤排除后，应该确定问题出在邮件服务器上。启动邮件服务器本身的故障排除：

由于邮件服务器收发正常，直接登录邮件服务器，查看其他可能影响邮件服务器的因素。

首先检查服务器负载，包括CPU、内存、磁盘空间、IO和→网络负载。通常主要影响的是 CPU 和内存，其次是磁盘空间和 IO。查了一下磁盘空间不足（已经不足5%了，但是还有3GB的空闲空¤间，由于经验不足，没有＠判断这个问题可能造成的影响，内网邮件正常，所以是没有优先考虑，最后发现是这个原因造成的）。

接下来，您应该检查服务器系统日志。首先检查日志或首先检查々负载只是一个习惯问题。系统日志通常会为管理员提供足够的信息。事件管理器虽然不是特别好用，但在日志方面还是相当良心的，一般大大小◥小的事件都有记录。

除了检查系统日志外，一般还提供其他诊♀断工具。比如“队列查看器”，由于队列查看器可以用来排查邮件流问题，在队列查看器中也会有一些邮件无法投递的提示。

查看系统日□志和队列查看器后，发现问题是由于资源不足。系统有两个明显的提示：

1.队列查看器指出最后一个错误是“4524.3.”。查询后，这通常意味着磁盘空间不足或内存空间不足。

2.事件查看器中的←“来源”报告说：

（1）警告：资源压力已从正常增加到中等。

（2）错误：传输服务∮拒绝了邮件提交，因为可用磁盘空间已低于配置的阈值。

故障排除和维修

已确定为由磁盘空间问题触发的“背压”保护策略。通过释放磁盘空间来解决。解决方案解决后，通知上级领导及相关人员。

知识点

关于“背压”。以下是文档库的摘录——了解背压。

背压是存在于集线器传输服务器和边缘传输服务器上的传▲输服务的系统资源监控功能。 可以检测可用硬盘空间和内存等重要资源何时受到压力，并采取措施尝试防止服务不可用。

背压可防止过度使用』系统资源并尝试传递现有消息。当系统资源使用恢复到正常水平时，服务器可以逐渐恢复正常运行。

其中，当集线器⌒　传输服务器或边缘传输服务器处于资源压力之下时，它会拒▓绝传入连接。在 中，传入连接被接受，但通过这些连接传入的邮件以较慢的速度被接受或拒绝。当 SMTP 主机尝试连接到背压下的集线器传输或边∮缘传输服务器时，连接成功，但当主机发出命令提交邮件时，根据压力下的资源，可能会延迟确认命令或拒绝订单。

以下摘录来自事件查看器：

传输服务拒绝了邮件≡提交，因为可用磁盘空间已低于配置的阈值。

以下资源面临压〓力：队列数据库日志记录路径("C:\\V14\dataQueue")=95%[][=93%=95%high=97%]

背压导致以下组件被禁用： 从集线器传输服务器提交入站邮件

提交来自的入站邮件

从选择器目录◥提交邮件

从重播目录提交邮件

从邮箱服务器提交邮件

将邮件投递到远程域

从队列数据库加载电子邮件（如果可用）

以下资源处于正常状态：Queue path("C:\\V14\dataQueuemail.que")=95%[][=95%=97%high=99% ]

版本桶=0[正常][正常=80中=120高=200]

私有字节=0%[正常][正常=71%中=73%高=75%]

物理内存负载 = 11% [限制为 94% 以启动邮↑件冻结。]

批处理点=0[正常][正常=1000中级=2000高级=4000]

提交队列=0[正常][正常=1000中=2000高=4000]

注意：其实Linux中也有类似的保护机制，比如oom，磁盘预留5%。遇到此类知识时，应从其他事实中推论，类推。

故障反映与总结

遇到∩故障或问题时，应保持头脑冷静，不要惊慌，不要搞砸自己。很多运维或者管理员遇到问题，首先想到的是如何解决，尝试＠ 了各种解决方法都无济于事后，为了节省时间想到了回滚，这是∏不正确的。作为一名合格的运维人员，应该了解事情的来龙去脉和问题的根源。在排查问题时，首先要考虑的是通过日志排查问题。在调查过程◆中，调查要尽可能全面，不要遗漏任何可能引起问题的细节。

部署必须符合标准，必须标︻准化。从这次事故来看，这台服务器包含三个∑数据库，其中一个存储在C盘，其他盘不存在。久而久之，这个数据库占用了大量磁盘空间，导致磁盘空间不足，从而触√发了“背压”机制。从标准和规范的实践来看，这个数据库应该从 C 盘移动到其他大容量磁盘。并在部署之初计算容量。

注意警察。该▃服务器配置了监控告警，已经检测到故障并发出告警。故障是由于★处理不及时造成的。

就算要接手，也要改变过去。因为这台邮件服务器是之前一个运维同事部署的，所々以里面的一些问题被搁置了很久没有解决（也有技术原因）。

保持学习。虽然有时有些事情会偏离自己的方向，但应该深入研究公司的核心 IT 系统（如邮件服务器）。只有理解和理解，才能在遇到问题时更快地解决问题。

每次失败后总结☉经验，吸取教训。记录知识和经验，安顿下来。比如经过这个总结，遇到这个故障时服务器运维，你可能会突然想到磁盘Ψ空间不足会触发背压，导致无法接收外部邮件。

如果你想在这个行业工作，但你没有基础，可以先去培训，也可以↘少走弯路。Linux培训费用不贵，投资非▓常必要。