在線服務的黑天鵝
軟件隨想錄（More Joel on Software）有這樣一段話：
提高服務穩定性的最大困難，就是”黑天鵝難題”（problem of black swans）。這個名詞是由 Nassim Taleb 提出來的（www.edge.org/3rd_culture/taleb04/taleb_indexx.html），他這樣定義：”黑天鵝代表外來因 素，是一個超出正常預料的事件。”幾乎所有的互聯網服務中斷，都來自于意料之外的突發事件，屬于極其小概率的非主流意外。這類事件是如此罕見，以至于常規 的統計方法—-比如”故障間隔平均時間”—-都失效了。”請問新奧爾良市發生特大洪水的平均間隔時間是多少？”
</blockquote>
Tim 這兩天也是剛忙完 InfoQ 的 ArchSummit 的演講，正在利用周日休息一下，但是一醒來就收到消息說某服務有些問題。于是趕緊連線了一堆正在處理事件的工程師，等拿到初步的原因分析之后，已經 4 小時之后了。
“墨菲定律”，一位工程師說，“前幾天覺得這個地方有些隱患，已經存在一段時間了，打算下周來處理，未料它今天就出了問題……”。墨菲定律是指 “凡是可能出錯的事必定會出錯”，指的是任何一個事件，只要具有大于零的機率，就不能夠假設它不會發生。因此在線服務發生問題之后，總有工程師隨即證明墨 菲定律的有效性。
不過我覺得用黑天鵝難題更能體現在線服務可用性的不可控，可用性是指一個系統中提供服務與設計時間的比例，通常用百分比來表示。在線服務通常看到最多的是以下 3 種
- 99. 9%，服務中斷時間：525.6 分鐘/年
- 99. 99%，服務中斷時間：52.56 分鐘/年
- 99. 999%，服務中斷時間：5.256 分鐘/年
當一個系統有大量用戶使用之后，對系統可用性有較高要求，互聯網服務通常會把可用性目標定在 99.99% 及以上，但極少能達到 99.999% 的。Tim 有一個服務由于功能簡單且穩定，較少需要變更代碼，且有容錯的設計，服務池沒有單點問題，所以跟同事們說 2014 年可以達成 99.999% 了。未料這個服務池最近被一個極偶然的掃描腳本全部干掉了，盡管運維工程師馬上進行了處理，但是最后也較難滿足 1 年低于 5 分鐘中斷的期望。雖然這個是個偶然的案例，但是它卻是典型的黑天鵝事件。
對于系統服務可用性的問題，在專業領域其實有 3 個詞匯去描述的。描述的順序通常是 fault -> error -> failure。這方面大多定義引用來自《Patterns for Fault Tolerant Software》一書，在書中描述如下。
用一個通俗的例子來描述三者的定義是，如果把 fault 比作是數據庫網線斷了，則 error 是網絡不通連不上數據庫，導致的 failure 是不能注冊用戶。由于 error 及 failure 是不可避免的，所以在代碼設計上更多的是做容錯（fault-tolerance）。
我們可以通過服務之間進行良好的容錯設計，進一步用代碼 review，關鍵路徑的梳理來確保容錯策略的落實。上線的 checklist 來確保變更出現異常時候的應對。即便如此，容錯只能幫助我們規避大部分已知的問題，隨著系統長時間運行，總是有意外情況出現，曾經有同事碰到關鍵的服務中 出現內存出錯這種小概率事件，查出來之后，當事的工程師的肯定為了怎么寫好問題總結那一段話在絞盡腦汁。
當團隊規模比較小的時候，服務本身可控性還是比較強，關鍵路徑中的每一段代碼團隊成員非常熟悉。當出現異常問題，團隊成員也可以快速拿出處理方 法來解決。但是當系統變大，每個團隊只參與大系統一個環節時，問題會變得更復雜。從概率的角度，大的系統中小的模塊的 failure 不可避免，容錯流程總是存在疏忽的地方。當系統中存在復雜的網狀調用，無法完全做到松耦合（理想的松耦合是指一個服務的失敗不會引起另外一個依賴服務的失 敗），因此任何一個模塊中，可能由于一個缺乏經驗工程師的一行不經意的代碼造成整個大系統不可控的后果。
大型系統不可預知問題的排查通常需要更多時間，需要多個團隊共同參與來定位及解決問題。但在線服務由于可用性的要求，出了問題之后，解決問題的 緊急程度會比分析問題更高，因此并不會第一時間來討論及分析問題，現場的工程師需要憑有限的現象迅速做出判斷，將問題消滅在萌芽階段。但正是由于缺少完整 分析問題的時間，故障也往往難以第一時間有效解決，問題延續的時間比預期的要久也成為常見的現象。
對于公司來說，肯定希望所有的服務都有 99.999% 的可用性；但由于黑天鵝的現象，完美的可用性較難達到，這也很容易成為工程師的心理負擔。當穩定性出現問題后，負責的技術團隊心理沮喪程度不會比一個戰敗 的隊伍更好，甚至一些工程師還會造成長期心理上的壓力及陰影。夜深人靜時候電話突然響起，第一反應會心頭一緊，“莫非是服務出問題了？”。
工程師應該用什么樣的心態去看待出現的問題？
一方面，各種故障 failure 它確實是一種客觀存在，給用戶訪問及體驗帶來了不便。我們不會通過回避問題來避免它的出現。當出現問題后，需要通過問題復盤的方式，幫助我們來重審事件的 經過，檢查流程、機制、代碼等共性層面的問題，避免在同一個地方再次踩坑。同時也可以反思團隊在項目中的表現是否達到了平均以上的水平，是否存在一些低級 錯誤？
在另外一方面，如果問題超出了之前的認知及應對策略的范圍，屬于黑天鵝式的問題，則沒必要太多的自責。具有完美心態的工程師需要理性的看待各種批評及質疑，畢竟在一定程度，這是業界在共同應對的一個類型的難題，這些不穩定問題的出現也是在線服務的一部分。
來自: timyang.net<span id="shareA4" class="fl"> </span>本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
