疫情在全世界肆無忌憚蔓延，但在我大中華國內得到有效控制，這不僅僅體現一個國家的綜合實力也體現我們大中華億萬民心團結，才能一次一次的戰勝住在外界看起來各種不可抗擊的力量，國之戰神在於民心，團結力量大，而我們做爲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發現確實沒有在復現問題。
（圖八）
圖九
總結：
雖然本次問題從發現到解決總用時十來分鐘，但是純屬運氣下得以快速解決，也說明了服務非功能故障處理的多維性、運維技術人員技術思維發散性和知識全面性，主要是還是要多實戰纔是王道，本次問題主要原因是：
一：服務器密碼設置過於簡單導致被有機可乘，主因。
二：服務器安全防護設置不夠完善
三：項目組人員上傳文檔沒有進行嚴謹審覈導致上傳文件帶有病毒才導致本次問題引發。
四：服務器系統用戶登錄權限不夠完善；
五：碰到問題不恐慌、要靜心、要冷靜；