一、背景介紹
目前實時數倉提供的投放實時指標優先順序別越來越重要，不再是單獨的報表展示等功能，特別是提供給下游規則引擎的相關資料，直接對投放運營的廣告投放產生直接影響，資料延遲或者異常均可能產生直接或者間接的資產損失。
從投放管理平臺的鏈路全景圖來看，實時數倉是不可或缺的一環,可以快速處理海量資料，並迅速分析出有效資訊，同時支援投放管理平臺的手動控盤。實時節點事故，將可能導致整個投放鏈路無法正常執行，另外，投放規則引擎是自動化操作，服務需要24小時執行，所以需要配置及時有效的資料質量監控預警，能快速識別到波動異常或者不符合業務的資料，從而計劃引入混沌工程，希望可以透過主動注入故障的方式、儘可能提前感知風險、發現潛在問題，並針對性地進行防範、加固，避免故障發生時所帶來的嚴重後果，提高實時數倉整體抗風險能力。
二、演練範圍
為了能更細緻反應出混沌演練情況，根據演練的內容不同，將實時數倉混沌分為兩部分：技術側和業務側。
技術側混沌：基於中介軟體、資料庫、JVM、基礎資源、網路、服務等注入常見的異常，根據實際業務中梳理的應用核心場景進行混沌演練，檢驗系統的脆弱性和應急響應能力，從而提升團隊的穩定性保障處理能力。
業務側混沌：對於電商活動密集型的公司來說，各種到達率、曝光率，以及更加宏觀的 GMV、使用者拉新數、使用者召喚數等，都能表現出業務的健康程度，在實際生活中，為了描述一種穩定狀態，我們需要一組指標構成一種模型，而不是單一指標。無論是否採用混沌工程，識別出這類指標的健康狀態都是至關重要的，所以要圍繞它們建立一整套完善的資料採集、監控、預警機制，當業務指標發生波動較大時，我們能搞快速感知、定位、修復止血。
過往數倉混沌工程均是技術側，此次在投放鏈路已搭建完成主備鏈路的前提下，期望通可以透過多輪業務側混沌，提高系統整體的資料異動感知能力。
三、演練計劃
工欲善其事，必先利其器，在執行混沌演練前，需要準備好前置工作，制定合理的演練SOP、方案、計劃，對演練環境、指令碼、資料、工具，場景及爆炸半徑等進行可能性評估，在確認可行性ok的情況下，約好關聯方時間，再進行實踐操作。
本篇主要和大家分享基於業務側的實時數倉混沌演練過程：
1.編寫演練SOP
SOP是一種標準的作業程式，就是將某一事件的操作步驟和要求，進行細化、量化及最佳化，形成一種標準的操作過程，關於業務側混沌，尤其是實時數倉資料相關的演練，我們也是第一次做，目前在業界也沒有找到相關的演練指導參考，處於探索階段，為了方便專案進度的順利進行及後續演練操作更加規範、高效，在演練前期大家經過溝通、討論後，專案前期梳理的SOP演練模板，如下：
2.演練方案調研
先收集實時數倉投放鏈路核心指標範圍，在此基礎上，拉取一段時間內的歷史資料進行分析，找到每個指標對應的健康波動閥值，從而在配置相應的DQC規則監控，對於波動不在健康閥值的異常指標，在分鐘級別（預期15min）內及時告警，並快速排查響應。為此，在演練前期，我們經歷過一系列的方案調研、探索，如下：
「下文提供的方案，指標資料都是以裝置啟用數為例進行分析」
- 方案一: 按照天維度，收集最近一段時間，同一天每個整點裝置啟用數，佔當天大盤佔比，統計出最小值、最大值，作為該指標的健康波動閥值;
- 方案二: 按照天維度，收集一段時間內，同一天相鄰整點指標波動資料找規律，比如每天上午9點到10點的波動資料，然後分別透過一系列的數學分佈方法進行資料統計，從而希望找一個相對穩定的波動區間；
- 方案三: 按照天維度，收集一段時間內，相鄰天整點指標波動資料找規律，比如昨天上午9點到前天上午9點的波動資料，然後分別透過一系列的數學分佈方法進行資料統計，從而希望找一個相對穩定的波動區間；
- 方案四:在前面三種方案的基礎上，指標在工作日和週末的波動可能不一樣，所以我們在日維度統計的基礎上，我們也調研了周維度同比波動分佈情況，比如每週一上午9點到上午10點的波動資料，然後分別透過一系列的數學分佈方法進行資料統計，從而希望找一個相對穩定的波動區間；
- 方案五:同理，我們也調研了周維度環比波動分佈情況，比如本週一上午9點到上週一上午9點的波動資料，然後分別透過一系列的數學分佈方法進行資料統計，從而希望找一個相對穩定的波動區間；
- 方案六：基於主備鏈路，在source源相同的情況下，經過實時數倉計算出的指標，在同一段時間兩條鏈路sink出來的結果資料，正常應該是保持一致，或者波動較小，比如10分鐘延遲的主備鏈路，波動不超過10%，平均差異做到一致性做到90%以上。
方案1到5，都嘗試過一遍，每個方案場景資料透過最大值、最小值、平均值、各百分位分佈、方差、標準差等統計出來的資料分析，很難找到一個相當穩定的波動規律，也無法框定指標具體的閥值區間，實際演練過程，如果設定的波動告警閥值過大，真實生產上業務資料波動異常時，無法及時告警發現；設定過小，將導致告警頻繁，對其準確性、有效性可能存在質疑，而且，實時投放的核心指標有幾十個，每個指標對應的健康閥值都不一樣，要收集、分析成本非常高，從演練的效果上看，也不是很明顯。
整體評估下來，演練主要採用的是方案六：涉及到的實時投放核心指標數共收集29個，一段時間內（15min），主備鏈路指標波動差異不超過10%。
3.演練方式
紅藍對抗演練，將團隊分為紅（防）藍（攻）兩組。
測試人員組成藍軍：負責制定混沌演練方案，執行目標系統故障注入，詳細記錄演練過程；
實時數倉開發為紅軍：負責發現故障、應急響應、排除故障，同時驗證系統在不同故障場景下的容錯能力、監控能力、人員響應能力、恢復能力等可靠效能力。
四、演練流程
整體演練過程，大致分為三個階段：準備階段、攻防階段及覆盤階段。
1.準備階段
- 方案准備完評審透過後，確認好鏈路計劃；
- 藍軍按計劃根據事先制定的攻擊方案，提前準備好相應的測試資料、指令碼；
- 紅軍按計劃根據事先制定的攻擊方案，在演練前，提前確保環境可用，並進行監控防禦、應急響應措施。
2.攻防階段
- 藍隊根據事先制定的攻擊方案，模擬真實的攻擊行為，按照約定的時間在演練鏈路（備用鏈路）進行攻擊，進行故障注入，同時記錄好相應的操作步驟，方便後續報告梳理；
- 紅隊在藍軍攻擊後，透過飛書/郵件告警等通知方式實時關注監控系統執行情況，如有異常告警，需第一時間進行問題排查定位，在評估修復方案；
- 在攻防對抗的過程中，藍軍可根據紅軍的防禦措施進行調整和改進攻擊策略，盡力突破系統的防禦並達到既定目標，同時紅軍也可分析藍軍的攻擊手法和行為模型，不斷改進防禦措施來加強防禦。
3.覆盤和改進階段
- 在混沌演練結束後，進行總結和評估，分析紅隊和藍隊的表現，評估系統的安全性和抗攻擊能力；
- 總結經驗教訓，總結成功的防禦措施和失敗的攻擊手法，以便於改進系統的安全策略；
- 根據評估結果和總結經驗，制定改進計劃，修補系統中的漏洞和薄弱點，提升系統的抗風險能力。
五、攻防實戰
本次演練共計有29個指標波動case，整體演練操作大同小異。
以其中case17 “召回商品收藏uv在某個渠道下整點波動異常”為例，具體的演練操作流程如下。
1.資料準備
- 透過後臺資料庫，拉出生產主(備)鏈路，某個渠道（如
media_id= '2'）下某個整點（如hour= 10）下，召回商品收藏uv對應的整體統計值N。
--渠道小時整點維度下，商品收藏uv彙總資料
select
`指標名稱`,
`日期`,
'2' as `指標ID`,
`小時段`,
sum(`指標值`)
from table_a
where
date = date_format(now(), '%Y%m%d')
and `指標名稱` in ( '商品收藏uv' )
and `小時段` = 10
AND `指標id` = '2'
GROUP BY
`指標名稱`,
`日期`,
`小時段`
order by
指標名稱;
- 拉出備用鏈路，某個渠道（如
media_id= '2'）下某個整點（如hour= 10）下，具體的一條明細資料，記錄商品收藏uv對應的值為n,把n改為n+0.1N,後續注入進備用鏈路，從而使得主備波動差異在10%。
-- 明細資料
select
t.指標名稱,t.賬戶id,t.計劃ID,t.裝置型別,t.指標值
from
(
select
`賬戶id`,
`計劃id`,
`指標名稱`,
`指標值`,
`裝置型別` ,
row_number() over (partition by 指標名稱 order by 指標值 desc ) as rn
from table_a
where
date = date_format(now(), '%Y%m%d')
and `指標名稱` in ('商品收藏uv')
and `裝置型別` = '召回'
and `小時段` = 10
AND `指標id` = '2'
) t
where
t.rn = 1
ORDER BY 指標名稱;- 整理後得到需要注入的資料資料，見標黃部分。
2.故障注入odps
- 將需要注入的資料匯入odps。
匯入前，需要在datawork空間中新建測試表du\_qa\_dw\_dev.hundun\_case，用於匯入演練資料
-- drop table if EXISTS du_qa_dw_dev.hundun_case;
CREATE TABLE IF NOT EXISTS hundun_case
(
message STRING COMMENT '訊息內容'
)
COMMENT '混沌演練'
;
- 往du\_qa\_dw\_dev.hundun\_case表裡灌數。
- 驗證資料匯入是否成功。
3.odps同步到kafka
執行flink同步指令碼，將odsp du\_qa\_dw\_dev.hundun\_case表表資料同步到對應的kafka topic中。
flink任務指令碼：
--SQL
--********************************************************************--
--odps同步到kakfa指令碼，用於實時數倉混沌演練異常注入使用
--********************************************************************--
-- 基本函式
CREATE FUNCTION JsonParseField AS 'com.alibaba.blink.udx.log.JsonParseField';
CREATE FUNCTION jsonStringUdf AS 'com.alibaba.blink.udx.udf.JsonStringUdfV2';
---同步賬號表
CREATE TABLE `source` (
message VARCHAR
) WITH (
'connector' = 'du-odps',
'endPoint' = '***',
'project' = '***',
'tableName' = 'hundun_case_01',
'accessId' = '*******',
'accessKey' = '*******'
);
CREATE TABLE `kafka_sink` (
`messageKey` VARBINARY,
`message` VARBINARY,
PRIMARY KEY (`messageKey`) NOT ENFORCED
) WITH (
'connector' = 'du-kafka',
'topic' = '********',
'properties.bootstrap.servers' = '*******',
'properties.compression.type' = 'gzip',
'properties.batch.size' = '40960',
'properties.linger.ms' = '1000',
'key.format' = 'raw',
'value.format' = 'raw',
'value.fields-include' = 'EXCEPT_KEY'
);
INSERT INTO kafka_sink
SELECT
cast(MD5(message) as VARBINARY),
cast(message as VARBINARY)
FROM source
;
4.kafka平臺查詢資料
執行完flink同步任務後，可透過後臺查詢，對應的資料是否同步成功。
5.異常注入通知
在異常注入完成後，可以透過飛書群通知，告知紅軍，如收到告警，需第一時間群告知。
藍軍：藍軍已完成資料準備，請紅軍在演練前確保環境OK且已完成規則配置，另外務必將演練時間計劃及時同步通知到下游關聯方；
藍軍：已完成注入。
6.告警觸發通知
- 紅軍在演練前，可透過監控平臺提前配置好防禦規則。
- 在異常注入後，如符合預期，在15min內發現指標波動異常，紅軍需及時同步到演練群中。
中危**雙鏈路主備一致監控
服務名：**** 環境：****** 告警時間：****** 觸發條件：**雙鏈路比對波動異常，持續10分鐘 告警詳情：指標:prd\_collect\_uv主對比備下降:[-10%] 主:1066 備:956
業務域：實時數倉
應用負責人：***
- 如不符合預期，未在15min內發現指標波動異常，紅軍需及時定位、跟進問題，並在修復後，溝通後續演練驗證修復結果。
紅軍：15min內未收到告警，定位中
紅軍：原因已找到，由於***造成，導致告警資料沒有及時發出，正在修復處理
紅軍：已修復，請紅軍重新發起攻擊
7.演練過程記錄
收集、彙總記錄演練過程中的每個操作，含時間點、執行人、操作等，如下：
六、演練總結
七、未來展望
實時數倉業務側的混沌演練，從0到1，在經過一系列的探索實踐後，透過主備鏈路比對方式，演練期間對於異常波動的指標，可以快速識別感知，從演練結果上，取得了不錯的成效，但也存在一定的侷限性，如：
- 演練期間，透過人工注入的異常資料，如無法快速清除，可能影響到備用鏈路使用。
- 對於沒有備鏈路的實時指標波動，需要制定更精細化的可行方案，找尋指標健康波動範圍。
這些都需要團隊進一步去探索、解決，同時在演練的過程中，我們將不斷積累、豐富演練case、完善演練庫，後續計劃透過引入工具（平臺）、建立演練協助機制、定期定時演練等手段，使混沌演練更加自動化、規範化、常態化，提高實時數倉整體資料穩定。
*文 / 袁宵
本文屬得物技術原創，更多精彩文章請看：得物技術官網
未經得物技術許可嚴禁轉載，否則依法追究法律責任！