總述
穩定性問題分為邏輯問題和架構問題。
邏輯問題三板斧：理念正確、流程規範、刨根問底。
邏輯問題
理念正確
曹操煮酒論英雄，對劉備發表了自己對英雄的看法：
胸懷大志，腹有良策，包藏宇宙之機，吞吐天地之氣。
意思是說所謂英雄，要志氣遠大，計謀精良。胸懷能包含宇宙，志氣能吞吐天地。對穩定性建設來說就是既要有道，又要有術，道為先。
穩定性理念舉例
Everything fails!
如果一件事情有可能發生則在生產環境中一定會發生。
不要容忍破窗戶。
過程對了結果一定不會差。
一個問題可能是許多事故的原因。
WHY
理念是目標和原則。錯誤的理念產生不了正確的行動，在穩定性方面是巨大的隱患。
試想如果一個人覺得一個系統是不可能出問題的，那他一定就不會制定故障處理的緊急預案，出現問題了也不能很好的控制影響範圍。
如果覺得一個問題是小概率事件是不會發生的，就不會對問題進行修復和補救。而所謂小概率事件如果發生概率在萬分之一。一般線上系統一天呼叫量就不只幾萬次，所以也就沒有什麼小概率事件了。
小的問題不修復，問題積少成多，不但修復變的困難，還會讓人產生反正已經這樣了的放棄心理，最終造成大問題。
流程規範
很多大公司的穩定性60%以上都是通過流程來保障的，有些流程經過自動化，開發人員習以為常，反而沒有去深究其背後的技術原理。比如變更管理流程，一般大公司會有相應的系統，而這個系統實際上是將變更管理的所有要點做了自動化。
變更管理
變更管理大體上分為兩部分：變更識別和變更流程。
變更識別：
要限制變更的影響，首先應該確保每一個生產變更都要有以下的資料記錄
1>變更的準確日期和時間
2>將要發生變更的系統
3>實際的變更
4>變更期待的結果
5>變更人員的聯絡方式
變更流程：
1>提出2>批准3>計劃4>實施5>驗證6>報告
變更識別是適用於初創型小公司的一種輕量級流程，一般有一定規模的公司都會使用變更流程。而變更流程的大部分過程都可以通過持續整合實現。這個過程的目的是為了安全的變更而不是減緩變更。
在實際開發的時候通常會遇到一個矛盾：一方面要控制發版頻率和時間，因為變更要耗費時間和精力，最重要的是每次上線都有風險。所以會有靜默期、發版許可時間；另一方面要讓變更儘量小，因為變更越大風險越高。
對於這個矛盾，我的看法是這兩個是兩個分開的問題。
發版時間只要控制在低峰期以及人員齊全的時間段，比如不要在週五，因為週六休息，問題不能及時發現。發版頻率需要靠每次問題解決徹底、每次釋出階段清晰等設計開發層面解決，就是說每次發版儘量：與其揚湯止沸，不如釜底抽薪。這樣一個問題或功能確保一次上線成功，不用打補丁，這樣來減少頻率。
變更儘量小，我的看法是最好一次釋出只是一個變更，不要多個成員的不同內容一起上線。否則一旦出現問題不好定位。有的人看法是3個內容一起上線只有1次風險，而分三次上線會有3次風險。我認為哈，如果3次變更真的出現了3個問題是不是程式碼質量太差了，需要從其他方面先把質量提升上來。而分為3次，每次變更內容清晰，也便於更高的流程把控和上線驗證，風險總體是要低的。
風險管理
評估特定行動風險有種方法叫故障模式及影響分析法(Failure mode and effects analysis, FMEA)。
每個故障的現象可以根據下述三個因素來打分：故障的可能性、嚴重性和可檢測性。可以選擇使用1、3和9作為打分的範圍，這是一種保守的打分方法，同時可以把高風險因素和中低風險因素區分開來。故障的可能性基本上是這個特定故障真實發生的概率。故障的嚴重性是指如果故障發生，對客戶和業務產生的總體影響。這種影響可以用金錢損失、聲譽損失或任何與業務有關的其他因素來測量。故障的可檢測能力指如果故障發生你是否能夠注意到。
對單項失效模式和效果打分後，將這些分數相乘得到總的風險評分，即可能性得分*嚴重性得分*檢測能力得分。這個分數顯示了一個特定元件在整體行為中的整體風險。
FMEA過程的下一步是確定可以執行或落實到位的緩解步驟，已降級特定因素的風險。例如，如果一個功能元件的可檢測能力有非常高的風險分數，這意味著如果事件發生，那將很難發出通知。因此該團隊可能會決定提前準備一些查詢，在產品或服務釋出後，每小時檢查一次資料庫，檢測是否有故障發生的跡象，如丟失資料或資料錯誤。此環節措施對該元件的風險因素有降級的作用，同時應該說明風險可以降級到什麼程度。
流程規範術例項
1>設計階段
統一設計模板、其中我編寫了穩定性三十六計的checklist，可以作為穩定性設計的參考規範，詳見：《穩定性「三十六計」實戰和背後的邏輯》
2>開發階段
2.1>可行性驗證階段寫好測試用例，測試驅動開發
2.2>與第三方互動，互動前後都要打日誌。互動後的日誌要把第三方返回的結果列印出來。一旦第三方出現問題。我們拿著第三方返回的結果來跟第三方溝通。避免責怪他人訛的出現。
3>上線規範
提測分支至少2名同學進行code review。Reviewer一般為之前負責過此模組開發的同學和架構師。
刨根問底
還是那句話：與其揚湯止沸，不如釜底抽薪。實施刨根問底最常用的手段是覆盤。說覆盤先從問題的發生說起。
一旦出現了問題或者故障，第一反應是什麼？找原因？錯！第一件要做的事情是「恢復現場」，先解決問題，控制和降低影響。比如生產環境突然load飆升、執行緒池被打滿了。這時候應該馬上啟動緊急預案，重啟服務或者機器，然後緊急擴容。如果問題發生前有過變更，則立即回滾。在發生問題的時候最好有個指揮者負責分派任務和協調人員。
現場恢復後再著手調查原因，可以多個人從不同層面來分析問題。比如這次問題主要是一個變更引起的。那麼變更的開發人員是問題分析的主力，一般也是問題的責任人和覆盤的發起者。但是其他人可以同時通過程式碼review、監控等資料分析角度幫助一起定位。
原因基本定位之後，如果大家都還沒離開。一個比較好的方式是以非常輕鬆的聊天的方式，讓瞭解問題的人都自然的聚在一起，開一個頭腦風暴的茶話會，將問題事前、事中、事後可以優化的都提出來，作為事件正式覆盤前的素材。
覆盤的流程
1>事件概述 2>事件影響 3>時間線 4>5why根本原因分析 5>經驗教訓 6>TODO
總結
穩定性問題中邏輯問題和架構問題的產生原因和側重點都不同。架構問題如果不快速治理，很容易造成級聯故障、雪崩等問題，從而引發穩定性危機。而架構大體滿足需求時，邏輯問題是日常工作中更經常面對的問題。
減少邏輯問題一要靠人二要靠流程。所謂靠人，就是人的能力和素質越強，問題越少。其中素質就包含理念價值觀和刨根問題的精神和能力。對於流程，很多大公司都有很好的工具或系統來進行流程規範。但是作為開發人員，一定要避免「離開了平臺，自己什麼都不是」。流程規範的系統實現都很簡單，關鍵點是實現了什麼，平時的時候建議多加思索，將平臺能力轉化為自身能力。
最後，這句話很重要：「與其揚湯止沸，不如釜底抽薪。」
相關閱讀