作者 |Bella醬
你好呀，我是Bella醬～
“又不是不能用，能用就行。”“又不是不能跑，能跑就行。程序和人有一個能跑就行。”
相信很多同學都聽過這2句話。乍聽沒毛病。編程3部曲，“make it run，make it fast，make it better”。上述2句話，我將其歸結爲“make it run”這一個階段，單看這一階段，沒有問題，但是若始終在這一階段，那就有問題了。
什麼是穩定性呢？我將其歸類到“make it better”這個階段。穩定性是通過一系列手段提前發現問題，力求將問題扼殺在襁褓中；穩定性要求在問題發生時，先於業務感知問題，處理問題，進而將問題影響面降至最小；穩定性要求問題發生後要有覆盤，覆盤哪裏可以改進，以避免再次發生此類事情。簡言之，穩定性就是爲了保障系統正常運行，保障業務如絲般順滑，保障數據準確無誤。
穩定性並非只能夠做一些零零散散的事情，穩定性也是有章可循的，有體系化的方法的。本文將從機制管控、監控告警、梳理系統風險點、保命措施、線上問題應急機制、故障演練、事後覆盤、宣講這8個方面來講解業務團隊如果在日常工作中做穩定性，可謂是涵蓋了事前、事中、事後的方方面面。
1.機制管控
所有事情，能上系統就上系統，靠人來運轉風險是極高的。這個道理，我相信很多同學都是明白的。穩定性保障亦是如此，通過一系列機制和系統強管控來規範日常工作中的一些行爲。
下面這些都是可以參考的：
1）分支發佈必須merge origin master分支的代碼。
2）分支發佈必須cr，且必須通過測試人員同意纔可發佈。開發、測試不可爲同一人，除非測試認可開發自測即可。發佈人員和cr人員不可爲同一人。
3）分支發佈需要在系統中有記錄，內容至少包含發佈時間、發佈分支、發佈內容、影響面、是否測試通過等等。
4）制定發佈窗口，窗口外的時間如果需要發佈，則需要走審批，審批人員可以是老闆，也可以是團隊內負責穩定性工作的人員，也可以視團隊情況設置爲其他的人員，例如團隊核心開發等。制定發佈窗口主要是爲了防止晚上或週末發佈的情況，避免發佈出現問題時響應和處理不及時。
5）制定發佈流程，主要是服務器環境這方面的，例如發佈系統設置分支必須先在日常環境部署成功，才能部署預發；只有預發環境部署成功，才能部署線上；發佈線上時，必須先在beta環境部署成功，且觀察規定時間內，才能繼續發佈至線上；線上至少分幾批來發布，每一批至少觀察多久等等。
6）禁止流量一刀切，必須有逐步灰度的過程。通過發佈機器的佔比也好，通過業務中帶灰度標的方式也好，必須要逐步灰度，禁止流量一次性全部切換。逐步灰度的過程是一個驗證功能，暴露問題的過程，灰度範圍是可控的，可以將灰度範圍告知業務方，以便出現問題時，業務方知道哪裏有了問題，而不是摸不着頭腦。
7）數據修復必須通過工具來操作，工具要可獲取當前操作人員，操作時間等，工具要具備check數據修復正確性的能力，工具的每次使用要在後臺有記錄，方便以後查看歷史操作記錄。
2.監控告警
監控告警的意義在於先於業務方發現問題，可以極大的提高響應速度，更快的開始定位問題。問題一旦定位到，影響面也就可以評估出來了，此時應該考慮如何快速止血，將影響面降至最低。
監控告警設置時有以下幾點需要注意：
1）告警範圍。切忌只告警給某個人，這樣風險太大，例如當這個人在洗漱時就可能會錯過告警信息。可以建一個釘釘告警羣，把和這個業務相關的同學都拉進去，以及團隊內負責穩定性的同學、老闆等等。這樣避免了“單點不可用造成服務宕機的情況”，即使一個人錯過了告警信息，還有其他人，只要有人看到報警信息並處理就ok。
2）告警優先級。不同情況需要設置不同的告警優先級。舉一個簡單的例子，以服務成功率來說，持續3分鐘成功率低於97%，可以告警至釘釘告警羣；持續5分鐘成功率低於97%，可以短信告警至訂閱人；持續10分鐘成功率低於97%，可以直接電話訂閱人。
3）告警內容。這個需要視團隊服務現狀而定。一般來說，DB層面的監控告警、服務成功率層面的監控告警、服務處理失敗數的監控告警、機器層面的監控告警等是必須的。DB監控告警例如CPU使用率、連接數、QPS、TPS、RT、磁盤使用率等。機器層面的監控告警例如CPU使用率、load、磁盤利用率等。服務成功率的告警配置時需要考慮持續時長。
4）告警有限性驗證。這點是非常關鍵的，如果告警無效，那上述告警範圍、優先級、內容這3個工作就是徒勞的。如果告警設置的閾值太高，那告警將起不到任何作用。如果告警設置的閾值太低，那每天都會接受到大量的告警，久而久之，就對這些告警疲倦了，等哪天狼真的來了，人們可能已經不相信了。經過壓測，摸清了服務、DB、機器等的基線後，根據基線設置的告警是最可信的。若前期沒有壓測，可以先觀察一下日常的水位，將告警閾值設置低一些，後面再根據告警情況慢慢調整告警的閾值。
3.梳理系統風險點
古人云，知己知彼，百戰不殆。爲何要知彼呢？知彼，你才知道他的弱點。做穩定性亦是如此。瞭解系統，你纔會知道系統的風險點在哪裏。當然，完全瞭解一個系統，是需要投入大量的時間和精力的。古人又云，君子性非異也，善假於物也。那梳理系統風險點的前期，你可以借一下你可愛的同事們的力呀～找到對應應用的owner，瞭解一下現狀，以及潛在的風險點，以及是否有應對措施。
在梳理系統風險點時，需要關注以下幾點：
1）鏈路是否閉環。這點是非常關鍵的，因爲如果是系統層面的缺陷，那影響面一定是很大的。梳理鏈路是否閉環時，需要你跳出開發的思維，以審視一個產品的角度來考慮，這個產品是否可以在任何情況下正常的run起來。如果發現系統不閉環，一定要第一時間告知產品和老闆。然後再從產品的角度來考慮如何解決這個問題，需要開發什麼功能才ok，然後再將此作爲高優先級的開發任務去進行排期修復。
2）慢SQL。慢SQL的威力是非常大的，一條慢SQL的執行可能會直接拖垮一個庫，此時如果再有其他SQL請求執行，那其他SQL的執行耗時也會放大很多，這個時候，對於開發人員來說往往難以分辨哪些纔是真正的慢SQL。此時需要靜下心來根據時間點來慢慢查找真正的慢SQL，或者求助DBA同學，專業的同學做專業的事情，結果會更可靠，耗時也更短一些。如果是自己找到了慢SQL，最好和DBA同學求證一下自己查找的結果是否正確，以免錯過了真正的慢SQL。
3）核心應用、非核心應用是否互相影響。不同重要等級的業務，應該在物理維度直接隔離。常說的讀寫分離也是這個道理，讀寫請求分別訪問不同的機器組，以免互相影響。除此之外，還有DB維度的分離。
4.保命措施
機制管控、監控告警、梳理系統風險點都是爲了防止問題的發生。可是，常在河邊走哪有不溼鞋？如果線上發生了問題，要怎麼快速止血呢？這個時候，就需要日常工作中準備好一些保命措施了，如果等到問題發生時，再去做準備，就有點太晚了。
那有哪些保命措施呢？
1）限流。雖然限流會導致一部分請求失敗，但是他會減輕服務壓力，減輕DB壓力呀，在有些時候是可以用來保命的。常用的限流工具有Sentinel。日常工作中，可以先在Sentinel控制檯配置好限流值，問題發生時，直接推限流開關即可。可以針對集羣限流，也可以對單機配置限流，這個要看具體的業務場景和需求了。可以對所有應用來源進行限流，也可以對某些特定應用配置限流值，這個也是看具體的需求了。
2）降級。降級分爲有損降級和無損降級。有損降級是業務感知的，無損降級只是技術側的，例如查詢從一個數據源降級爲另外一個備用數據源，業務側毫無感知。有損降級，比較典型的例子就是春晚搶紅包活動，百度直接公告通知除夕當晚，百度雲盤登錄註冊降級，以保障春晚搶紅包活動順利進行。對於有損降級來說，要在日常工作中就定義好，何種情況下，系統達到什麼指標了，纔可以進行有損降級。以免問題發生時，考慮過少，直接降級，導致更嚴重的問題發生。
3）切流。當一個機房的服務器發生了網絡問題或硬件設施問題或其他導致機房不可用的問題時，可以切流至其他機房。當一個數據源不可用時，也可以切流至備用數據源。這些都可以減小問題的影響面，或解決問題。
4）布控。如果是和外部用戶打交道的服務出現了問題，可以通過業務方或其他方式通知外部用戶，告訴他們此時系統發生了問題，相關同學正在解決中，以安撫他們，而不至於讓外部用戶一臉懵逼，不知所措。一些官方號通過發微博的方式告知用戶，也是布控的一種。
5）上下游、DBA等的聯繫方式。有時候可能並非自己系統的問題，而是上下游系統異常，間接導致自己系統的成功率下跌，這個時候，掌握上下游合作方同學的聯繫方式就很重要了，可以快速通知對方，讓對方介入排查。有時候也可能是DB發生了問題，需要DBA協助解決纔行，所以掌握DBA的聯繫方式也是非常重要的，DBA同學一個小小的命令可能就能拯救你於水火之中。
限流、降級、切流、布控等保命措施均需要清晰的定義系統哪些指標達到什麼值時，纔可以執行這些措施。這樣當問題發生時，可以快速做出決策判斷，也避免了使用不當造成更大問題。
5.線上問題應急機制
真的有線上問題發生了，怎麼辦？莫慌，越慌越亂。
首先，需要做到快速響應，表明已經有人在定位問題了。問題定位到之後，應該將如何快速止血放在第一位。此時就可以將上述的保命措施用上了。如果保命措施都用不到怎麼辦？只能採取其他措施了，通過發佈解決也是一種方式。
一個人是無法很好的快速應急的。需要有通訊員和外部溝通，及時彙報當前進展；需要有處理人定位問題，評估影響面，給出建議；需要有決策人員，可能是團隊內穩定性負責人，可能是老闆、也可能是業務方等，決策如何快速止血。達成一致決策後，處理人按照決策執行即可，通訊員保持和外部及時的溝通。
6.故障演練
故障演練的目的是模擬故障發生時，大家的真實反應，以及是如何處理問題的。所以故障演練不要提前告知團隊同學，更不要提前告知是何種線上問題，否則演練將毫無意義。當然，故障演練還應該把握好度，以免影響到線上業務。
7.事後覆盤
線上問題發生後，無論大小，都應該有相應的覆盤，小問題可以是小範圍的覆盤，大問題可以進一步擴大覆盤參與人員的範圍。
主要覆盤哪些內容呢？
1）何時發現問題？
確定時間點
2）哪種方式發現的問題？監控告警還是業務方反饋？
以確定監控告警是否有效，是否有可優化的空間。
3）何時響應問題？
以確定響應是否及時，是否有可優化空間
4）何時定位到問題？
以評估對系統的熟悉度，或對線上問題的響應處理能力。有的同學可能是因爲對系統不夠了解，所以需要耗時很久才能夠定位到問題；有的同學可能是因爲遇到事情時，或高壓下，心理素質不夠，導致手忙腳亂，所以才耗時比平時更久。兩種情況，可提升的能力是不同的。
5）有無快速止血措施？
例如限流、降級、切流等。可看平時保障工作是否到位。如果發現有缺失，則可以記爲一個action，後面工作中把這一塊給補上。最好的方式是，同步梳理下，系統中是否還有其他缺失的快速止血措施，並一起做掉。
6）需要上下游或DBA介入的情況，協同是否順暢？
以評估協同溝通是否有可提升的空間，畢竟需要上下游或DBA介入的情況，如果可以快速聯繫到對應同學的話，是可以節省很多時間的，有助於更快速的解決問題。
8.宣講
穩定性從來都不是一個人的事情，它關係到每一位同學，也是每一位同學應該銘記於心的事情。
在接需求時，需要考慮需求是否合理，鏈路是否閉環。
在寫代碼時，需要考慮代碼的健壯性，語法使用是否正確，是否在寫慢SQL。
在發佈時，需要考慮測試是否通過，是否在發佈窗口期，是否有灰度策略，發佈時若發現問題應如何處理，是否可回滾等等。
在線上問題發生時，如何快速應急也是每一位同學都應該瞭解的。
一些宣講還是很有必要的，以幫助每一位同學更好的瞭解自己應該如何做以保障系統的穩定。
-END-
本文分享自微信公衆號 - Kirito的技術分享（cnkirito）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。