實時數倉混沌演練實踐
一、背景介紹
目前實時數倉提供的投放實時指標優先級別越來越重要，不再是單獨的報表展示等功能，特別是提供給下游規則引擎的相關數據，直接對投放運營的廣告投放產生直接影響，數據延遲或者異常均可能產生直接或者間接的資產損失。
圖片
從投放管理平臺的鏈路全景圖來看，實時數倉是不可或缺的一環,可以快速處理海量數據，并迅速分析出有效信息，同時支持投放管理平臺的手動控盤。實時節點事故，將可能導致整個投放鏈路無法正常運行，另外，投放規則引擎是自動化操作，服務需要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、完善演練庫，后續計劃通過引入工具（平臺）、建立演練協助機制、定期定時演練等手段，使混沌演練更加自動化、規范化、常態化，提高實時數倉整體數據穩定。
