安全開發與發佈的基本準則

遵循一套用於安全開發和發佈的準則，爲開發活動編織一張質量安全網，儘量下降出問題的機率。

影響面評估準則

確保代碼安全的第一準則是：代碼的影響面評估。在覈心流程裏的一行代碼的影響面，勝於在非核心流程裏的百行代碼的影響面。
新手工程師，每每容易見樹不見林，着眼於眼前的功能，而未察覺對現有或全局的負面影響。

1. 在覈心流程或通用方法里加代碼時，要謹慎。哪怕是一行，均可能會出問題。
2. 儘可能避免修改原有方法的簽名。使用重載方法或拷貝方法來解決。若是原有方法只有一個調用方，能夠這麼作，但要回歸影響的功能；若是有兩個調用方，謹慎這麼作；若是有三個調用方，避免這麼作【由於迴歸量可能很大，超出所能預料】。
3. 實現眼前的功能時，要同時關注會被影響的功能。
4. 修改的方法有不少調用方時，要考慮兼容，評估每一個被影響到的方法及風險。
5. 新增而不修改原有代碼，一般不會出問題。努力作到開閉原則：「對修改關閉，對擴展開放」。
6. 新增配置而不修改原有配置，一般不會出問題。可是「老配置+新應用」會致使問題。
7. 當用新作法替換原有作法時，尤爲要回歸全部影響到的點。
8. 對可能產生風險的代碼敏感。
9. 勿存僥倖心理；勿對代碼過於自信。
   
   

健壯性準則

不少線上問題出在代碼的不健壯性上。即便引起的是小問題，未致使故障，但修復時也要從新測試和發佈，耗時耗力。

1. 在覈心流程裏解析不可靠的數據（尤爲是 JSON 數據）時，加 try-catch 。
2. 在總體流程中流經的肯定極可能會拋出異常的代碼，若是不指望影響總體的執行完成，加 try-catch 。
3. 在總體流程中流經的不肯定是否有場景會致使拋出異常的代碼，加 try-catch。
4. 避免鏈式地獲取嵌套對象的屬性，很容易致使 NPE 。
5. 對 API 返回結果判空。
6. 對不太肯定是否爲空的對象或容器判空。
7. 考慮對原有狀況的兼容。
   
   

不可變準則

修改入參，使用全局變量，每每使得程序行爲更難推測，錯誤潛藏很是隱祕，出問題後排查也會很是耗時。

1. 避免修改方法入參（對象或容器）。
2. 使用 stream.filter 替代刪除列表中的元素。
3. 當須要修改入參來實現時，老是考慮經過返回對象來替代。
4. 提供 merge 操做優化修改入參。
5. 避免使用全局變量。
   
   

快速失敗準則

快速失敗是避免產生大量髒數據的法寶之一。

1. 若是一項功能須要多個前置條件同時具有才能正確運行，錯誤運行會致使不可肯定的結果時，在任一條件不具有時，及時拋出異常終止。
   
   

重大重構準則

1. 儘量新增接口/鏈路而非修改原來的。
2. 使用策略模式分離新鏈路和舊鏈路。
3. 增長開關，可以快速切回原來的服務。
4. 確保可快速回滾【應用及配置】。
5. 經過逐步分流來切入新流量，冷卻老流量。
6. 用次要的影響面小的業務進行線上試點。
   
   

併發安全準則

1. 單例組件類儘量只引用不含有實例成員的單例組件。
2. 組件類避免含有可變的實例成員；這種設計容易潛藏難以覺察的併發風險。
3. 若是組件類含有可變的實例成員，則要麼確保不在併發環境使用，要麼添加組件的原型聲明。
4. 生產環境裏使用全局配置良好的線程池，而不是簡陋配置的線程池。
5. 避免在方法裏動態建立線程池。除非這是一個小流量應用，且方法調用不多。
   
   

大流量準則

1. 應對流量大的長耗時任務，限制指定時間段的處理數量。
2. 應對流量大的工具須要加限速能力；限速可動態調整。
3. 降級非核心服務和數據，可配置。
4. 數據存儲冗餘或優化，減小爲了取少許次要數據而致使的外部服務調用。
5. 實時性要求不高的場景，採用延時隊列或非實時接口來處理。
   
   

關鍵日誌準則

1. 核心鏈路和關鍵數據必須打日誌；方便排查問題。
2. 已預估的出錯或致命問題的打錯誤日誌；發佈時要尤爲關注此類日誌。
3. 不影響系統運行的錯誤打警告日誌；避免干擾發佈是否OK的判斷。
   
   

提早預知準則

1. 對於預發上報出的任何問題保持敏感。由於那多是老天爺在提醒你。
2. 對於返回大量數據的查詢服務類，可使用對比引擎來比較線上和預發的返回結果。
   
   

嚴格測試準則

1. 單測所有經過；不可繞開原有單測。
2. 不管改動大小，均要自測。
3. QA 和預發測試，自測經過。
4. 已有測試用例所有經過。
   
   

安全發佈準則

1. 一個項目涉及多個應用和配置時【應用+配置 > 3 時】，必定要制定發佈文檔，指明配置與應用的發佈順序，以及不遵循該發佈順序時會致使的風險。
2. 發佈文檔的細節必須很是具體明確，每個操做和命令都毫無歧義。即便換另外一我的來發布，只要按步驟執行，就不會出問題。
   
3. 發佈 4 個以上應用時，應找團隊其餘小夥伴協助，減小因發佈壓力過大可能致使的誤操做或長耗時。
4. 發佈多個應用時，在代碼實現考慮兼容，確保部分能夠提早發佈或者並行發佈。
5. 發佈時要專一，不容許被打斷；發佈後一小時內應持續觀察，儘可能不要離開。
6. 節前非重要緊急問題避免發佈；與產品同窗協商好，改日發佈。
7. 因爲配置切換致使線上容易產生大量髒數據，或者須要修復不少數據時，最好凌晨發佈。 儘可能一次性解決，而不要累積起來屢次解決【撈數據和修復數據的成本有時很大】。
8. 涉及不少配置和 DDL 的大項目發佈，最好凌晨發佈。有充足的時間測試迴歸。
9. 開發與發佈前，確保 QA 和預發、線上的配置是一致的。配置不一致，可能會致使 QA 和預發的測試OK，可是到線上就會出問題。
10. 使用灰度發佈或藍綠髮布；白名單驗證；分流發佈；分批發布；