防火墙趣事

最近当了一阵防火墙，期间遇到两个很有意思的问题，分享一下。

注：敏捷开发中设立防火墙主要是为了屏蔽迭代开发过程中的外部干扰，譬如故障定位、环境支持等等。

【问题1】

某日，有业务产品同事反馈，使用我们系统A时，发现与其对接的系统B发生异常，导致无法进行业务操作

排查：

1）浏览器登陆系统B，发现登录异常，无法访问（尝试复现问题现象，确认）

2）于是逐层排查，从网关nginx、uwsgi一层层排查，发现服务端的日志打印异常（理解系统架构，逐层递进）

3）根据异常日志，发现某个配置ini文件大小为0，导致无法正常启动服务

4）于是邮件反馈原因，问其是否有人为或者自己编写的小脚步误删导致

5）反馈未有特殊操作，这时又有同事反馈，之前也有同事遇到过一例类似问题，于是，警觉起来（保持警觉）

6）查阅操作系统日志、history记录等均未发现异常（掌握基本的操作系统知识，全面阅读日志）

7）不得其解，遂起身舒展一下身体，喝口水（当focus太久的时候，适当defocus，放空一下）

8）突然，灵光一现，大半年前，老形态的版本也遇到过类似问题，依稀记得当初操作系统专家给出答复是sed命令导致异常（发散，回想，找到灵感）

9）立马翻阅历史邮件，证实确有可能为sed命令导致（sed操作之后，如果os的内存没及时写入磁盘，此时断电会导致sed过的文件大小为0）（历史经验，保留关键资料很重要）

10）按此思路，查阅异常服务所在容器的启动脚本，果然发现有个初始化的shell脚本中有两行sed命令操作的文件

11）检查两行sed命令操作的文件大小，均变为0

12）原因基本锁定，为进一步确认是问题，进一步查看容器日志和操作系统messages日志

13）发现在容器启动后的不久，立马发生了操作系统重启的日志，并且时间点均能对上，最终锁定此问题（再次确认验证）

【问题2】

某日，有业务产品同事反馈，部署系统A，采用双机方式部署后无法登陆系统，而采用单机部署时正常

排查：

1）登录系统检查，发现异常的原因为业务容器依赖的kafka容器启动异常导致（老套路，先亲自复现确认）

2）于是，检查kafka容器启动日志，发现连接zk失败，报错Host is unreachable

3）为何会连不上呢？zk和kafka都是在同一个虚机内的啊，在虚机内部ping zk的地址一切正常

4）这时仔细一看zk采用的是host模式，容器内部使用的网络跟虚机一样，而kafka容器使用的是bridge模式，对应docker0网桥上分配的172段地址，两者地址不是同一网段（了解系统模式的差异，检查对比，发现差异）

5）于是进入一个同样采用bridge模式的容器，在容器内部尝试ping zk，发现果然不通（进行对比试验）

6）这又是为何呢？就在一个虚机内部，网络比较简单，不应该啊

7）于是，翻阅系统日志，这时，在messages日志中发现一段可疑打印：kernel: IPv4: martian source 172.17.0.1 from 172.17.0.12, on dev docker0（检查日志很重要）

8）恩。。。看来内部linux的路由有问题了

9）那就ifconfig检查一下IP设置

10）果然，发现有个心跳平面的网卡设置成172.16.0.2/24，而docker0的网关地址默认为172.16.0.1/16（注：单机模式是不用设置心跳平面的，双机模式时双机软件需要设置心跳平面）

11）于是将异常心跳平面网卡down掉，重启kafka，此时kafka启动正常，最终锁定此问题（确认问题，进行验证）

总结一下这过程中需要我们get到的一些知识点：

1）不要只听别人说，要自己看

2）要理解系统（这里想到一本书：《调试九法》，推荐一下）

3）要全面观察

4）大胆猜想，小心验证

5）必要的试验对比很重要

6）重视平时的细节经验，关键时刻很有用

7）思考问题时，需要focus聚焦，也需要及时defocus抽离发散获得新思路

我们可以进一步学习到一些知识点，譬如docker最基本的bridge、host、none三种基本的默认网络模式的差异（这个推荐一下CloudMan的每天5分钟系统，有兴趣的同学可以微信公众号或者cnblog或者csdn搜索学习）

珍惜每一次与系统、与人的交互，在交互中学习成长。