前言
在開始介紹服務穩(wěn)定性之前，我們先聊一下SLA。SLA（service-level agreement，即 服務級別協(xié)議）也稱服務等級協(xié)議，經(jīng)常被用來衡量服務穩(wěn)定性指標。通常被稱作“幾個9”，9越多代表服務全年可用時間越長服務也就越可靠，即停機時間越短。通常作為服務提供商與受服務用戶之間具體達成承諾的服務指標——質(zhì)量、可用性，責任。
3個9，即99.9%，全年可停服務時間：365 * 24 * 60 *（1-99.9%）= 525.6min
4個9，即99.99%，全年可停服務時間：365 * 24 * 60 *（1-99.99%）= 52.56min
5個9，即99.999%，全年可停服務時間：365 * 24 * 60 *（1-99.999%）= 5.256min
在嚴苛的服務級別協(xié)議背后，其實是一些列規(guī)范要求來進行保障。
一、系統(tǒng)穩(wěn)定性建設是指什么？
關于系統(tǒng)穩(wěn)定性是指什么這一問題，相信好多開發(fā)同學都會有自己的理解和認知，但可能會存在是否理解片面或者是否標準的疑惑，那到底有什么判定標準和劃分邊界呢？
我們不妨看下來自于維基百科的解釋：
穩(wěn)定性是數(shù)學或工程上的用語，判別一系統(tǒng)在有界的輸入是否也產(chǎn)生有界的輸出。
若是，稱系統(tǒng)為穩(wěn)定；若否，則稱系統(tǒng)為不穩(wěn)定。
簡單理解，系統(tǒng)穩(wěn)定性本質(zhì)上是系統(tǒng)的確定性應答。
從另一個角度解釋，服務穩(wěn)定性建設就是如何保障系統(tǒng)能夠滿足SLA所要求的服務等級協(xié)議。
本文重點介紹服務端穩(wěn)定性需要考慮的關鍵要素和策略，重點介紹變更之外的穩(wěn)定性保障。
總結(jié)一下，穩(wěn)定性的時間節(jié)點主要包括：
1、事前：消除潛在風險，確保系統(tǒng)穩(wěn)定運行不出問題。上醫(yī)治未病，所以這一點要重點投入。
2、事中：監(jiān)控快速感知和響應的體系，包括風險的感知、控制，并且團隊要訓練有素才能最快速度消除風險。
3、事后：深度復盤和改進，在系統(tǒng)運行過程中對已發(fā)生問題的總結(jié)、故障的處理、優(yōu)化和預防措施的制定。
二、穩(wěn)定性建設具體動作
1、事前：
我們先看下事前可以做的事情，或者說平時的研發(fā)規(guī)范、預防的實踐：
變更過程中的風險更多來自變更前的設計、代碼質(zhì)量、review、自動化測試等，而不是僅僅依靠灰度、監(jiān)控和回滾。
研發(fā)規(guī)范
1、定期業(yè)務串講：定期業(yè)務串講有助于各個業(yè)務線之間的業(yè)務互相熟悉、減少以后的溝通成本，并且有助于新人快速熟悉業(yè)務，對于各個業(yè)務的owner也能更加深刻的理解業(yè)務。
2、技術(shù)方案評審：
1）通過評審，可以確保后端技術(shù)方案的質(zhì)量，避免在項目實施過程中出現(xiàn)問題。這可以幫助團隊更好地理解項目的需求，確保技術(shù)方案能夠滿足這些需求。
2）可以幫助團隊識別和解決可能的技術(shù)風險，降低項目失敗的風險。這可以包括技術(shù)債務、性能問題、安全問題等。
3）通過評審，可以確保團隊的技術(shù)方案是有效的，從而提高開發(fā)效率。這可以幫助團隊更好地利用資源，提高項目的完成速度。
4）評審可以幫助團隊成員更好地理解彼此的技術(shù)方案，提高團隊協(xié)作效率，還可以幫助團隊成員更好地理解項目的需求。
5）評審可以幫助團隊確保后端技術(shù)方案的可擴展性，以應對項目的增長和變化?？梢猿浞职l(fā)揮團隊的力量，一起探討技術(shù)選型和可擴展性
3、代碼review：Code Review是現(xiàn)代軟件開發(fā)團隊中非常重要的一環(huán)，因為它可以帶來以下幾個方面的好處：
1）提高代碼質(zhì)量:?通過代碼審查，開發(fā)團隊可以及時發(fā)現(xiàn)和修復代碼中的問題，包括代碼中的錯誤、潛在的安全漏洞、缺陷和性能問題等，從而提高代碼的質(zhì)量。
2）減少維護成本:?通過及時發(fā)現(xiàn)和修復問題，代碼審查可以降低后續(xù)維護成本，因為修復問題的成本通常比在后期修復更低。
3）加強知識共享和團隊協(xié)作:?代碼審查可以幫助團隊成員了解項目中其他成員的工作，從而促進知識共享和團隊協(xié)作，提高團隊整體的開發(fā)能力。
4）提高編碼規(guī)范和標準的遵守: 通過代碼審查，可以促進團隊成員遵守編碼規(guī)范和標準，統(tǒng)一團隊的代碼風格和代碼質(zhì)量要求，提高代碼可讀性和可維護性。
5）促進開發(fā)者的技能提升和成長：代碼審查可以幫助開發(fā)者了解項目中的技術(shù)細節(jié)和最佳實踐，從而促進開發(fā)者的技能提升和成長。
切流預案
1、新功能開關：新上線的功能需要添加分布式配置開關，如果有問題，可以及時切換到舊版本。
2、灰度放量預案：灰度按百分比放量是一種軟件開發(fā)中常用的功能發(fā)布方法，它可以幫助提高軟件可靠性，提高用戶體驗，在實施時也需要注意幾個方面：
1）確定放量目標：首先需要確定放量的目標，例如增加多少百分比的數(shù)據(jù)量。這個目標需要根據(jù)實際情況進行制定，例如需要考慮數(shù)據(jù)量的大小、計算資源的限制等因素。
2）確定放量規(guī)則：你需要確定在放量過程中，哪些功能會被啟用，哪些功能會被禁用。你可以根據(jù)開發(fā)進度、測試結(jié)果和市場需求等因素來確定放量規(guī)則。
3）監(jiān)控放量過程：在實施放量操作時，需要監(jiān)控放量過程，以確保放量結(jié)果的穩(wěn)定性和可靠性。如果出現(xiàn)異常情況，需要及時采取措施進行調(diào)整。
穩(wěn)定運行
1、機器健康度：磁盤空間、網(wǎng)絡抖動、流量不均引起單機風險等。尤其是磁盤空間滿，對于成熟團隊來說應該是低級事故，不應該出現(xiàn)。應該有完善的平臺、機制確保一定不會出現(xiàn)磁盤滿。
2、容量規(guī)劃：計劃中的大促等，需要提前規(guī)劃好容量。在規(guī)劃前需要準確壓測摩的系統(tǒng)性能數(shù)據(jù)。
3、自愈能力：這是一項高級但也非常必要的能力?？梢耘e一個典型的發(fā)面案例：系統(tǒng)異常導致內(nèi)存中的任務隊列大量堆積，異常清除后還在持續(xù)消費內(nèi)存中堆積的任務，必須人工重啟來干預。這種情況下，應該設置合理的隊列最大長度、丟棄過期的任務、背壓等手段來實現(xiàn)自愈，避免依賴人工干預導致故障恢復時間拉長。
4、極限壓測：理想的壓測應該是常態(tài)化進行極限場景壓測、每次變更前后進行壓測、定期進行線上流量回放壓測以及時發(fā)現(xiàn)流量特征變化對性能的影響。實際中，因為自動化程度不夠高，不能完全做到，但是要持續(xù)往這個方向發(fā)展。
團隊訓練有素
以上的風險感知、風險控制手段能否有效執(zhí)行，取決于團隊是否訓練有素。平時頭腦清醒，重大故障期間慌的不知所措時很容易出現(xiàn)的，即使有預案也想不起來或者不敢執(zhí)行。
1、應急預案演練：前面講過，只有反復演練過的故障才敢真的去執(zhí)行，尤其是有損預案。
2、突襲演練：突襲更接近于真實場景的演練，日?？梢詧F隊內(nèi)互相突襲，也可以找風險團隊協(xié)助聯(lián)動做紅藍對抗突襲。
3、故障響應演練：專業(yè)的故障響應過程，一定要有多個訓練有素的角色高效配合才能最大限度壓縮故障時長，要有指揮員負責整體把控、資源協(xié)調(diào)，通訊員負責信息收集、對組織內(nèi)和客服甚至公關口徑及時傳遞有效信息，要有專人去執(zhí)行預案盡快恢復服務，也有要人去分析原因確保元無法消除影響后進一步處理。最典型的不專業(yè)表現(xiàn)是故障后所有人都撲上去尋找原因，這是大忌。如果看過足夠多集團重大故障的話，應該能夠發(fā)現(xiàn)我們有不少的故障原因是十幾個人數(shù)天時間才能真正分析清楚的。故障期間，原因分析之要能滿足故障恢復即可，不要強迫自己一定要分析到根本原因。比如服務異常后，定位到是db異常，這個時候如果有提前db降級預案，就可以快速評估是否執(zhí)行了，而不是分析db異常的根本原因，我們有些db異常最后分析到是mysql內(nèi)核層的bug,如果要分析到這種級別的根本原因才能恢復服務那對業(yè)務來說絕對是災難。
2、事中：
風險感知
1、監(jiān)控：監(jiān)控這部分需要單獨做系統(tǒng)性設計，后面單獨分享。原因是平時還是經(jīng)?？吹胶诵南到y(tǒng)都有監(jiān)控，但是監(jiān)控的覆蓋面、問題診斷能力嚴重不足。做的稍微好點的有調(diào)用量、成功率、耗時等監(jiān)控，做的差的只有幾個調(diào)用量的監(jiān)控根本不具備問題感知能力。還可以添加同比環(huán)比這類指標，如果指標下降明顯，可以觸發(fā)相應報警。
2、預警：預警首先要覆蓋所有故障場景，直接造成故障風險的一定要有電話告警。而且預警要持續(xù)優(yōu)化，降低到大家每條都能處理的程度，過度告警等于沒有告警了。
3、反饋：收到預警后要能快速處理，可以值班也可以由指定人跟進。
風險控制
1、容災切換：如果有同城容災、異地容災、單元化、區(qū)域化等容災手段的話，切換到其他可用區(qū)是一個可用快速恢復服務的手段。
2、限流：當DB出現(xiàn)大量慢SQL，突發(fā)流量造成容量風險時候，限流是避免系統(tǒng)徹底崩潰的有效手段，限流能力必須提前做好建設。
3、降級：降級通常會有一定的犧牲，但是可以確保核心的功能可用，比如犧牲一定體驗。一般提前會有預案，在代碼和配置中一般提前會有各種情況的降級措施。
4、故障隔離：通常是最后沒有辦法的時候的手段，比如新設備上線后會在很長一段時間里會有獨立的接入點，避免新設備的訪問異常造成無線大的訪問沖擊影響其他存量設備接入。避免故障影響上下游，所有依賴的服務和被依賴的服務
值班機制
1、輪流值班：每天安排指定人員值班，有問題如果自己能解決直接處理，無法解決可聯(lián)系相關owner，并記錄相關問題和進展。
2、服務有主備：每個微服務的owner要有主備負責人，出問題的時候，如果owner有特殊情況無法第一時間處理，可由另一個owner及時解決。
3、問題及時反饋：處理不了的問題，及時將工單轉(zhuǎn)給相應負責人，系統(tǒng)告警要及時ack，并跟進處理。
及時止損
1、及時通知：有問題第一時間發(fā)出通知，通知對應的上下游，以及所有可能影響到的業(yè)務方。
2、及時降級服務：核心服務如果默認降級措施無法生效，及時降級到緊急預案。
3、及時恢復數(shù)據(jù)：在技術(shù)方案設計階段其實就已經(jīng)要有相應的恢復數(shù)據(jù)的預案，故障發(fā)生時，評估相應影響后，及時恢復數(shù)據(jù)，可將損失降到最小。
4、及時擴容：及時關注系統(tǒng)資源利用率，提前規(guī)劃好，及時擴容。
5、及時修復：如果是小問題，不適合回滾的項目，可申請bug修復上線；若適合回滾的項目，根據(jù)監(jiān)控的波動曲線，如果對應指標下降明顯，及時回滾代碼。
3、事后：
復盤
事后的首要任務是對發(fā)生的故障進行分析，并定位根本原因。這包括收集故障發(fā)生時的日志、性能數(shù)據(jù)以及相關事件信息。通過深入分析這些數(shù)據(jù)，可以找到問題的起因，從而避免類似問題再次發(fā)生。復盤的目的不是為了懲罰，而是為了以后不犯類似的錯誤，而且復盤可以發(fā)掘系統(tǒng)中類似的缺陷，并及時改進。以下是一些在事后階段可以采取的策略和措施，以確保系統(tǒng)的持續(xù)穩(wěn)定性。在這個階段，可以采用以下策略：
1、5why分析法：所謂5why分析法，又稱“5問法”，也就是對一個問題點連續(xù)以5個“為什么”來自問，以追究其根本原因。雖為5個為什么，但使用時不限定只做“5次為什么的探討”，主要是必須找到根本原因為止，有時可能只要幾次，有時也許要十幾次，如古話所言：打破砂鍋問到底。5why法的關鍵所在：鼓勵解決問題的人要努力避開主觀或自負的假設和邏輯陷阱，從結(jié)果著手，沿著因果關系鏈條，順藤摸瓜，直至找出原有問題的根本原因。
2、日志分析：?仔細檢查系統(tǒng)的日志，包括錯誤日志、調(diào)試日志等，以找出故障的發(fā)生時間、位置和可能的原因。
3、性能分析：?利用性能監(jiān)控工具，分析故障發(fā)生時系統(tǒng)的性能指標，找出可能的性能瓶頸。
4、事務追蹤：?對系統(tǒng)中關鍵業(yè)務流程進行事務追蹤，以確定故障發(fā)生時的具體業(yè)務場景。
5、定責：根據(jù)公司規(guī)定和影響范圍來定責。
6、定級：復盤后，根據(jù)結(jié)論對當前故障定級，并發(fā)出公告。
性能優(yōu)化
在故障發(fā)生后，對系統(tǒng)的性能進行全面分析，找出瓶頸和問題點，然后制定性能優(yōu)化策略。這可以通過以下方式實現(xiàn)：
1、性能測試：?針對關鍵業(yè)務場景進行性能測試，找出系統(tǒng)在高負載情況下的性能瓶頸。
2、代碼審查：?對系統(tǒng)的核心代碼進行審查，尋找潛在的性能問題，并進行必要的重構(gòu)。
3、數(shù)據(jù)庫優(yōu)化：?針對數(shù)據(jù)庫的查詢性能進行優(yōu)化，包括索引優(yōu)化、查詢語句優(yōu)化等。
自動化運維
在事后，可以加強系統(tǒng)的自動化運維，減少人為操作的風險。自動化運維包括：
1、自動化部署：?使用持續(xù)集成/持續(xù)部署（CI/CD）工具，實現(xiàn)自動化的部署流程，減少部署過程中的人為錯誤。
2、自動化測試：?擴展自動化測試覆蓋范圍，包括單元測試、集成測試、端到端測試等，確保每次發(fā)布都是可靠的。
3、自動化監(jiān)控與預警：?將監(jiān)控和預警的設置與運維流程相結(jié)合，實現(xiàn)對系統(tǒng)狀態(tài)的實時監(jiān)控和及時響應。
安全審計與漏洞修復
事后還需要對系統(tǒng)進行安全審計，確保系統(tǒng)沒有潛在的安全風險。具體措施包括：
1、安全漏洞掃描：?定期使用安全漏洞掃描工具，對系統(tǒng)進行全面掃描，及時發(fā)現(xiàn)并修復潛在的安全問題。
2、代碼審計：?對系統(tǒng)的代碼進行審計，檢查是否存在安全漏洞和潛在的風險點。
3、安全培訓：?對團隊進行定期的安全培訓，提高團隊成員的安全意識，減少因為人為失誤引起的安全問題。
文檔與知識庫更新
在事后階段，及時更新系統(tǒng)文檔和知識庫，記錄故障處理的經(jīng)驗教訓，為未來遇到類似問題的團隊成員提供參考。具體做法包括：
1、故障總結(jié)文檔：?匯總對于不同類型故障的總結(jié)文檔，包括根本原因、解決方案和未來預防措施。
2、運維手冊更新：?更新系統(tǒng)的運維手冊，包括部署流程、故障處理流程等，確保手冊的實時性和準確性。
3、知識庫建設：?建設團隊內(nèi)部的知識庫，匯總團隊成員的經(jīng)驗分享和技術(shù)教程，方便團隊成員學習和查閱。
性能監(jiān)控和持續(xù)優(yōu)化
引入持續(xù)監(jiān)控系統(tǒng)，實時追蹤系統(tǒng)性能和穩(wěn)定性，確保在生產(chǎn)環(huán)境中發(fā)現(xiàn)問題時能夠及時響應。具體策略包括：
1、監(jiān)控系統(tǒng)升級：?隨著系統(tǒng)規(guī)模和復雜性的增加，持續(xù)升級監(jiān)控系統(tǒng)，引入更智能的告警和分析功能。
2、容量規(guī)劃：?根據(jù)系統(tǒng)的使用情況，進行容量規(guī)劃，提前預測系統(tǒng)的資源需求，避免因為資源不足而導致的性能問題。
3、性能優(yōu)化迭代：?定期進行性能優(yōu)化的迭代，不斷尋找和解決系統(tǒng)中的性能瓶頸，提高整體性能。
災難恢復演練
定期進行災難恢復演練，檢驗災備和容災方案的可用性和有效性。演練可以模擬不同的災難場景，確保在真正的緊急情況下，團隊能夠迅速而有效地進行恢復操作。
三、穩(wěn)定性建設案例學習
美團點評智能支付核心交易系統(tǒng)的可用性實踐
https://tech.meituan.com/2018/04/19/trade-high-availability-in-action.html
參考文章：
穩(wěn)定性建設（一） http://www.itdecent.cn/p/68008fb8b025
