这几天有个很好的兄弟项目所搭建的阿里云ECS出现了极其诡异的现象，简单分析来看就是，系统会定期屏蔽访问，重启后会短暂恢复，但是很快又会故障依旧，这种问题凭借我Linux运维老鸟的经验来看，第一解决切入口就是进入阿里云后台，查看ECS服务器所在的安全组，是否开放了cPanel所需要的2087 2086 2083等端口，结果发现这些端口一直是开放状态。
然后我想到了局域网的IP可能被阿里云防火墙挡掉的原因，于是建议兄弟重启本地路由器，更换IP，结果还是没解决问题，照旧定期抽风，至此我才感觉到了这个问题的复杂性。
然后我兄弟和我聊起的时候，说他有给ECS购买了付费的云盾，我兄弟对网络安全要求是极高的，因此云盾的安全设定规则也很复杂，我建议他进去一顿关闭，咔咔操作猛如虎，结果却是二百五，问题还是像小强一样，外甥打灯笼–照旧。
到这个时候，我有点开始慌了，凭借我十多年的运维经验，这个现象非常不科学，而且甚至可以说有点“诡异”，我开始有点手足无措了，于是通过阿里云ECS自带的远程SSH登陆工具，登陆到了服务器上，通过命令行输入 service cpanel status 得到如下错误信息：
[root@cpanel ~]# service cpanel status
Redirecting to /bin/systemctl status cpanel.service cpanel.service – cPanel services Loaded: loaded (/etc/systemd/system/cpanel.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2020-08-13 15:00:21 CST; 17min ago Process: 1171 ExecStart=/usr/local/cpanel/scripts/restartsrv_cpsrvd –no-verbose –notconfigured-ok –systemd-service=cpanel (code=exited, status=0/SUCCESS) Main PID: 1399 (code=exited, status=255)
注意到我红色标注的地方一个清晰的 failed 由此可以断定，cPanel服务压根没启动起来，于是我输入 service cpanel start 执行很顺利，没有报错，于是我小小窃喜了一下，重新输入 service cpanel status 的时候，发现 failed 部分变为了绿色 running ，于是我再次测试发现，还是没解决问题，而且再次检测的时候，发现这个成功的标志再次消失，重新变为红色的失败提示。
由此我发现了问题根源依旧没找到，不过已经逐步接近真相了，于是我输入 df -h 发现系统盘20G，所剩无几，这时候我突然意识到，会不会是系统盘空间不够导致了安装在系统盘的cPanel无法启动，或者间歇性的宕机。
这之后多个操作都证明我的判断是正确的，在系统盘上执行任何安装类型的操作，都会提示 no space left on this device ，于是我让兄弟通过阿里云对这块系统盘进行了扩容，从20G扩充到了60G，信心满满的重启了服务器，通过命令行发现服务器压根没识别到这个新的60G空间，于是刚刚升腾起的希望又瞬间跌入谷底，看来阿里云的云盘扩容压根不完善，还要手工去做什么操作，于是提交工单给阿里云客服，慢腾腾的得到了一个扩容教程如下：
yum install cloud-utils-growpart yum install xfsprogs
resize2fs /dev/vda1
通过以上命令终于成功的将系统盘从20G扩充到了60G，于是，终于看到了曙光，然后输入如下命令：/usr/local/cpanel/scripts/upcp 全新升级了当前cPanel，升级过程很顺利，最终升级完成以后，此次问题也成功的获得了解决。
综上来看，Linux运维是个非常复杂而且充满不确定的过程，因为每次的问题处理可能都会面临新的不确定性，分分钟可能会让你怀疑人生，要想做好Linux运维，除了需要掌握大量的Linux知识以外，更多的是需要进行实战操作，只有在不断的实战中积累大量的一手经验，这样当下次遇到新的问题的时候，不至于茫然不知所措。
学海无涯，掌握某个知识不难，难就难在于掌握一整套解决问题的思路，一旦掌握了这种思路，无论下次遇到的问题有多棘手，总归都能顺利搞定。
特记录此次解决问题的过程，算是抛砖引玉，与大家共勉。