三周前刚从上家公司换到新的公司，这家公司与上家公司相比对阿里云的云计算环境更加的依赖，使用的ECS实例和其他服务如SLB、RDS、OSS等更多了一个数量级。这篇文章的背景就是为了解决阿里云ECS云主机SSH连接的一个问题，从故障发现到故障排除到最后反思的一个详细过程。文章比较长，图片众多，建议有时间仔细阅读，没时间就阅读文末的“总结和反思”部分即可。
故障发现：
2017-05-23 下午17:00点前同事报告称GitLab所在的服务器访问出现异常。经查发现在公司内无法正常通过SSH连接GitLab服务器。经过测试后发现问题确实存在。
用户（运维）自查过程：
- SSH连接公网IP地址失败，ping正常，该服务器上的业务访问正常，因此判断不是服务器宕机；
- 连接到在阿里云刚搭建好的OpenVPN服务器，SSH连接内网IP地址，发现可以正常连接，排除SSH服务问题；
- 经过查询ECS云主机上的日志，/etc/hosts.*，防火墙、SELinux以及ECS安全组，发现公司的IP根本没有任何连接ECS云主机的日志记录和存在配置不当的问题；
- 因此初步判断问题不在ECS云主机和公司网络上，怀疑可能是阿里云安全组出了问题或者公网出口的防火墙对我们公司的IP地址进行了拦截，认真核对了安全组设置和确定云主机以及运行环境没有问题后，果断向阿里云提工单支持。
阿里云工单支持过程：
说明：
（1）为了方便编辑和阅读，所有内容均为原始截图（在新标签页中打开图片查看原始图片），IP等敏感信息也不做隐藏处理，请大家不要恶意攻击，如果发现漏洞欢迎留言和进一步交流；
（2）沟通记录后面的图片是沟通记录中按次序出现的图片，供大家查阅；
（3）工作任务比较繁重，时间仓促，如有问题请批评指正和多多谅解；
1.用户报告问题，售后工程师给出初步诊断
2.双方互相协助排查
3.进一步测试问题
4.及时跟进进度，进一步诊断问题
5.进一步分析和确认原因
6.找到原因，解决问题
7.售后工程师给出问题结论，用户评价，完成工单
问题和解决方案总结：
[ 问题现象 ] ECS云主机的公网IP地址无法通过SSH连接，提示“Connection reset by peer”，内网地址连接正常
[ 解决方案 ] 排查发现是该客户端IP扫描服务端多个敏感端口导致被云盾拦截，如果确认没有问题，您可以通过如下路径设置白名单放行：云盾控制台--》DDOS防护--》基础防护--》点击具体的实例--》扫描拦截--》白名单设置--》添加源地址 124.129.14.90
总结和反思：
1.阿里云的产品的确为用户提供了很大的便利，但用户也需要了解用户自己使用的阿里云产品的技术栈和相关知识，用户需要有自己专业的运维支持
2.提交问题时，用户要尽可能的为问题诊断人员提供尽可能的多的信息，这样才能帮助问题诊断人员在较短的时间内定位问题
3.在工单过程中，用户要尽可能的提供图片，保留问题证据，为后期纠纷和索赔做好准备
4.利用排除法缩小问题范围，判断问题的种类和使用恰当的工具很重要，比如这个例子中：SSH无法连接-->排除其他问题定位到是网络问题-->网络问题的工具：tcpdump+Wireshark抓包排查-->判断不是xxx的问题-->最终得出结论：云盾拦截
5.当售后工程师帮助我们解决问题时，自己也要多动脑思考，并不是一劳永逸提交过工单说明情况就完结了，需要用户在此过程中多做配合及时跟进问题，了解工单进展
6.问题解决过程中，用户和售后要互相谅解，互帮互助，以解决问题为要
7.事故的责任问题，此事故不能说完全是用户的问题，阿里云的云盾确实存在缺陷，假设用户办公网络内真的存在恶意扫描，云盾在检测到攻击后应该及时告知用户，例如给出攻击威胁通知，在拦截并加入黑名单后，应该及时通知用户
8.对于这位售后工程师的评价：其实他很不容易。但通过纵览解决问题的全过程，可以发现这位工程师在解决问题的能力上和在为用户解决问题的态度上还是有一定问题的。如果在沟通过程中能更主动一些，解决问题的思路上更灵活一些应该能在更短的时间内解决问题
9.自己的反思：
（1）作为运维人员来说，经验要不断积累，技能要不断提升，这需要保持一个良好的心态和面对问题时的态度；
（2）在面临问题时要考虑全面，把所有可能的问题因素都找出来，逐个排除最终解决问题；
（3）解决问题时工具和思路都很重要，平时运维过程中不仅需要经验知识积累也需要关注针对某一部分问题的完整解决方案的积累，能灵活运用恰当的工具快速解决问题
（4）…… ……
时间有限，先到此为止，后期再慢慢整理和反思。
--end--