本文是对2018年8月9日公司Exchange邮件系统邮件流故障的故障发现、故障处理和故障修复的过程记录和总结反思。帮助自己总结经验和吸取教训，同时也作为一次反面教材让其他运维或管理员吸取教训。
故障发现
昨天下午18点50左右结束团队内培训分享会后，收到同事的反馈，说他们几个人都无法收到外部邮件（Internet上的邮件），故障现象为：Exchange服务器内网收发邮件正常，外网发送正常，但无法收到外部邮件。
因为公司的邮件系统是公司自建的Exchange Server 2010，因此需要运维自己去管理。经过多个外部邮箱的测试发现，的确无法收到外部邮件，这些外部邮箱包括网易、阿里企业邮箱和微软Outlook邮箱。
因为邮件服务是企业核心服务之一，加之已经有同事反馈遇到问题，因此此故障应该是重要紧急故障，必须尽快排除以恢复服务。
注1：如果问题比较严重或者有紧急事件处理流程规定，应该按照流程汇报上级领导和发出通告。
注2：以下是个人看法和经验总结，如有错误敬请指出。
故障处理
面临故障最重要的就是尽快通过排除法进行故障排除以实现服务的最快恢复。因此首先要做的故障排除。由于已经是下班时间，事故虽然重大，但还尚未造成重大影响。
因为在Windows特别是Exchange的运维上个人经验比较欠缺，不能凭经验一下子发现问题，因此只能先根据以往经验，结合Google等逐个排查。
经过初步测试，内部邮件收发正常，内部向外部发送邮件正常，但接收异常。于是开始以下排查。
在排查之前应该先需要搞清楚最近发生的变更，如软件配置，导致变更的操作，特别是两个及以上的管理员共同管理时。因此服务器由一人管理，且最近没有进行过任何更改，是突然出现的问题，因此直接开始排查：
检查域名解析，排查mx记录等是否存在问题。使用nslookup命令在多个外网服务器上测试MX记录、以及相关的A记录和CNAME记录。
注1：Windows服务器可以使用nslookup -q=mx xxx.com直接查询，Linux命令需要交互式查询，即先执行nslookup再set q=mx或set type=mx，再查询
注2：在查询mx记录时，只需要查询邮件服务器fqdn域名的上级域名即可。如mail.qq.com，则只需要查询qq.com的mx记录即可。
经过排查，排除域名解析问题。
检查外部与内部的通信问题，检查防火墙拦截情况和防火墙到服务器中间的网络链路问题。使用telnet mail.xxx.com 25命令检查25端口的打开情况，经过测试排除防火墙问题。
注1：25端口是接收外部邮件的约定端口
注2：如果25端口正常且目标为Exchange邮件服务器，应该提示类似“220 mail.xxx.com Microsoft ESMTP MAIL Service ready at Fri, 10 Aug 2018 10:43:58 +0800”字样。
为了确认不是防火墙或网络设备bug问题，重启防火墙或网络设备。通常无软关闭和重启功能的防火墙需要断电或切换电源状态10s以上。经过检查不是网络设备问题。
以上3个步骤排除后，应该确定问题是出在邮件服务器身上。开始邮件服务器自身的排查：
因为是邮件服务器内部收发正常，因此直接登录邮件服务器，检查邮件服务器的其他可能影响因素
首先检查服务器负载，包括CPU、内存、磁盘空间、IO和网络等负载情况。通常影响Exchange的主要是CPU和内存，其次磁盘空间和IO。经过检查磁盘空间不足（已经低于5%，但尚有3GB可用空间，由于经验不足，没有判断出此问题可能造成的影响，加之内网邮件正常，因此没有优先处理，最后发现是此原因造成）。
其次应该检查服务器系统日志。关于先检查日志还是先检查负载情况，只是习惯问题。系统日志一般会给与管理员足够的信息。虽然Windows的事件管理器并不是特别好用，但是Exchange在日志方面还是比较良心，一般大小事件均记录在内。
除了检查系统日志之外，Exchange一般提供了其他诊断工具。比如“队列查看器”，因为队列查看器可用于解决邮件流问题，因此队列查看器里面也会有一些关于邮件无法传输的问题的提示。
经过查看系统日志和队列查看器后，发现问题是由于资源不足引起。系统有两处明显的提示：
1.队列查看器提示上一个错误为“452 4.3.1 Insufficient system resources”。经过Google查询，这通常意味着要么磁盘空间不足要么内存空间不足。
2.事件查看器中来源自“MSExchangeTransport”报告称：
（1）警告：资源压力已从 普通 增至 中。
（2）错误：Microsoft Exchange 传输服务拒绝邮件提交，因为可用磁盘空间已降至配置的阈值之下。
故障确认和修复
已经确认为磁盘空间问题导致的触发Exchange的“反压”保护策略。通过释放磁盘空间解决。解决后通告给上级领导和相关人员。
知识点
关于“反压”。以下摘录Microsoft文档库--了解反压。
反压是存在于 Microsoft Exchange Server 2010 集线器传输服务器和边缘传输服务器上的 Microsoft Exchange 传输服务的一种系统资源监视功能。Exchange 传输可以检测重要资源（例如可用硬盘空间和内存）何时具有压力，并采取操作以尝试阻止服务不可用性。
反压可以防止过多地使用系统资源，并且 Exchange 会尝试传递现有邮件。当系统资源使用率恢复到正常级别后，Exchange 服务器就可以逐渐恢复正常运行。
在 Exchange Server 2007 中，当集线器传输服务器或边缘传输服务器具有资源压力时，它会拒绝传入连接。在 Exchange 2010 中，会接受传入连接，但是会以更慢的速度接受或拒绝通过这些连接传入的邮件。SMTP 主机尝试连接到处于反压下的集线器传输服务器或边缘传输服务器时，连接会成功，但是该主机何时发出 MAIL FROM 命令来提交邮件，则取决于具有压力的资源，Exchange 可能会延迟确认 MAIL FROM 命令或拒绝该命令。
以下摘录自事件查看器：
Microsoft Exchange 传输服务拒绝邮件提交，因为可用磁盘空间已降至配置的阈值之下。
以下资源处于压力之下: 队列数据库日志记录路径(“C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\”) = 95% [中] [正常=93% 中=95% 高=97%]
反压力导致禁用了以下组件: 从集线器传输服务器提交入站邮件
从 Internet 提交入站邮件
从分拣目录提交邮件
从重播目录提交邮件
从邮箱服务器提交邮件
向远程域传递邮件
正在从队列数据库加载电子邮件(如果可用)
以下资源处于正常状态: 队列数据库路径(“C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\mail.que”) = 95% [普通] [正常=95% 中=97% 高=99%]
版本存储桶 = 0 [普通] [正常=80 中=120 高=200]
专用字节 = 0% [普通] [正常=71% 中=73% 高=75%]
物理内存负载 = 11% [开始邮件冻结的限制为 94%。]
批处理点 = 0 [普通] [正常=1000 中级=2000 高级=4000]
提交队列 = 0 [普通] [一般=1000 中=2000 高=4000]
注：其实Linux中也有类似的保护机制，如oom，磁盘保留5%，遇到此类知识应该举一反三，触类旁通。
故障反思和总结
遇到故障或问题应该保持头脑冷静，切莫慌乱，不能自身乱了阵脚。很多运维或者管理员在遇到问题时首先想到是如何解决，而尝试各种办法解决无果后为了节约时间就想到回滚，这是不正确的。作为一个合格的运维应该弄清事情的来龙去脉和问题的根本原因。在排查问题时首先想到通过日志去排查问题。在排查时应当尽可能全面的排查，不要漏掉任何一个可能导致问题的细节。
部署必须遵从标准，必须规范。从这次事故来看，此Exchange服务器中含有三个数据库，其中一个数据库存放在C盘没有在其他盘。随着时间的增长，这个数据库占用了大量的磁盘空间，导致磁盘空间不足，从而触发了“反压”机制。从标准和规范的做法来看，应该将此数据库从C盘移动到其他容量大的磁盘。并且在部署最开始时计算好容量。
重视报警。此服务器是配置了Zabbix监控报警的，而且Zabbix已经监测到故障并发送报警，由于没有及时的处理才导致本次故障的发生。
就算是接盘也要痛改前非。因为此邮件服务器是之前运维同事部署的，因此里面有些问题一直搁置而迟迟没有解决（也有技术上的原因），从长远角度上看，即使需要付出一定的代价也需亡羊补牢。
保持学习。虽然有些时候，某些东西偏离了自己的发展方向，但像邮件服务器这样的公司的核心IT系统应该去深入的学习。只有了解和懂得才能遇到问题时更快的解决问题。
每次故障后总结经验和吸取教训。将知识和经验记录下来，沉淀下来。比如此次总结后，在遇到此故障可能一下子就想到了磁盘空间不足会导致Exchange触发反压，从而导致无法收到外部邮件。
--end--
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
