適合的讀者：任何人
前言
記錄昨天正式環境服務器事故的發生以及處理過程，服務器是Linux（Centos 7）。
察覺到異常
後端A：莊大叔，服務器登錄不上去了。
我：是不是你網絡有問題啊，C你登錄一下服務器試試。
後端C：肯定是A網絡有問題啊，我才剛登錄過。
過了一會......
後端C：我也登陸不上去了，正式環境是不是崩了？
前端D：什麼？正式環境崩了？￥%354535！4￥%……
前端E：￥%354535！4￥%……
我：D看看正式環境接口是否還能正常調用（與此同時我也嘗試登錄了服務器，報連接失敗），C你剛才對服務器進行了什麼操作。
D：接口還能正常調用。
後端C：我更新完補丁以後刷新了權限，然後就沒有了。
現象分析
從上面的對話可以看出，服務器出於無法登錄的狀態，但是接口服務還是正常的，而且做過chmod權限操作。想到這裡我不冒了點冷汗：很可能是C不小心執行了類似
chmod -R 777 /
這類操作，把服務器全部文件的權限都更改了，導致root賬號無法登錄以及無法sudo操作。
解決過程
- 詢問C是否還保持著那個服務器連接，辛運的是他還保持著，查看他執行過的更新腳本，有一句是有錯誤的，導致在根目錄執行了
chmod -R 777 ./
確認了問題原因，而且服務器還保持著連接，那麼問題已經解決了九成。
- 為了防止其他意外，先進行數據庫備份，以及配置備份
- 從開發環境（也是Linux）執行以下命令備份文件權限
getfacl -R / > filename.bak
然後把這個文件拷貝到正式環境，執行以下命令恢復系統目錄默認權限
setfacl --restore=filename.bak
- 執行上述步驟後，重啟
service sshd restart
- 我的預期是重啟以後ssh就可以恢復正常，然而並沒有，猜想是文件權限沒有更新到位，於是一個一個恢復權限
cd /etc
chmod 644 passwd group shadow
chmod 400 gshadow
cd ssh
chmod 600 moduli ssh_host_dsa_key ssh_host_rsa_key
chmod 644 ssh_config ssh_host_dsa_key ssh_host_rsa_key.pub
chmod 640 sshd_config
chown -R root.root/var/empty/sshd
chmod 744 /var/empty/sshd
再重啟ssh
service sshd restart
發現重啟成功，接著讓A連接服務器，連接成功。問題基本解決，後續把其他文件的權限恢復一下就可以了。
總結
這是一種從流程和管理方面可以避免的事故，比如儘量不要使用root賬號。
問題剛發現的時候，A問我能不能重啟服務器試試，我直接駁回了，沒有確定問題原因、並且接口服務正常的情況下，千萬不要出了問題就馬上重啟服務器，像這次的問題，如果重啟服務器，反而會導致sudo操作無法進行，無法進行一些操作導致接口無法正常調用，進而影響到事故，而且服務器一旦重啟也僅剩的連接也會斷開，這時候就更加難以處理問題！
我是搞技術的莊大叔，有什麼建議或看法可以在評論區進行交流。
