背景：
國產化web容器(寶蘭德)升級。
踩坑過程：
web容器升級後，web系統正常訪問，看似正常。晚上批次跑批的時候，中斷了。
中斷原因：發現某路徑下的檔案，的確存在，但是程式報NoSuchFileException。
調查得知，現在該檔案的許可權是640（linux），想定應該是644。其他使用者組的read許可權缺失，導致檔案不可讀（也就是讀取不到）。
專案啟動指令碼中，有umask 0022。
（預設情況下的umask 0022 ，為了控制預設許可權，使得預設檔案和目錄不會具有全部許可權。umask 0022 檔案的預設許可權是644，目錄預設許可權是755）
經過分析，以前執行指令碼 umask 0022 賦的許可權是644，那麼卻現在賦成了640。
那麼，為什麼會出現這個狀況？
sh test.sh 原因在於此。
sh 命令執行後面的shell時，會另起一個新的子程序。這時，寶蘭德容器內部為了安全性的考慮會預設設定640的許可權。
改法：
sh test.sh 改成 source test.sh （source 命令在當前shell程序中執行指定的指令碼，並將命令和變數匯入到當前shell環境中，這就意味著外面的umask 0022的作用會影響到test.sh的執行環境，使得umask值644）
當時這個方案確定後，我組織人力批次修改。但是還有人改漏了，出了生產問題。
覆盤：
1.reviewer 沒細看程式碼導致問題帶出
複合程式碼人必須逐步檢查。
2.自己寫的程式碼，自己檢查。常常發現不了問題。
要進行交叉檢查。A寫的程式碼，B去檢查。B寫的程式碼，A去檢查。
3.測試環境下的變數值，與生產不一致。
後續要保證一致，避免出錯。
4.開發人員改了10處。那麼發現一處改錯了，要確認好其餘9處是否有同樣問題。切記！！！
（完）
附：
cat proc / 程序id / status 命令 （檢視某程序下的umask值）