導讀：
隨着業務的不斷髮展，尤其是在2020疫情開始後，整個在線教育行業的競爭變得異常嚴峻，作爲這個行業的領路人，用戶流量更是成倍增長，這就對我們在線業務運維體系的穩定性提出了更高的要求。
對此網校整體產研部每年寒、暑假都會針對性成立寒、暑特戰隊。特戰隊成員爲各業務總接口人以及各專項總負責人
特戰隊成員共同目標爲：保障寒、暑假期間百萬學員同時穩定上課，無S0事故
每個部門方向均需要輸出負責人review過得保障方案，如需有風險，列出整改計劃
這裏我們從SRE視角對活動保障體系進行了系統性的梳理和總結，將好的沉澱總體分享給大家。整體來看，保障大致分成三個階段：重保前-重保中-重保後
重保前
一、架構高可用
1.架構設計的原則
.N+1設計。系統中的每個組件都應做到沒有單點故障；
.回滾設計。確保系統可以向前兼容，在系統升級時應能有辦法回滾版本；
.禁用設計。應該提供控制具體功能是否可用的配置，在系統出現故障時能夠快速下線功能；
.監控設計。在設計階段就要考慮監控的手段；
.多活數據中心設計。若系統需要極高的高可用，應考慮在多地實施數據中心進行多活，至少在一個機房斷電的情況下系統依然可用；
.資源隔離設計。應避免單一業務佔用全部資源；
.架構應能水平擴展。系統只有做到能水平擴展，纔能有效避免瓶頸問題
2.狡兔雙活架構設計總圖
二、壓測及容量保障
1.全鏈路接口壓測
a.直播全場景壓測試
場景業務說明：直播場景比較特殊 ，一個大的直播場景就是一堂課，而一堂課是由多個獨立的互動場景構成，所以這裏僅僅一個課中場景來整體覆蓋，肯定是不能準確真實的找到系統的性能問題的。爲了更貼近真實，覆蓋的更加深入，我們將直播課中場景按照小的互動形式，再結合着接口依賴，拆分成13個小場景，然後逐一場景去進行壓測。
b.平臺全場景壓測
場景業務說明：
2.監控大盤
.監控加固
從物理層面（服務器資源）、服務層面（進程、日誌、core）、數據層面（配置一致性、數據一致性）、業務層面（語義監控、訪問時延、域名）4個維度進行監控的補全,便於重保當天進行實時監測
a.基礎監控加固
做運維，不怕出問題，怕的是出了問題，抓不到現場，兩眼摸黑。所以，依靠強大的監控系統，收集儘可能多的指標，意義重大。但哪些指標纔是有意義的呢，本着從實踐中來的思想，我們在長期摸爬滾打中總結了在系統運維過程中，經常會參考的一些指標，主要包括以下幾個類別：
參考文獻：https://book.open-falcon.org/zh_0_2/faq/linux-metrics.html
b.網關集羣QPS大屏
內網地址：https://cloud.tal.com/tal-beacon#/1/gateway/cluster
c.消息系統大屏
內網地址：https://cloud.tal.com/msg/statistics/dataStatistics
d.網校直播課堂業務監控大屏
內網地址：https://cloud.tal.com/tal-beacon#/1/big-class
3.容量管理
.根據容量信息的確認，評估容量風險，如需擴容則安排資源協調和實例創建操作
a.基礎容量評估
進行線上環境監控覆蓋度檢查，補齊缺失監控指標，保障線上環境容量監控的有效性;確保監控覆蓋到全部資源/服務，報警功能是否正常;可按照以下性能和容量緯度（包含但不限於）：
- 用戶體驗、2.網絡層、3.入口層、4.服務層、5.緩存層、6.數據層、7.三方調用
b.壓測心得和注意事項
.關注服務端
壓測是爲了找出瓶頸，這個瓶頸可以是cpu的性能（計算）、網絡和磁盤（IO）性能等環境上的，也可以是程序的業務邏輯上的。不論如何，壓測時一定要將服務端的硬件使用情況監控起來
.關注客戶端
壓測時注意客戶端的資源如cpu、帶寬等是否已經到了上限，如果到了上限應該及時提升配置，或者做客戶端集羣（jmeter集羣需要大量的帶寬用來同步每個agent的壓測結果，需要格外注意），最後，還要特別留意你的客戶端腳本性能有沒有問題
.關注程序業務邏輯
對於業務程序，首先需要梳理接口的整體邏輯，比如在什麼情況下進行了幾次IO
.善用排除法爲結論背書
排除法也是壓測過程中一個重要的手段，如果基本推斷到某個地方非常影響性能，可以通過一些手段跳過這個地方的執行，看看性能是否能上來，以此證明你的結論
.爲你的想法背書，而非想當然
比如，對於網絡——如果你認爲你壓測過程中使用的是HTTP長連接（keepalive），那麼你關注服務端和客戶端的各種狀態的TCP連接數，確定真的是長連接；
比如，如果你認爲硬件越多性能越高，那一定要通過壓測證明一下，如，同時A壓B，C壓D，兩個壓測結果的和是不是單獨A壓B的兩倍
另外，有一些東西是公論則可以不必去費功夫，因爲已經有很多人在很多文章中爲你背書了——比如kafka的磁盤順序寫等
.確保壓測環境不互相干擾
在雲服務上壓測，請確定你的服務器資源是獨享型，否則壓測基本沒有什麼意義
.壓測報告務必詳細
壓測報告不只是給別人看的，更是你自己的工作證明，要詳細的羅列用到的硬件，什麼環境，壓測過程中各個指標的狀態，在各種參數情況下程序的吞吐量，壓測報告直接反應了一個人的能力，因爲你能力越強，你看到的關鍵參數越多
打個比方，從前我只關心cpu和內存，所以我做的壓測報告裏會有這些數據；後來我瞭解了HTTP長短連接的區別、網絡等知識，報告內容有所增加；再後來我發現磁盤也會成爲某些程序的瓶頸，磁盤IO也成了壓測報告中的內容……
4.安全加固
.主要針對外網攻擊、注入等問題進行攔截防護；程序本身需要考慮這部分內容（可使用安全掃描進行review)、可以接入阿里雲waf進行保護，能夠使用https則儘量使用https
三、放火演練及防護預案
1.放火演練
相信大家都碰到過大半夜被電話叫醒，開始緊張地查驗問題，處理故障以及恢復服務的情況。也許就是因爲睡前的一個很小的變更，因某種未預料到的場景，引起蝴蝶效應，導致大面積的系統混亂、故障和服務中斷，對業務造成影響。儘管有充分的監控告警和故障處理流程，這樣的情況仍時有耳聞。問題的癥結便在於，對投入生產的複雜系統缺少了解和信心。監控告警和故障處理都是事後的響應與被動的應對，那有沒有可能提前發現這些複雜系統的弱點呢？我們嘗試通過一些常規故障演練方案以及歷史case來進行相關係統放火演練操作，以達到逐步完善系統預案的過程
a.故障放火演練Checklist
b.演練注意事項
.演練前：
· QA推進RD補充完整每個case方案，完成方案梳理（演練記錄），共同確定方案可行性和安全性。包括確定方案演練範圍/sop/演練環境（線上、灰度）/預期/風險
· 準備演練需要數據，包括不限於功能驗證課程數據、模擬用戶流量的壓測腳本&場景（小量即可）
· 故障平臺上創建可執行故障case
· 對接哪些服務/場景/歷史記錄
· 在執行階段是否需要qa去做驗證
.演練中：
· 晚 10:30 or 11:00，checklist；
· 執行故障，做好過程記錄（開始時間、報警、恢復時間等截圖、功能驗證、存在什麼異常問題、是否通過），完成方案梳理（演練記錄）內的演練記錄/是否通過/執行人一欄。
· 問題項記錄，出現演練不符合預期問題，需記錄在演練問題彙總，便於後續跟進定位和覆盤。
.演練後：
· 恢復驗證，線上功能確保無恙。
· 更新當晚實施cheklist進度。
· 跟進需要複測的問題項。
2.混沌測試
a.什麼是混沌
2008年8月， Netflix 主要數據庫的故障導致了三天的停機， DVD 租賃業務中斷，多個國家的大量用戶受此影響。之後 Netflix 工程師着手尋找替代架構，並在2011年起，逐步將系統遷移到 AWS 上，運行基於微服務的新型分佈式架構。這種架構消除了單點故障，但也引入了新的複雜性類型，需要更加可靠和容錯的系統。爲此， Netflix 工程師創建了 Chaos Monkey ，會隨機終止在生產環境中運行的 EC2 實例。工程師可以快速瞭解他們正在構建的服務是否健壯，有足夠的彈性，可以容忍計劃外的故障。至此，混沌工程開始興起。
Netflix 開發的 Chaos Monkey 成爲了混沌工程的開端，但混沌工程不僅僅是 Chaos Monkey 這樣一個隨機終止 EC2 實例的實驗工具。隨後混沌工程師們發現，終止 EC2 實例只是其中一種實驗場景。因此， Netflix 提出了 Simian Army 猴子軍團工具集，除了 Chaos Monkey 外還包括：
.Latency Monkey 在 RESTful 客戶端到服務器通信中引入隨機延遲，以模擬服務降級並測量上游服務是否正確響應。
.Conformity Monkey 在發現不符合最佳實踐的實例時將其關閉。
.Doctor Monkey 會在每個實例中運行健康檢查，同時也通過其他外部監控指標來檢測不健康的實例。一旦檢測到不健康的實例，將它們從服務中刪除，並且在實例所有者找到問題的原因後終止。
.Janitor Monkey 搜索未使用的資源並按規則處理，以確保AWS上的環境資源有效避免浪費。
.Security Monkey 在發現安全違規或漏洞時，如發現未正確配置的AWS安全組，並終止使用該違規安全組的實例。此外，還會確保所有的 SSL 和 DRM 證書有效且無需續訂。
.10-18 Monkey （l10n-i18n）針對多個區域和國家的客戶提供服務的實例，檢查有關語言和字符集的配置。
.Chaos Gorilla 模擬了 AWS 可用區域（AZ）的中斷，以驗證服務是否會自動平衡至可用的 AZ ，而無需人工干預，也不會給用戶帶來可見的影響。
參考文檔：https://aws.amazon.com/cn/blogs/china/aws-chaos-engineering-start/
參考文檔：https://github.com/dastergon/awesome-chaos-engineering
參考文檔：https://cloud.tencent.com/developer/article/1622874?from=article.detail.1647276
參考文檔：https://github.com/chaosblade-io/chaosblade/blob/master/README.md
b.爲什麼我們需要混沌
自從2011年Netflix開發了Chaos Monkey以來，這款軟件變得越來越流行。如果想要構建一個分佈式系統，就讓Chaos Monkey來“糟蹋”這個集羣，這樣有助於構建出一個更具容錯性、彈性和可靠性的系統。
通常情況下，我們會盡可能多地編寫單元測試，確保能夠覆蓋所有的代碼邏輯，也會進行足夠多的集成測試，確保我們的系統可以與其他組件一起工作，還會執行性能測試，用以改進處理數百萬次請求的性能。
然而，這些對於分佈式系統來說還遠遠不夠。無論我們做了多少單元測試、集成測試或性能測試，仍然無法保證我們的系統能夠應對生產環境的各種不可預測性。我們可能會遇到磁盤故障、機器斷電、網絡隔離，而這些只是冰山一角。爲了讓分佈式系統更加健壯，我們需要一種方法來模擬不可預知的故障，並測試我們對這些故障的反應。這就是爲什麼我們需要Chaos Monkey
c.關於混沌未來方向展望
目前混沌測試我們還停留在實驗室環境階段，引入此工具的目的就在於優化原有的故障植入方式，並擴展一些新的植入場景，如網關服務異常，mysql操作，網絡異常，特定方法異常等。關於場景植入只是進行了初步設想，其中可能還存在一些細節考慮不夠到位，但其實可以看到的是，隨着我們性能保障能力的不斷提升。我們可以很容易地想像出更多更有效、更智能的可能。
此工具目前的實驗場景如下：
.自測階段的故障植入，在不需要變更真實邏輯的情況下，驗證自己的異常處理；
.組件在測試階段，模擬底層依賴服務的故障場景，驗證系統可用程度，降級方案是否生效等；
.業務故障演練時，在不需要變更真實邏輯的情況下，可以人爲模擬特定場景的故障異常，驗證止損方案是否可是有效的
3.防護預案
a.預案加固
.預案基本要求
.一個預案對應一個具體的操作場景，解決一個具體的異常問題/故障，包含關鍵依賴、關鍵前置依賴及檢查點、直接可執行操作步驟、直接可執行回滾步驟、結果驗證。重要服務及場景，需要做到人的double check
.觸發條件需要明確、量化
.預期影響是指執行預案過程中及之後的預期影響
.結果驗證checklist應該包括：動作、指標，通過指標判斷是否符合預期
.預案儘可能複用，觸發條件可以有多個
.預案執行過程需要儘可能自動化、高效
.制定明確有效的3大預案
.流量切換：制定實例間、機房間、地域間的流量切換預案，平臺或腳本方式執行，可快速完成生效（要求至少分鐘級別）；
.服務降級：服務本身做到後臺故障對於前端用戶無感知，或服務功能降級以保證核心功能可以訪問的機制，並且制定一鍵生效預案，可快速完成服務降級（要求分鐘級別）；
.快速擴容：服務架構有能力和資源可以在短時間內（要求至少30分鐘內）完成快速的擴容操作，並且穩定可靠
.網校預案現狀
網校狡兔計劃共分4個層面，總計整理並完成40餘個具體預案
b.容災加固
.多實例建立：避免服務單點情況，改造成多實例（或主備）架構，避免單點故障的風險；多機房建立：建立至少2個機房的實例組，避免單機房故障的風險
四、變更管控
1.管控策略：
.早7點-晚10點禁止線上操作
.如需在晚10:00 - 早7:00之間進行線上操作
.至少提前6小時在“【專項】寒假穩定性保障”羣裏報備，報備內容包括：操作事項、操作時間、影響範圍
.操作前請先確認直播在線人數（通過貓頭鷹平臺首頁查看 https://cloud.tal.com/tal-beacon#/1/big-class），確保在線人數低於500人才能進行操作
.如需在早7點-晚10點之間緊急進行線上操作，需要部門N2郵件確認並抄送保障總負責小組成員確認
2.管控期限：
7.01 - 8.25
重保中
一、人員值守
1.響應時間
· 值班人員必須實時關注核心報警以及問題反饋羣
· 非值班人員30分鐘內必須相應
週期：7.01 - 8.25
時段：早8：00~晚9：30
重點時段：早晨8：00~12:00 和晚上5：30~9：30
2.值守內容
a. 出現異常時，暑假主值班人員推動拉專項羣，拉相關人員：相關RD及leader ，相關QA及leader，相關PM及leader，客訴老師，危機老師等
b.值班同學需要每天發送日報，同步當天出現的相關線上問題等
3.值班準則
a.每日關注核心報警羣中的報警信息，如有問題，及時和Rd一起確認問題
b.每日關注核心核心監控大盤，確認是否有異常
c.每日關注當天的課程場次，暑假保障羣中同步“高危”場次以及時間節點
d.每日確認下所有值班同學是否就位
e.如有需要，暑假主值班可以臨時調整其他值班人員需要關注的羣
二、異常處理
出現疑似故障時：
1. 問題跟進
a. 問題解決原則，先止損，再定位具體原因
故障止損，故障止損負責人負責故障的止損工作，以最快&最穩妥的方式進行恢復嘗試和處理；當長時間無法止損時，需要第一時間反饋故障總負責人尋求幫助和方案；當故障止損時，第一時間反饋故障總負責人；
b. 主動和問題反饋人、RD、PM溝通，分析定位問題
c. 嘗試使用各個平臺以及日誌定位問題
d. 基於以上結論嘗試進行問題復現
e. 引導相關人員在相關專項羣溝通解決
2.故障通告
故障總負責人負責定期對外進行通告（通告範圍需要準確），接受所有外界對於故障的詢問；幾個關鍵時間節點必須要同步更新（故障處理進度、止損完成、恢復完成）；如果長時間到達不了下個時間節點，則需要至少1小時同步更新狀態；
3.問題解決原則
a. 嚴重線上問題，必須當天完成，如無法當天修復，需要與相關RD，QA 達成一致
b. 問題解決後，羣裏通知相關干係人以及故障總負責人，並同步問題解決結果；問題解決方案集中放到wiki存檔記錄
4.根因追查
根因追查負責人負責故障的根因追查，確定徹底恢復的方案，第一時間反饋故障總負責人，由故障總負責人確認方案可行性並且安排人員進行方案執行；如果追查過程中需要任何資源，則第一時間反饋故障總負責人尋求幫助
重保後
一、問題記錄、覆盤總結
在日常運維過程中，出現故障等事故對於我們而言其實是一個很好的覆盤學習機會。通過歷史監控數據，分析事故其中的根本原因，制定後續應對策略，並且通過運維平臺將這些應對策略編輯成標準化、可重用、自動化的運維應用場景，爲後續相同問題的處理提供標準且快捷的解決方案。這正是事後回顧這個過程最真實的價值體現
覆盤總結就是對於過去的一些服務異常和服務中斷情況進行回顧和總結，以確保相同問題下次不會再出現。爲了讓大家團結協作，我們希望建立一種無指責、透明的事後文化。個人不應該害怕事故，而是確信如果事故發生，團隊將會響應和改進系統
1.覆盤的具體步驟
a.目標回顧、結果呈現
b.複述過程、剖析原因
c.發散思路、總結經驗
2.覆盤時注意的幾點
a.不計較個人得失，提升團隊作戰能力能力爲前提
b.敢於反思爲什麼，深入問題根部思考，開拓思路
c.公佈現有的結果，總結共享所獲經驗，提升下一次活動質量
3.覆盤落實
跟進歷史case study的優化措施，按時落地，驗收效果
二、經驗積累
從以往真實的case和歷史水位等信息中分析重要數據，提煉出新的重保模式和特點，總結和沉澱一套重大活動保障方案。目的是：避免後續保障中有明顯的缺失和遺漏，保障後續活動不出大的問題，同時按照方案指導，降低業務一些過度防護和重複工作
1.SRE日常組件水位巡檢記錄存檔
2.網關歷史沉澱
3.消息歷史沉澱
爲熱愛全力以赴，未來可期～
關於好未來技術更多內容請：微信掃碼關注「好未來技術」微信公衆號
