b. 智慧型運維 --- 質量保障 --- 混沌工程
概述 目的：混沌工程是在分布式系統上進行實驗的學科, 目的是建立對系統抵禦生產環境中失控條件的能力以及信心。我們需要在異常行為出現之前，在整個系統內找出這些弱點。這些弱點包括以下形式:
當服務不可用時的不正確回滾設定;
不當的超時設定導致的重試風暴;
由於下游依賴的流量過載導致的服務中斷;
單點故障時的級聯失敗等。
意義：混沌工程的意義在於，能讓複雜系統中根深蒂固的混亂和不穩定性浮出表面，讓我們可以更全面地理解這些系統性固有現象，從而在分布式系統中實現更好的工程設計，不斷提高系統彈性。
與測試的區別混沌工程和這些其他測試方法的主要區別在於，混沌工程是發現新資訊的實踐過程，而故障注入則是對乙個特定的條件、變數的驗證方法。
常見方法
模擬整個雲服務區域或整個資料中心故障；
跨多例項刪除部分 kafka topic 來重現生產環境中發生過的問題；
挑選乙個時間段，和針對一部分流量，對其涉及的服務間呼叫注入一些特定的延時；
方法級別的混亂（執行時注入）：讓方法隨機丟擲各種異常；
在**中插入一些指令可以允許在這些指令之前執行故障注入；
強制系統節點間的時間不同步；
在驅動程式中執行模擬 i/o 錯誤的程式；
讓某個 elasticsearch 集群 cpu 超負荷。
前提條件
如果你很確定混沌工程實驗會導致系統出現嚴重的故障，那執行這樣的實驗是沒有任何意義的。你需要先解決這個問題，然後再回到混沌工程，然後你不僅能繼續發現更多不知道的脆弱點，還能提高對系統真實彈性水平的信心。
混沌工程的另乙個前提條件是監控系統，你需要用它來判斷系統當前的各項狀態。
原則 基本原則
首先，用系統在正常行為下的一些可測量的輸出來定義「穩定狀態」。
其次，假設這個在控制組和實驗組都會繼續保持穩定狀態。
然後，在實驗組中引入反映真實世界事件的變數，如伺服器崩潰、硬碟故障、網路連線斷開等。
最後，通過控制組和實驗組之間的狀態差異來反駁穩定狀態的假說。
高階原則
建立乙個圍繞穩定狀態行為的假說
目標：通過乙個模型，基於所期望的業務指標，來描述系統的穩定狀態。
建設假設：即便你已經建立了穩定狀態行為模型，你也需要定義清楚，當偏離穩定狀態行為發生時你要如何測量這個偏差。
多樣化真實世界的事件
原則我們不應該給系統注入引發故障的根因事件。
我們不需要窮舉所有可能對系統造成改變的事件，只需要注入那些頻繁發生且影響重大的事件，同時要足夠理解會被影響的故障域。
在生產環境中執行實驗
理念經典測試的乙個普遍信條是，尋找軟體缺陷要離生產環境越遠越好。
但是在混沌工程領域裡，整個策略卻要反過來了。在離生產環境的越近的地方進行實驗越好。理想的實踐就是直接在生產環境中執行實驗。
問題狀態和服務：總有一些意想不到的狀態會傷害到你。
生產環境中的輸入：真正對系統的建立信心的唯一方法就是在生產環境中針對真實的輸入資料驗證實驗。
第三方系統：服務依賴大量的第三方系統
生產環境變更
外部有效性
不願意實踐混沌工程的藉口：我們認識到，在有些環境中，直接在生產環境中進行實驗可能非常困難甚至不可能。我們並不期待工程師將干擾注入到行駛中的自動駕駛汽車的感測器裡。但是，多數使用者應該都不是在操作這類安全悠關的系統。
我很確定它會宕機！：混沌工程的乙個主要目的是識別系統中的薄弱環節。如果已經看到明顯的薄弱環節，那你應該首先專注於提高系統在這一點上的彈性。當你確信系統有足夠的彈性時，就可以開始進行混沌工程實驗了。
如果真的宕機了，麻煩就大了！我們採用的方法是通過下面兩個途徑來最小化潛在的影響範圍：
支援快速終止實驗；
最小化實驗造成的「**半徑」。
離生產環境越近越好：即便你不能在生產環境中執行實驗，你也要盡可能的在離生產環境最接近的環境中執行。越接近生產環境，對實驗外部有效性的威脅就越少，對實驗結果的信心就越足。
持續自動化執行實驗
自動執行實驗：1. 先手動實驗，確立對系統的信心 2. 再自動實驗混沌工程自動化平台 chaos automation platform（chap）
自動建立實驗：如果你已經可以配置定期自動執行實驗，你就處在乙個非常好的狀態了。然而，我們認為還可以追求乙個更好的自動化水平：自動設計實驗。lineage-driven fault injection (ldfi)
最小化**半徑我們經常執行本來只會影響一小部分使用者的測試，卻由於級聯故障無意中影響到了更多的使用者。在這些情況下，我們不得不立即中斷實驗。雖然我們絕不想發生這種情況，但隨時遏制和停止實驗的能力是必備的，可以避免造成更大的危機。
最小風險的實驗只作用於很少的使用者之上。
當自動化實驗成功之後（或者小量裝置驗證沒有涵蓋要測試的功能時），下一步就是執行小規模的擴散實驗。
下一步是進行小規模的集中實驗，通過修改路由策略讓所有實驗覆蓋的使用者流量導向到特定的節點。
風險最大但最準確的實驗是大規模無自定義路由的實驗。
除了不斷擴大實驗範圍，在實驗造成過多危害時及時終止實驗也是必不可少的。
實驗 實驗步驟
選定假設；
設定實驗的範圍；
識別出要監控的指標；
在組織內溝通到位；
執行實驗；
分析實驗結果；
擴大實驗範圍；
自動化實驗。
混沌工程成熟度模型
熟練度入門
未在生產環境中執行實驗；
全人工流程；
實驗結果只反映系統指標，而不是業務指標；
只對實驗物件注入一些簡單事件，如「關閉節點」。
簡單用複製的生產流量來執行實驗；
自助式建立實驗，自動執行實驗，但需要手動監控和停止實驗；
實驗結果反映聚合的業務指標；
對實驗物件注入較高階的事件，如網路延遲；
實驗結果是手動整理的；
實驗是預先定義好的；
有工具支援歷史實驗組和控制組之間的比較。
高階在生產環境中執行實驗；
自動結果分析，自動終止實驗；
實驗框架和持續發布工具整合；
在實驗組和控制組之間比較業務指標差異；
對實驗組引入如服務級別的影響和組合式的故障事件；
持續收集實驗結果；
有工具支援互動式的比對實驗組和控制組。
熟練開發流程中的每個環節和任意環境都可以執行實驗；
全自動的設計、執行和終止實驗；
實驗框架和 a/b 測試以及其他測試工具整合以最小化影響；
可以注入如對系統的不同使用模式、返回結果和狀態的更改等型別的事件；
實驗具有動態可調整的範圍以找尋系統拐點；
實驗結果可以用來**收入損失；
實驗結果分析可以用來做容量規劃；
實驗結果可以區分出不同服務實際的關鍵程度。
應用度暗中進行
重要專案不採用；
只覆蓋了少量系統；
組織內部基本沒有感知；
早期使用者偶爾進行混沌工程實驗。
適當投入度
實驗獲得正式批准；
工程師兼職進行混沌工程實驗；
多個團隊有興趣並參與；
少數重要服務也會不定期進行混沌工程實驗。
正式採用
有專門的混沌工程團隊；
所有故障的覆盤都會進入混沌工程框架來建立回歸實驗；
大多數關鍵服務都會定期進行混沌工程實驗；
偶爾執行實驗性的故障覆盤驗證，例如「比賽日」的形式。
成為文化
所有關鍵服務都高頻率進行混沌實驗；
多數非關鍵服務高頻率進行混沌實驗；
混沌工程實驗是工程師日常工作的一部分；
所有系統元件預設要參與混沌工程實驗，不參與需要特殊說明。
故障分類
應用程式/資料
程序hang
程序被殺
啟動異常
心跳異常
環境錯誤
報錯誤或損壞
配置錯誤、誤刪、獲取超時
系統單點
非同步阻塞同步
依賴超時
依賴異常
業務執行緒池滿
流控不合理
監控錯誤
oom執行時/中介軟體/作業系統
負載均衡失效
快取熱點
快取限流
資料庫熱點
資料庫宕機
資料庫同步延遲
資料庫主備延遲
資料庫連線滿
資料庫熱點
cpu搶占
記憶體搶占
記憶體錯亂
上下文切換
虛擬機器/儲存硬體/網路
伺服器宕機&假死
斷電超賣
混部磁碟滿、慢、壞
不可寫不可讀
網路抖動、丟包、超時
網絡卡滿dns故障
斷網
資料庫運維保障
國慶假期本來是可以開開心心去玩的，但是由於某些突發情況，例如天災導致的資料庫故障的情況還是有可能出現 如果出現這種情況不但破壞了國慶假期玩樂的美好心情，節後上班也可能由於沒有做好預防措施要遭遇領導挨批。為了避免發生這種情況，對於公司業務系統的相關運維人員來說不能掉以輕心，一定要做好預防措施。以下是總...
ccf 智慧型運維 裴丹 基於機器學習的智慧型運維
聽了裴丹教授關於 基於機器學習的智慧型運維 演講之後的寫下的乙個筆記。今天來看，還是有不少啟發，分享給大家，對細節有興趣的童鞋可以去看演講實錄。在本文末尾附了相關鏈結。基於機器學習的智慧型運維 講師 裴丹 概述值得工業界運維工程師關注的頂級學術會議 智慧型運維歷程 基於專家庫規則 機器學習 深度學習...
如何構建智慧型運維平台？
隨著技術的發展，運維支撐必須逐漸擺脫對人力的單純依賴，走向平台化。如何才能構建具有一定智慧型的運維平台？軟體即服務 software as a service 需要以軟體服務為基礎，實現運維的it能力和業務能力的對接。生活中，幾乎我們每一天都在接觸saas雲服務，比如 我們平時使用的蘋果手機雲服務，...