行业动态

本文是对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培训费用不贵，投资非常必要。