周六中午12点突然接到同事消息，公司APP内的订餐功能无法访问，消息无法发送附件。
此时的我正在地铁上，公司规模较小，周末并没有人专职值班。
打开手机，通过远程控制软件连接可用环境，检查服务和端口一切正常。
服务正常的情况下，功能不正常，会不会是某个常见的问题（一直没找到根本原因），其常用的处理方式是重启服务。
于是把对应的服务重启了一遍：
重启应用服务，重启消息服务，重启移动端服务。
重新尝试访问，仍然无效。
联系供应商，供应商的值班技术排查了一遍，没找到问题，认为是移动端的问题，又联系移动端的同事排查一遍，仍然没找到问题。
记录一下排查思路：
首先是常规的netstat查看端口的服务情况，然后是查看移动端的请求日志，发现请求日志中大量的请求应用端80端口服务失败。
开始检查应用端80端口提供的服务，一切正常。
netstat -an|grep :80发现80端口主动拒绝了来自移动端的请求。
太诡异了，所有的服务都正常，但是就是无法访问。
先暂停了解决该问题，准备去查看文件无法传输的问题，就在此时，基本定位了问题。
文件传输失败，我首先去检查的是服务器的磁盘空间
登录服务器，df -h，发现此命令卡住了，ctrl+c中断，df -l，发现磁盘的使用率只有一半。
此时的我，并不知道 df -h，df -l有什么区别。
但是观察df -l的时候，我发现了一个细节，本来应该挂载此服务器上的一块5T的磁盘不见了。
一番百度，发现了df -l只是列出本地磁盘，df -h是列出所有磁盘，包括网络磁盘。
df -l ###只查看本地挂载的磁盘文件
df -hT ###查看本地及远程挂载的磁盘文件
mount | column -t ###查看mount挂载文件详情
于是执行：
strace df -h
发现的确是在nfs磁盘位置卡住了。
同时，又找到了以下资料：
在设置了防火墙的环境中使用NFS，需要在防火墙上打开如下端口：
1. portmap 端口 111 udp/tcp；
2. nfsd 端口 2049 udp/tcp；
3. mountd 端口 "xxx" udp/tcp
系统 RPC服务在 nfs服务启动时默认会为 mountd动态选取一个随机端口（32768--65535）来进行通讯，我们可以通过编辑/etc/services 文件为 mountd指定一个固定端口。
的确我们的应用和文件服务器之间有一层防火墙。
我尝试了ping和telnet对应的端口，所有的端口通信没有问题，这就很诡异了。
于是分享给了我另外一位管网络的同事，他告诉我一个重要消息，防火墙在10点钟进行过一次升级，而文件传输失败的问题，恰好发生在这个时间之后。
我们基本把问题定位到了防火墙层面。
经过一番检查，防火墙策略并没有变更，所有端口可以正常访问，应用和文件服务器之间是做的any端口的策略。
但是我们相识还是防火墙做了这个升级引起的，于是联系防火墙供应商。
沟通第二天早上9点做一个三方沟通。
第二天早上9点之后，供应商检查之后，做了相应的设置，文件服务成功恢复，mobile成功登录。
关于本次问题的反思：
0.对于企业内部的所有服务之间的连接方式及接口，应该非常；
1.基础设施的升级，尽可能一定要告知相关方；
2.基础设施升级后，一定要做应用访问是否正常的检查，本次做了应用检查，但是没有做文件服务的检查。