編寫代碼的「八榮八恥」- 以開關上線爲榮，以自信編碼爲恥

背景

"個人代碼太完美了，不可能有bug!" 不知道你們有沒有過這樣的自信。咱們團隊的代碼觀：「是代碼必定是有bug的。要考慮好充分的兜底以及緊急預案。」

不能將碰運氣當成戰略  --《SRE Google運維解密》

 

WHAT

編寫代碼的「八榮八恥」

1. 產品命名：以簡單有趣爲榮，以平庸難記爲恥。

2. 單個方法：以短小精悍爲榮，以冗長費神爲恥。

3. 代碼維護：以持續重構爲榮，以停滯不前爲恥。

4. 編程思想：以面向對象爲榮，以面向過程爲恥。

5. 程序設計：以開關上線爲榮，以自信編碼爲恥。

6. 接口定義：以用戶易用爲榮，以複雜歧義爲恥。

7. 斷言分支：以實時報警爲榮，以忽略分支爲恥。

8. 報警策略：以定時調整爲榮，以放棄維護爲恥。

 

WHY

SRE（Site Reliability Engineering站點可靠性工程師)。在《SRE Google運維解密》裏提到世界上第一個SRE，瑪格麗特教授。

瑪格麗特帶着她的小女兒拉夫勞倫一塊兒來到公司，在飛行模擬測試時，拉夫勞倫偷偷地按下了控制檯上的DSKY鍵。整個模擬程序意外崩潰，發射程序終止。瑪格麗特和組員調試後發現，拉夫勞倫意外觸發了P01子程序的執行。若是在火箭飛行過程當中執行這段程序，後果不堪設想。

瑪格麗特爲此提交了一個軟件改動，申請在飛行程序中增長一項特殊狀態檢查避免這個問題。但NASA管理層認爲這個錯誤發生的可能性過小，沒有經過。瑪格麗特只能在飛行手冊中添加一段文字：請勿觸發P01程序。

幾天後，阿波羅8飛船執行任務時，宇航員意外觸發了P01程序。幸虧瑪格麗特的飛行手冊更新中提到了這種情形，並提供了有效的解決辦法。

不管對一個軟件系統運行原理掌握得多麼完全，也不能阻止人犯意外錯誤。--瑪格麗特教授

 

HOW

這裏主要介紹三種開關：版本切換開關、調參配置開關、灰度流量開關。

 

版本切換開關

新版本上線，上線若是發生問題，一個解決方法是：回滾代碼。線上服務由多臺機器組成，滾動回滾是須要較長的時間的。通常來講須要幾分鐘到幾十分鐘不等。更有效的方法是在編碼階段對於改動都設置開關。出現問題當即切換到老版本。

穩定性的要務之一：「消除臨時代碼」。因此通常運行兩週版本確認穩定後要將切換開關及原來的老版本代碼下線。

開關咱們團隊用的是配置管理實現的，開源的有zookeeper的實現。美團用的是OCTO的MtConfig。

 

調參配置開關

舉一個場景：mysql數據庫常常是被認爲很是穩定的基礎設施，甚至有的團隊在作架構設計的時候原則是：消息中間件掛了，咱們須要thrift直連降級；緩存掛了，咱們降級直接走持久層。可是若是mysql掛了，咱們就掛。

mysql掛的場景確實很少見，常見的狀況是咱們本身沒有用好。好比：容量沒有作合理預估。好比創建物理鏈接時間時長不合理。數據庫鏈接有一堆參數設置，建議放到配置管理裏去配置。

緣由：隨着在線上的運行，QPS升高，不斷加新功能等形成的對數據庫壓力。有可能形成預估或者測算出合理的參數再也不合理，爲了應對突發問題，建議測算值做爲默認值，同時可動態修改配置。

 

灰度流量開關

大功能上線通常須要灰度，以避免不符合預期形成較大損失。一個建議的策略是若是自己QPS較高，那麼能夠按照SLA(Service-Level Agreement服務等級協議)可容許的錯誤預算來設置灰度粒度。

好比，系統從年初一直運行良好，沒有出現過問題。此次要上線了。對外承諾SLA3個9。那麼第一次灰度的流量能夠按系統0.1%來灰度，那麼就算出現問題了，三天內能夠恢復，也能夠保證咱們的SLA。

 

總結

不要靠巧合編程 --《程序員修煉之道》

 

相關閱讀

編寫代碼的「八榮八恥」(上篇)

《程序員修煉之道》解讀

Elasticsearch的基本概念和指標

程序經常使用的設計技巧

到底多大才算高併發？

美團分佈式服務通訊框架及服務治理系統OCTO

學會用數聽說話-分佈式鎖究竟能夠多少併發？

大話高可用