疫情仍在全世界蔓延，但在我国已得到有效控制，这不仅仅体现了一个国家的综合实力，也体现了我们亿万国民团结一心，才能一次一次的战胜外界看起来不可抗击的力量。国之战神在于民心，团结力量大。
同样的道理，我们做为IT行业运维技术人员，不仅自身要实战技术过硬，项目组组员也都要有质量运维意识，才能一起共同做好线上线下系统运营运维技术保障，做好对众多服务的非功能性、功能性等防控，确保服务的高可用性、高可靠性、高维护性、高稳定性、高安全性等，确保企业业务运营正常。反之，如果组员对服务器上传代码工程包或者安装部署某个服务控件时，不经意间上传了有危害性代码、侵害性程序，会导致系统瘫痪。
在疫情期间，我们自身戴好口罩、强身健体；小区出入做好各种安防、出入证、量体温；社区喷雾杀毒等。这就如同我们服务器设置好防火墙、配置好访问端口、对于每个上传文档做好安全代码扫描、定期做好性能测试等各类非功能指标检验测试等，确保服务器正常运行。但一旦百密一疏，就会导致出问题。例如，这段时间我们某台应用测试服务器就出现CPU高、且无法正常登录现状，具体情况如下：
2月28日下午临近六点时，开发人员突然发了截图给我说187服务器无法登陆，问我是否修改了密码，如下图一:
（图一）
想想这段时间只有安装验测运维监控工具有用到187服务，但是也是10天前的事情，且没有去修改过密码，于是我也好奇登录下看看，发现确实出现问题，重新输入密码也不行，如下图二：
（图二）
追根溯源：
发现187确实无法正常登录，但是该提示信息说明该服务器没有被关闭，只是ssh链接被篡改了，这时脑中第一反应，***者使用了一个可执行的SSH后门，而且这些组件以服务形式安装来为恶意软件提供驻留。
出于好奇和对刚部署监控工具的可用性，我登录运维服务监控，发现还能收集187服务CPU等资源信息，如下图三，只是CPU使用率偏高，应该是使用了什么恶意软件在为它自己提供服务，但也说明187服务还是可用，只是新建的ssh连接无法链接。
（图三）
还好之前有一个惰性习惯，在另外一台电脑打开一个CRT，用完很少去关。此时刚好有打开187等服务器没关，还可以直接访问，发现是TSM服务导致CPU 高，cron的内存使用率偏高，问了下开发人员没有该服务，发现都没使用，就干掉为先。
于是就直接先kill掉，然后修改了下系统登录密码，但是还是要把问题追究到底，发现kill该进程后发现CPU立马掉下来，如下图四：
（图四）
通����ҽ��,��÷ֹ��过查证：tsm64是负责通过SSH暴力破解传播挖矿机和后门的扫描器，可以发送远程命令来下载和执行恶意软件。
看了下该进程对应的服务，安装路径配置路径如下：
root 31803 31798 84 07:44 ? 08:36:57 /tmp/.X19-unix/.rsync/c/lib/64/tsm --library-path /tmp/.X19-unix/.rsync/c/lib/64/ /usr/sbin/httpd rsync/c/tsm64 -t 505 -f 1 -s 12 -S 8 -p 0 -d 1 p ip
发现该服务应该只是一个shell服务，而且看了下远程监控收集的记录，发现是2月27日凌晨四点多的时候被侵入，植入病毒，导致CPU使用率高，也导致我们CRT无法正常登录，如下图五和图六：
（图五）
（图六）
分析下应该是有开启服务进程，才会导致CPU和内存偏高，而引起内存偏高的是cron进程，于是通过crontab -e发现确实被开启了进程服务，如下图七
（图七）
接下来直截了当，停止服务，然后删除对应路径下文件和定时作业，继续观察两天，如下图8发现确实没有再复现问题。
（图八）
（图九）
总结：
虽然本次问题从发现到解决总用时十来分钟，但是纯属运气下得以快速解决，也说明了服务非功能故障处理的多维性、运维技术人员技术思维发散性和知识全面性，主要还是要多实战才是王道，本次问题主要原因是：
一、主因是服务器密码设置过于简单，导致被有机可乘。
二、服务器安全防护设置不够完善。
三、项目组人员上传文档没有进行严谨审核导致上传文件带有病毒才导致本次问题引发。
四、服务器系统用户登录权限不够完善。
五、碰到问题不恐慌、要静心、要冷静。