《美團：2022年美團技術年貨——數據、安全、運維系列（160頁）.pdf》由會員分享，可在線閱讀，更多相關《美團：2022年美團技術年貨——數據、安全、運維系列（160頁）.pdf（160頁珍藏版）》請在三個皮匠報告上搜索。

1、數據1Kafka 在美團數據平臺的實踐1美團綜合業務推薦系統的質量模型及實踐26業務數據治理體系化思考與實踐41數據治理一體化實踐之體系化建模71運維/安全85數字化新業態下數據安全創新Token 化85Linux 中基于 eBPF 的惡意利用與檢測機制101如何應對開源組件風險？軟件成分安全分析（SCA）能力的建設與演進136目錄Kafka 在美團數據平臺的實踐作者：海源仕祿肖恩鴻洛啟帆胡榮李杰1.現狀和挑戰1.1現狀Kafka 是一個開源的流處理平臺，業界有很多互聯網企業也都在使用這款產品。我們首先了解一下 Kafka 在美團數據平臺的現狀。圖 1-1Kafka 在美團數據平臺的現狀數據2

2、2022年美團技術年貨如圖 1-1 所示，藍色部分描述了 Kafka 在數據平臺定位為流存儲層。主要的職責是做數據的緩存和分發，它會將收集到的日志分發到不同的數據系統里，這些日志來源于系統日志、客戶端日志以及業務數據庫。下游的數據消費系統包括通過 ODS 入倉提供離線計算使用、直接供實時計算使用、通過 DataLink 同步到日志中心，以及做OLAP 分析使用。Kafka 在美團的集群規?？傮w機器數已經超過了 15000+臺，單集群的最大機器數也已經到了 2000+臺。在數據規模上，天級消息量已經超過了 30+P，天級消息量峰值也達到了 4+億/秒。不過隨著集群規模的增大，數據量的增長，Kaf

3、ka 面臨的挑戰也愈發嚴峻，下面講一下具體的挑戰都有哪些。1.2挑戰圖 1-2Kafka 在美團數據平臺面臨的挑戰如圖 1-2 所示，具體的挑戰可以概括為兩部分：第一部分是慢節點影響讀寫，這里慢節點參考了 HDFS 的一個概念，具體定義指的是讀寫延遲 TP99 大于 300ms 的 Broker。造成慢節點的原因有三個：1.集群負載不均衡會導致局部熱點，就是整個集群的磁盤空間很充?；蛘?ioutil很低，但部分磁盤即將寫滿或者 ioutil 打滿。2.PageCache 容量，比如說，80GB 的 PageCache 在 170MB/s 的寫入量下僅能緩存 8 分鐘的數據量。那么如果消費的數據

4、是 8 分鐘前的數據，就有可能觸發慢速的磁盤訪問。數據2022年美團技術年貨圖 2-1 是針對讀寫延遲碰到的問題以及對應優化方案的概覽圖。我們把受影響的因素分為應用層和系統層。應用層主要包括 3 類問題：1）Broker 端負載不均衡，例如磁盤使用率不均衡、ioutil 不均衡等問題。個別磁盤負載升高影響整個 Broker 的請求受到影響。2）Broker 的數據遷移存在效率問題和資源競爭問題。具體來講，包括以下 3 個層面：遷移只能按批次串行提交，每個批次可能存在少量分區遷移緩慢，無法提交下個批次，導致遷移效率受影響。遷移一般在夜間執行，如果遷移拖到了午高峰還未完成，可能會顯著影響讀寫請求。

5、遷移請求和實時拉取存在共用 Fetcher 線程的問題導致分區遷移請求可能會影響實時消費請求。3）Consumer 端單線程模型存在缺陷導致運維指標失真，并且單 Consumer 消費的分區數不受限制，消費能力不足就無法跟上實時最新的數據，當消費的分區數增多時可能會引起回溯讀。系統層也主要包括 3 類問題：1）PageCache 污染。Kafka 利用內核層提供的 ZeroCopy 技術提升性能，但是內核層無法區分實時讀寫請求和回溯讀請求，導致磁盤讀可能污染 PageCache，影響實時讀寫。2）HDD 在隨機讀寫負載下性能差。HDD 對于順序讀寫友好，但是面對混合負載場景下的隨機讀寫，性能顯

6、著下降。3）CPU 和內存等系統資源在混部場景下的資源競爭問題。在美團大數據平臺，為了提高資源的利用率，IO 密集型的服務（比如 Kafka）會和 CPU 密集型的服務（比如數據2022年美團技術年貨實時讀寫延遲變高，比如說 TP99 請求處理時間超過 300ms 可能會導致實時作業發生消費延遲問題，數據收集擁堵問題等。集群整體利用率不足，雖然集群容量非常充裕，但是部分磁盤已經寫滿，這個時候甚至會導致某些分區停止服務。針對這兩個問題，我們采用了基于空閑磁盤優先的分區遷移計劃，整個計劃分為 3步，由組件 Rebalancer 統籌管理：1.生成遷移計劃。Rebalancer 通過目標磁盤使用率和

7、當前磁盤使用率（通過KafkaMonitor 上報）持續生成具體的分區遷移計劃。2.提交遷移計劃。Rebalancer 向 Zookeeper 的 Reassign 節點提交剛才生成的遷移計劃，Kafka 的 Controller 收到這個 Reassign 事件之后會向整個KafkaBroker 集群提交 Reassign 事件。3.檢查遷移計劃。KafkaBroker 負責具體執行數據遷移任務，Rebalancer 負責檢查任務進展。如圖 2-2 所示，每塊 Disk 持有 3 個分區是一個相對均衡的狀態，如果部分 Disk 持有 4 個分區，比如 Broker1-Disk1 和 Brok

8、er4-Disk4；部分 Disk 持有 2 個分區，比 如 Broker2-Disk2，Broker3-Disk3，Reblanacer 就 會 將 Broker1-Disk1 和Broker4-Disk4 上多余的分區分別遷移到 Broker2-Disk2 和 Broker3-Disk3，最終盡可能地保證整體磁盤利用率均衡。遷移優化雖然基于空閑磁盤優先的分區遷移實現了磁盤均衡，但是遷移本身仍然存在效率問題和資源競爭問題。接下來，我們會詳細描述我們采取的針對性策略。1.采取流水線加速策略優化遷移緩慢引起的遷移效率問題。2.支持遷移取消解決長尾分區遷移緩慢引起的讀寫請求受影響問題。3.采取 F

9、etcher 隔離緩解數據遷移請求和實時讀寫請求共用 Fetcher 線程的問題。數據2022年美團技術年貨優化二，遷移取消圖 2-4-1遷移問題如圖 2-4-1 所示，箭頭左側描述了因為遷移影響的三種線上類型。第一種是因為遷移會觸發最舊讀，同步大量的數據，在這個過程中會首先將數據回刷到 PageCache上引起 PageCache 污染，導致某個實時讀的分區發生 CacheMiss，觸發磁盤度進而影響讀寫請求；第二種是當存在某些異常節點導致遷移 Hang 住時，部分運維操作無法執行，比如流量上漲觸發的 Topic 自動擴分區。因為在 Kafka 遷移過程中這類運維操作被禁止執行。第三種和第二

10、種類似，它的主要問題是當目標節點 Crash，Topic 擴分區也無法完成，用戶可能一直忍受讀寫請求受影響。數據2022年美團技術年貨優化三，Fetcher 隔離圖 2-5Fetcher 隔離如圖 2-5，綠色代表實時讀，紅色代表延時讀。當某一個 Follower 的實時讀和延時讀共享同一個 Fetcher 時，延時讀會影響實時讀。因為每一次延時讀的數據量是顯著大于實時讀的，而且延時讀容易觸發磁盤讀，可能數據已經不在 PageCache 中了，顯著地拖慢了 Fetcher 的拉取效率。數據2022年美團技術年貨完畢后會將請求傳遞給 DelayedPurgatory 組件中，該組件是一個延時隊列

11、。當 觸 發 某 一 個 延 時 條 件 完 成 了 以 后 會 把 請 求 寫 到 ResponseQueue 中，在DelayedPurgatory 隊 列 持 續 的 時 間 為 RemoteTime，Processor 會 不 斷 的 從ResponseQueue 中將數據拉取出來發往客戶端，標紅的 ResponseTime 是可能會被客戶端影響的，因為如果客戶端接收能力不足，那么 ResponseTime 就會一直持續增加。從 Kafka-Broker 的視角，每一次請求總的耗時時 RequestTotalTime，包含了剛才所有流程分階段計時總和。圖 2-7Consumer 異步化

12、數據2022年美團技術年貨據并放到 CompleteQueue 中。2.3系統層Raid 卡加速圖 2-9Raid 卡加速HDD 存在隨機寫性能不足的問題，表現為延時升高，吞吐降低。針對這個問題我們引入了 Raid 卡加速。Raid 卡自帶緩存，與 PageCache 類似，在 Raid 這一層會把數據 Merge 成更大的 Block 寫入 Disk，更加充分利用順序寫 HDD 的帶寬，借助Raid 卡保證了隨機寫性能。Cgroup 隔離優化圖 2-10Cgroup 隔離數據2022年美團技術年貨ZeroCopy 就會觸發磁盤讀，磁盤讀不僅顯著變慢，還會污染 PageCache 影響其他讀寫

13、。如圖 2-11 中左半部分所示，當一個延遲消費者去拉取數據時，發現 PageCache中沒有它想要的數據，這個時候就會觸發磁盤讀。磁盤讀后會將數據回寫到 Page-Cache，導致 PageCache 污染，延遲消費者消費延遲變慢的同時也會導致另一個實時消費受影響。因為對于實時消費而言，它一直讀的是最新的數據，最新的數據按正常來說時不應該觸發磁盤讀的。選型和決策針對這個問題，我們這邊在做方案選型時提供了兩種方案：方案一，讀磁盤時不回寫 PageCache，比如使用 DirectIO，不過 Java 并不支持；方案二，在內存和 HDD 之間引入中間層，比如 SSD。眾所周知，SSD 和 HDD

14、 相比具備良好的隨機讀寫能力，非常適合我們的使用場景。針對 SSD 的方案我們也有兩種選型：決策優勢不足基于操作系統內核層實現1.數據路由對應用層透明，對應用代碼改動量小。2.開源軟件自身的健壯性由社區維護，可用性較好（前提：社區比較活躍）。1.FlashCache/OpenCAS 每種模式下都會將數據回刷到 SSD 緩存中，與 PageCache 相似，都會發生緩存污染。2.發生 CacheMiss 時會多一次對設備的訪問，延遲增加3.所有的 Meta 數據都由操作系統維護，內核消耗的內存會增加，在與其他引擎混布的場景下會導致其他服務可申請的內存減少。Kafka應用內部實現1.設計緩存策略時

15、充分考慮了Kafka 的讀寫特性，確保近實時的數據消費請求全部落在 SSD上，保證這部分請求處理的低延遲，同時從 HDD 讀取的數據不會回刷到 SSD 防止緩存污染。2.由于每個日志段都有唯一明確的狀態，因此每次請求的查詢路徑最短，不存在因 CacheMiss帶來的額外性能開銷。1.需要在 Server 端代碼上進行改進，涉及的開發及測試工作量較大。2.隨社區大版本升級，也需要迭代上這些改進的代碼。但可將相關代碼貢獻社區，解決迭代問題。數據2022年美團技術年貨具體實現下面來介紹一下 SSD 新緩存架構的具體實現。1.首先新的緩存架構會將 Log 內的多個 Segment 按時間維度存儲在不同

16、的存儲設備上，如圖 2-14 中的紅圈 1，新緩存架構數據會有三種典型狀態，一種叫 OnlyCache，指的是數據剛寫進 SSD，還未同步到 HDD 上；第 2 個是Cached，指數據既同步到了 HDD 也有一部分緩存在 SSD 上；第三種類型叫 WithoutCache，指的是同步到了 HDD 但是 SSD 中已經沒有緩存了。2.然后后臺異步線程持續地將 SSD 數據同步到 HDD 上。3.隨著 SSD 的持續寫入，當存儲空間達到閾值后，會按時間順序刪除距當前時間最久的數據，因為 SSD 的數據空間有限。4.副本可根據可用性要求靈活開啟是否寫入 SSD。5.從 HDD 讀取的數據是不會回刷

17、到 SSD 上的，防止緩存污染。圖 2-14SSD 新緩存架構細節優化數據2022年美團技術年貨圖 3-1 隔離優化第一點是業務隔離，如圖 3-1 所示，每一個大的業務會有一個獨立的 Kafka集群，比如外賣、到店、優選。第二點是分角色隔離，這里 Kafka 的 Broker 和 Controller 以及它們依賴的組件 Zookeeper 是部署在不同機器上的，避免之間相互影響。第三點是分優先級，有的業務 Topic 可用性等級特別高，那么我們就可以給它劃分到 VIP 集群，給它更多的資源冗余去保證其可用性。數據2022年美團技術年貨3-3 所示。圖 3-3全鏈路指標監控圖 3-4 是一個根

18、據全鏈路指標定位請求瓶頸的示例，可以看出服務端 RemoteTime占比最高，這說明耗時主要花費在數據復制。日志和指標的解析服務可以自動實時感知故障和慢節點，大部分的故障（內存、磁盤、Raid 卡以及網卡等）和慢節點都已經支持自動化處理，還有一類故障是計劃外的故障，比如分區多個副本掛掉導致的不可用，遷移 Hang 住以及非預期的錯誤日志等，需要人工介入處理。圖 3-4全鏈路監控指標示例數據2022年美團技術年貨3.4TOR 容災圖 3-6TOR 容災挑戰我們從工程實現的角度，歸納總結了當前主流圖神經網絡模型的基本范式，實現一套通用框架，以期涵蓋多種 GNN 模型。以下按照圖的類型（同質圖、異質

19、圖和動態圖）分別討論。圖 3-7TOR 容災TOR 容災保證同一個分區的不同副本不在同一個 Rack 下，如圖 3-7 所示，即使Rack1 整個發生故障，也能保證所有分區可用。數據2022年美團技術年貨美團綜合業務推薦系統的質量模型及實踐作者：勇皓根根王欣賀賀俐聰1.前言美團到店綜合業務（以下簡稱到綜）是美團到店業務的重要板塊之一，涵蓋洗浴、KTV、美業、醫美、親子、結婚、運動健身、玩樂、教育培訓、家居、寵物、酒吧、生活服務等數十個重點細分行業，滿足數以億計用戶多樣化的本地生活需求。推薦系統在其中是實現供給和需求高效匹配的重要環節，是傳遞數據價值的出口，而推薦系統的質量決定了匹配效果的折損。

20、如下圖1所示，數據經過數倉處理、算法加工，再通過數據服務到各個業務系統，最后通過客戶端埋點又重新流轉回數倉，形成了數據的“飛輪效應”，而質量恰恰是這條鏈路中齒輪嚙合的關鍵點，是提升效率和保障效果的重要前提。質量保障要圍繞著度量開展，才能“看得見”、“理得清”、“改得準”。但是傳統的后臺服務質量指標并不能很好地描述當前“數據飛輪”的質量。我們希望通過綜合業務推薦系統的質量模型建設，為類似多業務線、效果導向的系統質量度量提供一種新的思考角度和實踐參考。數據2022年美團技術年貨分析等環節。一是可用性并不涉及數據表的質量，二是在可用性能度量的地方無法反應數據質量的全貌。數據質量需要考慮完整性、準確性

21、、時效性、安全性等特征，超出了可用性的范疇。國際知名學者吳恩達曾說過，人工智能的價值80%取決于數據，推薦系統交付推薦效果（點擊轉化率、交易轉化率、用戶停留時長等）的質量，也主要取決于數據的質量?？捎眯噪y以反映業務差異性：美團到綜覆蓋上百個行業、幾十個頻道頁，推薦系統出于效率和成本考慮，業務間無法完全進行隔離，可用性的串并聯計算方式難以區分業務進行單獨評價。到綜不同業務差異很大，訪問頻次、流量高峰期、業務策略各不相同，從而質量的特點和問題分布也不同。目前可用性的指標缺乏業務維度信息，不利于指導精細化的質量運營。在質量建設中，過去以故障等級作為目標，驗證周期長，具備偶然性，且目標和動作邏輯推導關

22、系不強。另外，故障本身偏事后，這種問題驅動的思路不利于持續運營?？偟膩碚f，以可用性為目標，在實際落地計算時存在種種問題，所以我們考慮進行推薦系統的質量模型建設，以可用性為基礎，然后調整計算方式，進而指導精細化的質量運營。3.建設思路3.1業務語境下的質量建設質量模型，先回到對質量本質的理解。根據國際標準化組織（ISO）的定義，質量是反映實體滿足明確或隱含“需要”能力的特征總和。另一個常用的質量概念是穩定性，穩定性的核心是讓系統長時間地運行在“預期”狀態。無論是質量還是穩定性，都要搞清楚系統需要滿足誰的需要和預期。在推薦的場景下，這個對象是產品和算法。業務產品通過理解用戶場景，抽象用戶需求，向推

23、薦團隊提出產品需求，體現為對外的產品迭代；同時推薦系統團隊內部相互協作，學習最佳優化模型策略，體現為數據團隊內部的算法迭代。如下圖2所示，在可用性的計算公式中，強調了長時間，而“需要”和“預期”只體數據2022年美團技術年貨圖 3推薦系統的質量特征我們發現傳統可用性的度量，大多集中在可靠性、功能完整性、正確性方面，但是對于大部分的功能準確性、適當性以及安全性都缺乏度量，這些都與推薦的質量和效果緊密相關。準確性、適當性對效果的影響比較直觀，其他則較間接。比如安全性，以安全性中的爬蟲訪問為例，爬蟲由于訪問行為不符合真實人類的行為習慣，會影響UVCTR等核心指標的回收，從而造成效果誤判；同時如果不能

24、識別和剔除爬蟲數據，噪聲會進一步影響模型訓練的準確性。數據質量問題是數據“飛輪效應”中的“毒丸”，會產生正反饋不斷放大缺陷。我們將在第四章計算規則中，量化上述的缺陷，拓展可用性的外延。3.3度量和計算的選型可用性可以分為度量方式和計算方式：度量即我們常說的N個9，計算則用平均故障間隔時間和平均恢復時間的函數來衡量。在度量方式上，業界常用的質量度量方式如下圖4所示：數據2022年美團技術年貨4.計算方式根據上一章節的建設思路，從故障到缺陷，從推薦結果的“有”、“無”到推薦效果的“好”、“壞”，從整體到各個業務，我們描述了一個好的質量分應該有的特征。這一章節我們著重在指標的計算邏輯上，選取關鍵缺陷

25、，定義“成功的請求響應”，并增加質量分的業務聚合維度。4.1計算公式結合3.2章節中描述的質量特征，從成功請求占比的角度評估系統質量，在實際落地計算時可以分成以下四個層面的缺陷：系統層面：該請求觸發了系統異常，則為缺陷響應。常見的如召回超時、召回失敗、召回空結果等。數據層面：該請求用到的數據出現異常，則為缺陷響應。常見的如供給數量異常、標簽分布異常等，數據對用戶請求的實際影響，依賴數據血緣關系的建立和影響面評估。算法層面：該請求在召回和排序過程中，使用的特征、模型、策略異常，則為缺陷響應。常見的如模型更新延遲、特征缺失等，影響推薦的效果表達。業務層面：該請求觸發了業務適當性或安全合規要求，則結

26、果中包含以上結果的請求均為缺陷響應。常見的如運營反饋有供給質量、內容安全等嚴重的BadCase。一條請求，在生命周期的任意環節經歷了缺陷，則在結果上定義為缺陷響應，具體的缺陷環節是分析下鉆的維度。我們從3.2章節的質量特征和上述缺陷的四個層面選取典型問題（業務痛點、高頻質量問題）進行計算，以下圖6為例：數據2022年美團技術年貨陷率等。還可以再將一級指標進一步拆解，得到二級輸入指標，比如召回缺陷率比較高時，可以再去衡量召回空值率、召回超時率等。用戶的請求還可以根據業務進行垂直、橫向、時間維度聚合，得到有業務屬性的質量分，這樣會更有針對性，更加聚焦。圖 8質量指標體系這套改進后的質量分，以請求為

27、基本單位，相較于最初的可用性計算方式，在一定范圍內解決了它的局限性：對缺陷敏感，可以包括數據鏈路帶來的影響，方便進行多業務維度的聚合分析。4.4血緣拓展質量分以請求的粒度統計，在數據應用服務中，請求只是數據對外輸出的形式之一。在完成基礎的質量分后，請求的生命周期應該延展到數據全鏈路，這樣對質量的度量才完整。這時就依賴數據的血緣關系，將數據表-業務系統-C端流量關聯起來，構建全景的質量畫像，如下圖9所示：數據2022年美團技術年貨5.指標運營5.1系統實現質量分的系統實現方式依賴于埋點和診斷。推薦全鏈路包含參數輸入、召回前置處理、召回、召回后置處理、粗排、精排、重排等多個環節，每個環節都有可能出

28、故障，因此數據采集需要覆蓋運行時異常、各環節的關鍵輸入輸出信息等。如下圖10所示，我們通過Kafka異步收集埋點數據，然后分場景進行數據處理：生產環境下，近實時ES構建索引，提供近4天快速查詢服務，4天前的日志入Hive歸檔，另外通過Flink引擎解析埋點數據，經過必要的診斷后，實時計算分數并推送告警信息；測試環境下，日志實時分揀至MySQL，方便測試排查。最后，結構化展示推薦不同階段的質量情況，提高了結果的可讀性。圖 10質量分的系統實現分數體系的完善需要逐步推進，對于推薦系統，沒有推薦結果是最嚴重的質量問題。我們首先采集和計算的是推薦空結果，對應一級指標里的結果缺陷率、召回缺陷率和二級指標

29、里的結果空值率、召回空值率等。同時由于到綜的業務特性，行業眾多、供給時空分布不均，大量可交叉的篩選條件也會有空結果，影響質量分的計算。如何剔除符合業務預期的空結果，消除質量分噪聲，在實現埋點的基礎上，診斷就變得非常重要。以空結果為例，我們主要從參數診斷、數據診斷、鏈路診斷三個環節去識別。其中數據診斷指的是當線上篩選條件出現空結果時，回源二次校驗底層數據，數據37查詢底表數據是否為空。如果底表確實沒有相關供給，則沉淀免告警規則，設置免告警有效期，在一段時間內，當前城市當前行業確實缺少相關供給，該空結果不納入質量分計算。如果底表存在供給，則說明是數據加工或者服務過程中出現了異常，導致無法召回，則再

30、經過鏈路診斷確定出錯環節，納入相應質量分計算。如何建立規則匹配機制（即規則引擎）是診斷引擎的關鍵。當下的規則引擎選擇非常多，例如EasyRule、Drools、Zools、Aviator等。根據上文分析，診斷引擎需要能夠對請求參數、推薦鏈路以及底層數據進行規則診斷。對于請求參數、推薦鏈路的診斷均可通過內存參數進行診斷，而數據診斷則需要從第三方存儲中獲得信息，因此必然有一部分需要定制開發?？紤]人員工具使用成熟度以及便利性來說，Aviator表示式引擎較為合適。為契合需要診斷的內容，設計的表達式診斷原語如下：/參數診斷-原語表達/是否符合一定參數的診斷原語global:check=aviatorc

31、ityId!=nil&include(string.split(1,2,3,4,5,6,7,8,9,10,16,17,),str(cityId)/鏈路診斷-原語表達/1、召回異常診斷原語global:recallException=param$recall#exception#,global:check=aviatorrecallException!=nil&recallException!=/2、召回空無異常的診斷原語global:recallEmpty=param$recall#after#,global:check=aviatorrecallEmpty!=nil&recallEmpty!

32、=/3、召回不為空，過濾規則執行后為空的診斷原語global:recallEmptyCode=param$recall#after#,global:predictFiltersEmptyCode=param$predict#after#filters#,global:check=aviator(recallEmptyCode=nil|recallEmptyCode=)&predictFiltersEmptyCode!=nil/4、執行某一具體過濾規則后，導致無結果的匹配global:filterEmptyCode=param$PredictStage#filter#after#_compSkR

33、ef#,global:check=aviatorfilterEmptyCode!=nil&filterEmptyCode=deleteItemByConditionalFilter/數據診斷-原語表達（判斷底層是否有數據，若沒有則為true，否則為false）global:keys=keySpreadprefix 138_ymtags_crossOrder city_$cityId_platform_$platformNo_surgery_prj_$genericLvlIds,global:cnt=cellarcellarcount$keys,global:check=aviatorcnt!=

34、nil&cnt!=&long(cnt)2022年美團技術年貨5.2告警跟進質量分可以用于實時監控和運營復盤，需要團隊成員及時跟進異動。一般公司通用的告警系統，都是基于服務名稱粒度配置告警接收人。推薦系統這類平臺型的服務，通過統一的接口提供服務，但是模型策略卻是由不同的同學維護，業務間存在一定的行業知識和理解門檻。默認廣播式的告警，容易引起告警風暴，每個人無法專注于自己模塊的問題，有時也會遺漏告警。出于跟進率的考量（如下圖11所示），我們基于現有告警二次開發了跟進功能，將特定流量位的告警路由到專屬負責人，并記錄跟進狀態流轉，便于及時周知及事后復盤。在運營方面，我們通過數據報表搭建質量分看板，定期

35、回顧不同業務的質量波動情況。圖 11告警跟進流程5.3治理效果質量分的落地以結果空值率為抓手，按流程拆解采集召回空值率、模型預測空值率、重排算子空值率，并按業務聚合成平臺、業務、形態、項目、流量位多個維度。治理動作和成果分為以下幾個方面：數據2022年美團技術年貨6.未來規劃我們以可用性為基礎，調整計算方式，建立了多層次的推薦系統質量分，并拓展到各種推薦物料、各個業務模塊，核心是我們完成了從對外提供服務的“有無”到對外提供服務的“好壞”的認知迭代，這也是質量精細化運營的基礎。后續的規劃，一方面是繼續充實質量模型的計算和鏈路覆蓋；另一方面，我們會基于質量模型做更多的質量治理工作，后續將重點思考與

36、迭代的一些方向包括：通過完善埋點和診斷，逐步落地質量分體系中的各層指標，豐富質量分的內涵，容納更多的質量問題。通過建設多層次的推薦柔性降級，迭代對于質量分的理解，量化不同降級對于系統的影響。優化數據血緣的準確性、覆蓋率和時效性，更加正確快速評估某一個環節質量問題的影響面。7.本文作者勇皓、根根、王欣、賀賀、俐聰等，均來自美團到店平臺技術部/到綜業務數據團隊。數據2022年美團技術年貨另一方面，住宿數據組所屬的數據中心內部有住宿、門票度假等多條業務線，各業務線業務模式不同，所處業務生命周期階段不同，在數據治理上的認知及經驗積累也不同。如何能將數據治理經驗及能力高效復用，使數據中心各業務線在數據治

37、理的效率和效果上都能穩步提升，避免踩坑，這就需要數據治理更加標準化、體系化、自動化。此前，我們在數據治理上已經有了一些積累和沉淀，前一階段主要從單點、被動的治理轉變為主動、專項的治理，治理動作有意識、有規劃，也有一定的針對性，且取得了一定的成果（前一階段的治理經驗可參考美團酒旅數據治理實踐一文），但總的來說仍以問題驅動治理、憑經驗治理為主。面對新的數據治理責任及要求，過往的方式存在著一些問題，主要包括以下幾個方面。治理認知差異大認知不一致，思路不統一：治理缺乏通用的體系指引，不同的治理人對于數據治理的認知深度、問題拆解的方式、治理的思路步驟、采取的方法及其效果追蹤等方面，都存在較大的差異。重復

38、治理、信息不通：治理不徹底、治理經驗缺乏沉淀，同樣的治理，不同的人反復實行。范圍交叉、邊界不清、效果難評估：不同的人針對不同的問題成立不同的專項進行治理，問題的底層邏輯有交叉。有的治理沒做什么動作，反而收到了較好的結果，有的治理對于結果說不清。治理方法不標準流程規范缺失：對于每個方向、每類問題的治理缺少理論指導，治理的方法、動作、流程、步驟依賴治理人的經驗和判斷。問題難度量追蹤：治理的問題缺少衡量標準，更多靠人為來進行判斷，治理效果缺少評估體系。解決方案難落地：解決方案存在于文檔中，需要治理人查找理解，缺少工具支撐，成本較高。數據2022年美團技術年貨效落地。下面介紹一下我們在治理體系化層面的

39、理解和思考。3.1什么是數據治理體系化？針對數據管理和治理，我們期望搭建一套集管理體系、方法體系、評價體系、標準體系、工具體系等核心能力的組合，持續服務于數據管治實施?？梢灶惐纫话愕碾娚坦?，如果需要運轉并服務好顧客，它首先必須搭建起來一套銷售體系、產品體系、供給體系、物流體系、人力體系等等，只有這樣才可以相互配合，實現服務好用戶這一大目標。圖 2數據治理體系思考3.2數據治理體系化如何解決目前治理存在的問題？方式方法上：先做頂層治理框架設計，從團隊整體視角定義和規劃好治理的范圍、人員、職責、目標、方法、工具等必須部分，再進行落地。更關注整體策略的普適性及有效性，而非深陷某個具體問題解決方案開

40、始治理。技術手段上：以完善的技術研發規范為基礎，以元數據及指標體系為核心，對業務數倉和數據應用進行全面評價和監控，同時配套治理系統工具，幫助治理同學落地治理策略和解決數據開發同學治理效率低問題。運營策略上：通過對待治理問題進行影響范圍、收益情況進行評估，確定待治理問題的重要度，從管理者視角以及問題責任人視角 2 個途徑推動不同重要程度的治理問題解決。數據2022年美團技術年貨圖 3數據治理體系概覽體系框架建設成果：業務數據治理體系框架是針對數據治理工作整體做的頂層方案設計，框架定義好了業務線數據治理是什么、怎么做、做什么、用什么工具以及達成什么目標。拉齊各方對業務數據治理的認知，標準化治理路徑

41、方法和組成部分，指導數據治理有序、有效地進行。圖 4數據治理體系框架數據2022年美團技術年貨針對上述三個問題，我們從解決問題的視角出發，劃分數據開發流程，通過事前約束、事中監控、事后分析評估的思路，整理補齊缺失的流程規范，從而實現標準流程規范在數據管治各環節全覆蓋，并建設系統化工具來保障標準規范的落地實施。下文將分別從規范建設及工具保障兩方面來介紹我們在數據治理標準化過程中是如何解決上述問題的。圖 6數據治理標準化思路4.1.1規范建設規范是數據治理建章立制的基礎，針對標準規范建設不合理及流程規范缺失的問題，我們用體系化的建設思路從整體架構上對數據開發流程及數據治理流程進行劃分，并針對全流程

42、數據管治各個環節建設相應規范：數據治理管理規范：明確數據治理組織職責以及人員構成，確定數據治理實施流程及治理問題運維流程，以保障數據治理過程順利進行。數據研發規范：明確數據開發各個環節需要遵守的規范要求，從問題產生的源頭，通過建設完善的研發規范，指導研發工作按標準進行，一定程度上可減少問題發生。數據標準化治理 SOP：明確各個治理問題治理動作，確保治理動作是標準且可實施。數據2022年美團技術年貨規范質量差：文檔沒有統一進行維護，無法持續進行迭代和完善，不能隨著業務及技術的發展更新。規范沒權限：文檔散落在各個成員的私人空間內部，未對所有人開通權限，優質內容無法及時共享。針對上述問題，我們重新收

43、集整理已有規范文檔并進行分類，補充缺失文檔，優化文檔內容，并新增知識中心模塊，將知識體系框架產品化，在產品層面維護統一的入口及權限管理，同時嚴格控制發布流程，解決了標準規范在實際落地時“找不著”、“質量差”、“沒權限”等問題。圖 8知識中心及文檔發布流程測試規范工具化-八卦爐在數據測試規范落地方面，以往數據測試規范都是通過 Wiki 維護，無法約束大家實際執行過程，導致數據質量較差，容易出現數據故障。為減少數據開發過程中由于測試不規范而導致數據故障的情況，提升數據質量及業務滿意度，我們利用數據中心與數據平臺工具組合作共建的 ETL 測試工具（美團內部工具-八卦爐）來保障測試規范數據2022年美

44、團技術年貨圖 10無效任務治理 SOP 及美團的自動化工具4.1.3標準化收益及建設經驗通過數據治理標準化建設，我們解決了團隊在數據治理規范方面若干問題，取得了明顯效果：實現了數據開發、數據治理的標準化，解決了團隊內各小組之間在開發、管理、運維方面流程方法標準不一致的問題。通過測試工具對標準化測試規范進行落地，在事前阻塞問題發生，提升數據質量，減少故障發生。通過 SOP 自動化工具，有效保障治理過程的標準化，解決了治理效果差的問題。同時，我們在實際建設的過程中，也總結了一些標準化的建設經驗：標準規范如何落地，需成為標準流程規范建設的一部分，最好有交付物。標準規范的制定，除常規內容外，需要綜合考

45、慮組織目標、組織特點、已有工具、歷史情況、用戶反饋等因素，否則會給人“不接地氣”的感覺。標準規范的制定要優先考慮利用和適配已有工具能力，借助工具落地，而非讓工具適配流程規范。4.2數字化以往大家在開展數據治理工作時主要依賴經驗判斷，缺乏科學可量化的抓手，對治理問數據2022年美團技術年貨4.2.2元數據倉庫建設元數據是描述數據的數據，包含數據資產種類、數據存儲大小、數據流血緣關系、數據生產過程等信息，存在信息種類多，分布零散，信息不完整的特點。豐富的元數據有助于我們快速了解團隊數據資產，讓數據資產更加精準，透明。為數據使用和價值釋放提供支撐。我們的建設思路，采取數據業務化、業務數字化、數字應用

46、化的思路來搭建元數據倉庫。數據業務化：即將數據工程師日常數據開發工作業務化描述，抽象多個業務過程，如需求提出、任務開發、數據表產出、數據應用、需求交付。業務數字化：用建設業務數倉的思路和方法，對數據業務化之后的各個業務過程及主題，搭建元數據數倉及指標衡量體系，并通過元數據場景化應用提升易用性及豐富度。數字應用化：在元數據倉庫基礎上開發數據產品，驅動數據管治實施。圖 12數據業務化思路通過數據業務化思路，我們抽象業務域、管理域、技術域等 3 大主題域來描述元數倉對象，并對每個主題域進行細分，劃分多個主題：數據2022年美團技術年貨圖 15元數據倉庫建設成果4.2.2指標體系建設一個問題的衡量需要

47、從多方面進行考慮，只用一個指標無法充分說明問題，這就需要一組有邏輯且相互關聯的數據指標來描述問題。在數據開發過程中，需要制定多個指標來監控衡量數據開發團隊在質量、安全、效率、成本等方面存在的問題。此前，住宿數據團隊沒有一套成熟穩定的指標體系，無法長期準確衡量團隊的業務支持能力、技術能力。2020 年，我們在元數據倉庫基礎上搭建了數據治理指標體系，全面衡量了業務數倉建設過程中各類問題，通過指標體系監測工作中的優點與不足，提升了團隊的工作能力，進而提高了對業務的支持能力。數據2022年美團技術年貨圖 17指標體系建設成果元數據及指標體系應用：團隊管理：幫助團隊管理者快速了解團隊情況，提升管理效率。

48、數據治理：利用元數據及指標體系驅動數據治理，為數據治理提供可量化的抓手。項目評估：幫助項目成員準確評估項目的問題、進展及收益。建設思考在指標建設過程中，我們沉淀了以下幾點經驗：指標體系既要解決管理者對日常工作無抓手的問題，也要成為具體問題處理人員的治理抓手，兼顧管理者和開發者。指標體系是展示偏整體層面的內容，還需通過指標解決實際問題，形成指標體系和數據治理工具閉環，實現發現問題、治理問題、衡量結果持續循環。數據2022年美團技術年貨資產等級建設（數據表）下圖是針對數據表資產等級建設的方法和流程圖：圖 19數據表資產等級劃分1）確定影響因子及權重評估影響因子的確定是資產等級計算中最為關鍵一環，合

49、理評估影響因子對最終資產等級結果的準確性至關重要。根據實際數據開發中經驗可知，影響數據表重要程度主要有以下幾個關鍵因素：下游類型：決定下游資產重要程度，下游資產類型一般有 ETL 任務和數據產品兩類，ETL 任務及數據產品又根據重要度分為普通型及 VIP 型。下游數量：決定是否是關鍵節點，對下游生產的影響范圍，下游數量越多表明影響范圍越大。使用熱度：決定是否有用，影響查詢用戶的范圍，熱度越高表明影響的用戶范圍越廣。鏈路深度及分層：決定問題的修復時間，鏈路越深，問題修復的時間可能就越長。確定好影響因子之后，我們需要判斷每個影響因子所占的權重值。我們采用層次分析法來計算權重值（層次分析法主要應用在

50、不確定情況下及具有多數個評估準則的決策問題上，具體計算步驟，大家可查閱相關的資料），其優點是把研究對象作為一個系統，按照分解、比較判斷、綜合的思維方式進行決策，而且計算過程簡潔實用。數據2022年美團技術年貨4.3系統化4.3.1數據百品-管治中心除了標準化和數字化之外，我們數據治理體系落地仍面臨諸多問題：數據資產無法統計和描述，管理者及數據工程師不知道有什么，缺乏資產的可視化。管理者缺少抓手發現團隊的問題，且問題難以追蹤。治理線上化程度低，需要跳轉多個工具，治理效率低，治理過程無法標準化，導致結果無法保障。針對上述問題，我們搭建了數據百品-管治中心治理平臺（美團內部產品），實現了集資產管理、

51、問題分析監控、自動化治理、過程追蹤、結果評價的一站式、全覆蓋數據治理平臺，能有效提升治理質量和效率，為數據質量提升做好強有力的支撐。通過“管+治”相結合的理念，分別從管理者及研發人員的視角對數據、人效等問題實現全面監控，并實現了資產全景、管理中心、治理中心三大模塊：圖 22管治中心建設思路數據2022年美團技術年貨管理動作天級別。管理者發現團隊某核心指標異常（例如：故障數），需要找對應的責任人詢問，無法從系統上快速進行異常追蹤，原因獲取。管理中心主要從管理者視角出發，解決了怎么管的問題，通過管理者關注的核心指標，為管理者提供監測團隊狀態、判斷團隊問題、輔助管理決策的能力，讓管理者從“依賴經驗管

52、理”轉變為“數據驅動管理”。包含管理者大盤、運維管理、需求管理、團隊管理四大模塊：管理者大盤：向管理者提供團隊核心指標總覽、問題趨勢分析、異常明細追蹤、異常原因標記等功能，方便管理者快速了解團隊情況，及時做出管理動作。需求管理：提供詳細的人效分析大盤以及需求管理功能，服務于人效管理及提效。故障管理：提供詳細的故障分析大盤以及故障復盤管理能力，提升故障管理效率。團隊運營：團隊周月報，值班，滿意度問卷等團隊運營需要的能力，提升運營效率。圖 24管理中心建設思路數據2022年美團技術年貨圖 25治理中心建設思路4.3.2SOP 自動化工具在日常數據治理過程中，每個團隊都會沉淀若干 SOP 規范文檔來

53、指導大家進行問題治理，減少問題發生。但是在 SOP 的落地上，依然存在很多問題：SOP 一般以 Wiki 形式存在，實際執行過程無法跟蹤約束。SOP 動作的執行需要跳轉多個平臺系統，執行效率低下。建設方案基于上述問題，我們開發了 SOP 自動化配置工具。SOP 自動化工具是一款 SOP 配置工具，適用于問題治理類 SOP，將治理動作通過工具進行配置以提高治理效率，進而保證過程質量和結果質量。目標是解決 SOP 規范文檔在落地過程中遇到的執行效率低、過程無法跟蹤監控的問題，實現一站式解決問題的能力。SOP 自動化工具主要包含基礎組建層、配置層及應用層，以下是產品架構圖及產品界面：基礎組建層：SO

54、P 最小粒度模塊，包括展示類組件（富文本、表格、IFrame），數據2022年美團技術年貨SOP 實際操作步驟如下：用戶在創建 SOP 后可選擇性配置需要展示的數據信息，然后按照 SOP 執行步驟依次拖動各個基礎組件，并填寫執行操作完成 SOP 的配置工作，在效果預覽完成后即可發布上線并生成外嵌 URL。自動化工具主要通過外嵌的形式對外提供服務。圖 28SOP 工具化操作步驟應用場景通過 SOP 自動化工具，數據治理已實現了問題解決過程線上化、步驟標準化，很好地保障了治理效果，提升了治理效率。下圖是無效存儲指標在使用 SOP 自動化工具前后的流程對比，通過對比，我們可以看到之前工程師需要人工確

55、認若干信息，并跳轉多個平臺操作，現在只需要在一個界面完成所有動作，極大地減輕了研發人員的工作量。圖 29無效存儲流程優化對比目前，我們團隊已完成 7 大治理域內 30 多個指標的治理 SOP 建設，并均已通過自動化工具落地。后續，我們仍將探索其他專項治理內容，并利用 SOP 自動化工具輔助開展數據治理的工作。數據2022年美團技術年貨圖 30業務數據治理實施流程六、總結與展望經過在數據治理體系化建設上的持續思考與實踐，我們的體系化框架基本建立，在數據治理的標準化、數字化和系統化三個方向上取得了較大的進展，并且在業務應用上取得了一定的成績。更重要的是，我們在數據成本、安全、效率等多個領域都幫助業

56、務解決了實際的問題，尤其是在成本方面，預計每年可以幫助業務可節省數百萬的成本，獲得了業務方的肯定。但對比“理想終態”，我們的工作仍任重道遠。數據治理體系化框架這個龐大“身軀”中的各個血脈、骨骼、臟腑還需要持續充盈，在流程規范、元數據數倉、指標體系、資產分級等的建設過程中，還有很多需要靠專家經驗、人為判斷、人工操作串聯的場景存在。下一步，我們將在智能化（如智能化元數據服務、智能化數據標準建設等）、自動化（基于治理框架的治理應用場景的線上化建設等）等方面發力。七、作者簡介王磊、有為、尉斌等，均來自美團數據科學與平臺部。數據2022年美團技術年貨從對體系化建模的定義來看，它強調了兩個統一，即數據需求

57、與模型設計的統一和模型設計與物理實現的統一。數據需求與模型設計的統一，模型設計是倉庫領域劃分和具體需求相結合的產物。倉庫領域劃分是對數據進行基于業務本身但超越和脫離業務需求限制的抽象，對數據完成主題、業務過程的抽象，作為業務指標、維度需求歸屬和實現數據建設高內聚、低耦合的重要依據；具體的需求模型設計，是在倉庫領域劃分基礎上的內容填充，將需求以指標、維度的形式歸屬到對應的主題與業務過程，以此驅動和約束具體詳細模型設計，勾勒出寶貴的信息架構資產。模型設計與物理實現的統一，基于模型設計環節沉淀的信息架構元數據，以此來驅動和約束實際的物理模型，約束對應物理模型的 DDL，在數據加工時，防止因缺乏有效約

58、束帶來的“煙囪式”開發，是模型上線前，自動完成業務定義與物理實現一致性驗證，確保 DML 實現的正確性。3.為什么要進行體系化建模此前一段時期，配送數據建設存在著需求管理（指標、維度）、模型設計、模型開發相互割裂不統一的現象，數據架構規范無法進行實質、有效的管理，元數據（指標、維度、模型設計）與實際物理模型割裂、不匹配，造成各種數據資產信息缺失。而且由于缺乏系統抓手，無法完全規范研發的模型設計質量，導致部分需求直接進行了數據開發，引起惡化模型建設質量的問題。這種缺乏規范和約束帶來的“煙囪式”開發，在浪費技術資源的同時造成數據重復且不可信。配送體系化建模切入點是：以規范“基礎數據建設”，消除因“

59、煙囪式”開發給業務帶來的困擾和技術上的浪費。3.1體系化建?？梢詫祿軜嬤M行實質有效的管理，從源頭消除“煙囪式”開發體系化建模不僅可以在工具上實現一體化設計和開發，而且能在機制上形成模型設計與開發實施的有效協同。以需求驅動模型設計，以模型設計驅動和約束開發實施，防止因模型設計與開發實施割裂、開發實施缺少約束帶來的無序、“煙囪式”開發。數據2022年美團技術年貨的主題、業務過程，然后基于數據定義標準，對業務指標進行結構化拆解，實現指標的技術定義，完成高層模型設計；其次，基于高層模型設計環節沉淀的元數據，驅動和約束最終的物理模型設計，為后續的數據加工確定最終的 DDL，完成物理模型設計，以此來約

60、束后續的數據開發。圖 3體系化建模流程4.1高層模型設計一線的數據需求都是以指標和維度的形式提給數據工程師的，數據工程師首先要根據拿到的指標需求確定要分析的業務過程，完成業務過程的劃分和定義，同時將指標歸屬到對應的業務過程下；其次，根據指標的業務口徑，將業務指標拆分成原子指標+限定條件+時間周期或計算指標+限定條件+時間周期形式，完成指標的技術定義；第三，綜合各方分析視角，完成該業務過程一致維度的設計，多個業務過程一致性維度的設計構成該主題下的總線矩陣。上述高層模型設計，涉及兩個環節。第一，通過業務抽象完成領域模型劃分，我們基于業務的實際流程來劃分業務過程，并按照分析領域完成業務過程的歸屬。在

61、特定的業務下，分析領域和對應的業務流程不會隨著分析需求的變化而變化，領域劃分也不會隨著分析需求的變化而變化，可以基于此劃分，構建穩定的資產目錄。第二，通過完成業務指標的技術定義并將其歸屬到特定的業務過程下，以及確定特定業務過程的分析維度完成邏輯建模。邏輯建模進一步勾勒出了在特定的分析領域和業務過程下，具體的分析度量和分析維度，完成最終的高層模型設計，高層模型的設計決定了在特定的分析域和分析業務過程下的具體物理產出。數據2022年美團技術年貨標。由于衍生指標是由原子指標/計算指標衍生出來的，所以衍生指標需要歸屬到原子指標/計算指標所屬的業務過程。4.限定條件：限定條件是指標業務口徑的一個邏輯封裝

62、，時間周期也可以算作一類特殊的限定條件，是衍生指標必須包含的。在物理實現上我們將其加工成衍生事實的一個邏輯標簽。在這樣的定義后，衍生指標便清晰地分為原子衍生指標和計算衍生指標兩類，都可以比較容易地通過結構化的方式半自動生成定義和實現。衍生指標覆蓋了用戶生成報表等數據產品的所有指標，而原子指標和計算指標作為指標體系的核心內容不直接提供給用戶使用。在指標的實現方式上也容易明確，原子指標和計算指標的邏輯盡量下沉在基礎事實層中，而衍生指標在中間層和應用層根據需求實現。4.2詳細模型設計詳細模型設計是將高層模型設計轉化為實際物理生產的橋梁，詳細模型設計必須結合數據的生產流程，給出與其分層模型相匹配的實際

63、物理模型。根據數倉不同分層間的職責邊界，詳細模型設計又呈現出不同特點。具體說來，需要數據工程師結合業務需求，對應的邏輯建模產出的 DDL 完成最終物理模型的加工生產，這是我們詳細模型設計的核心，對于中間層匯總模型，是為提高查詢性能，基于明細模型進行預計算的過程，不涉及任務業務口徑的加工，只要元數據定義清晰，完全可以通過工具實現“TEXT2SQL”進而實現配置化生產。我們的工程師只需要關注基建層的開發，中間和應用層建設交給工具完成，節省了大量的時間和精力。在展開詳細模型設計之前，我們先介紹一下數倉分層，然后通過數據分層來介紹與之匹配的詳細模型設計。4.2.1數倉分層簡介按照整個數據生產的流轉鏈路

64、看，數據會經歷產生、接入、加工到最后的消費，數倉的建設主要集中在數據的接入和加工環節。數據的接入包含數據的獲取和清洗兩個過程，通過該過程完成了數據從業務系統到倉庫的流轉，為后續基于分析場景的數據建數據2022年美團技術年貨4.2.2元數據驅動的詳細模型設計設計理念元數據驅動的詳細模型設計，是基于高層模型設計產出的邏輯模型，進而來驅動和約束后續要加工的物理模型 DDL，大致分成三步：第一，確定物理模型名稱；第二，基于模型歸屬自動生成基礎事實，基于需求確定衍生事實，完成事實確定；第三，基于總線矩陣，確定模型一致性維度。每一步具體操作的內容因模型所屬的倉庫分層不同而有所區別。對于中間匯總層而言，只是

65、在基礎模型基礎上的多維上卷，基礎模型確定以后，人工通過簡單的指標拖拽，就可以自動生產 DDL 而且可以自動生產 DML，相對較簡單，在此不做詳述。接下來，我們重點描述一下基礎事實層的詳細模型設計，具體如下圖所示：圖 6詳細模型設計第一步，根據模型的出處確定模型名稱，經過此處，不僅規范了模型命名，而且在數據生產前自動實現了資產掛載，方便了后續數據的管理和運營；第二步，根據第一步的模型掛載，約束并確定該模型要生產的事實，即該模型所包含的基礎事實字段由對應業務過程下的快照表決定，自動生產基礎事實字段，該模型所包含的衍生事實由由對應業務過程下的衍生指標所需的限定條件決定，確保了需求、模型設計、物理實現

66、三者的統一。通過該過程，我們約束了實際生產環節物理模型的隨意加工，從源頭消除了“煙囪式”開發帶來的冗余。通過元數據約束了對應主題應該生產哪些事實，從源頭防止了邊界不清帶來的交叉耦合問題，保障了最終物理模型的高內聚、低耦合。數據2022年美團技術年貨系，為后續資產消費環節提供了完備的基礎元數據。按照物理模型設計最終的交付物來看，它的設計流程主要包括兩部分：第一，按照規范和標準，確定物理模型的名稱；第二，按照規范和標準，確定物理模型的數據字典。1.通過確定所建物理模型對應的數倉層級、主題域和業務過程，自動生成該物理表的名稱。圖 9詳細模型設計之確定物理表的名稱和資產歸屬1.基于高層模型設計環節確定

67、的分析度量和維度，自動生成物理表對應的數據字典，確保模型設計與最終物理落地的一致性，從源頭杜絕不規范的開發。圖 10詳細模型設計之確定物理表的字段信息并完成指標、維度與字段的映射4.3上線前卡點高層模型設計和詳細模型設計約束和規范了數據工程師如何確定一個模型的 DDL，數據2022年美團技術年貨在美團內部，涉及配送交易、履約等核心主題的規范性建設方面治理評分均取得了優秀的成績，特別是在指標完整性建設得分和物理模型維度完整性得分方面，均取得90 分以上優秀成績。圖 12健康的主題得分得益于體系化建模實現的元數據和數據的統一，我們實現了數據建設從“保姆”模式到“服務+自助”模式的轉變。數據2022

68、年美團技術年貨職等業務場景，得益于上述模式，不僅得到了一線人員廣泛好評，而且也將我們的數據 RD 從“取數”、“跑數”的繁重工作中解脫出來。作者簡介王鵬、新興、曉飛，均來自配送事業部數據團隊。團隊簡介配送數據組負責基于美團配送業務千萬級訂單、百萬級商家和騎手產生的海量數據的實時和離線數據計算體系和產品體系的建設，為業務實現安全、效率和體驗的核心目標，為新一代智能即時配送系統美團超腦建設數字化、智能化的系統能力，提供數據支撐，為業務的運營管理、策略決策和算法策略提供完善的數據體系和基于數據科學的決策能力。作為美團萬物到家的基礎，美團配送擁有最豐富的實時計算和離線計算場景，應用業界最先進的數據計算

69、技術架構，建設保障數據及時性、一致性、準確性、完整性，保障數據計算和服務的穩定性的技術能力。歡迎你的加入，跟美團配送數據團隊一起打造業界領先的數據支撐平臺。數字化新業態下數據安全創新Token 化作者:志剛0.引言伴隨科技創新引領數字化浪潮席卷全球，數據成為企業發展的核心生產要素。像Google、Facebook 等高科技公司，通過提供免費、優秀的軟件和服務，接入大量的用戶，并基于數據資源驅動，獲得了巨大的商業成功。然而，在高速發展的同時，公司對數據卻疏于治理，引起了大量的數據泄漏、算法濫用以及隱私相關的問題。這種危機伴隨著 Facebook 的“劍橋分析”丑聞、2020 年美國大選等標志性事

70、件，推向了高潮?；趯祿踩碗[私的擔憂，歐盟的 GDPR 領銜的現代隱私合規出臺，隨后風靡全球，成為又一不可逆轉的潮流。擺在企業面前是兩條路，既要通過數據科技創新保證生存發展，又要保證用戶數據的安全。在這兩條路的選擇與平衡上，有些企業倒下了，有些企業存活下來，并迸發出新的勃勃生機。由此可見，唯有轉變思路，勇于創新，才能化危為機，長遠發展。我們要認清轉折趨勢：數字化時代從上半場粗放、低效，大水漫灌式碳增長，向基于高效數據管理、治理能力的高質量、高效率的數據碳中和轉變。企業要在這個轉變中生存并脫穎而出，科技創新是重要的抓手，而重點是把握兩大核心思想：1.需要認清強大數據應用生產力特征，積極進行

71、技術改造，充分利用先進的數據管理技術手段，提高數據使用效率和治理水平。2.深入學習、理解隱私合規的目的和本質，遵循“可用、不可見”的核心思想，實現效率與治理的統一。運維/安全862022年美團技術年貨1.數據科技對安全的挑戰在數字化應用環境下，數據具有如下特征：1.數據的流動性與開放性：按數字經濟學理論，數據要想創造出商業價值，就必須做到低成本、大規模供應，高效流動。如果利用傳統網絡安全最小化、層層審批、層層設防，將嚴重限制數據生產的活力。此外，在數據流經的每一個節點都達到高級的防護基準，起成本也是組織無法承受的。2.數據的可復制性和失控性：數據作為流動資產，一旦被訪問后其控制權將被轉移，供應

72、者將失去對它的管控。傳統的信任邊界在數據應用中也越來越模糊，這些都讓集中安全策略在新型數據架構下落實起來成本巨大，收效甚微。3.數據形態多變、應用復雜：數據將在幾乎所有 IT 系統中傳遞、存儲和處理，其復雜程度超乎想象。加之 AI、機器學習以及各類創新型數據應用，讓數據使用邏輯更難以琢磨，要想了解數據的全貌幾乎是不可能的任務。4.數據威脅復雜多變：數據的巨大商業價值讓包括黑、灰產業鏈，內、外部人員乃至商業、國際間諜都趨之若鶩。攻擊技術、動機層出不窮，防不勝防。圖 1常規系統為中心防護模式下數據暴露性運維/安全2022年美團技術年貨但只有少數富豪才雇傭得起，因此社會資產大量流失。銀行體系應運而生

73、：用戶獲得現金后，第一時間去銀行將現金兌換成存款（等價代替物），隨后在整個社會中流通的都是這個代替物-電子現金，只有在極個別場景兌換成現金。隨著銀行系統的滲透，加上各類線上支付應用的普及，這種現金使用場景越來越少。要想搶錢，只能到銀行去，而銀行是經過重點防護。同樣，數據作為核心資產，可以通過方案在個人敏感數據數據（PII）剛進入組織業務系統時，就將明文數據（P）替換成與其一一對應的假名-Token。在隨后的整個組織應用環境中以 Token 高效流通。因為 Token 與明文是一一對應的，可以在生命周期絕大多數場景代替明文傳輸、交換、存儲和使用，而 Token 只有通過安全可靠的Token 化服

74、務，才能兌換成明文。黑客和內外部惡意攻擊者即便拿到了也毫無用處（不可見）。由于 Token 的自帶安全屬性，只要在組織內控制住主要數據源和數據樞紐只使用 Token 流通。新的明文數據需主動換成 Token，實現數據默認安全，也就從根本上解決了個人敏感數據的治理難題。圖 3Token 化的數據暴露性運維/安全2022年美團技術年貨勢替換通用數字化場景中的個人敏感信息（PII）。1.個人唯一標識信息（PII）：任何可以直接、間接關聯到具體的自然人的唯一標識信息如身份證件、手機號、銀行卡、電子郵件、微信號或者地址。單獨依賴 PII 信息，結合其他公開信息，就可以找到自然人。PII 信息一旦泄漏，可

75、能對個人造成如身份冒用、欺詐等生命財產傷害。因此，在包括國內外各類法規中明確要求企業對 PII 全生命周期保護。2.去標識化（De-identification）：通過一定技術手段，對敏感數據進行替換、轉換，臨時或永久消除個人敏感數據與自然人的關聯。具體的手段包括假名化、匿名化、數據加密等。3.假名化（pseudonymization）：通過將敏感數據替換成人工 ID 或假名，未經授權，任何人無法利用假名建立起與原自然人之間的關聯。Token 化就是一種假名化實現機制，廣義上二者可以概念互換。假名化是包括 GDPR 在內認可的去標識化方案。注意，假名化與 PII 是一一對應，在特定場景是可以還

76、原原始數據。4.匿名化（Anonymization）：對敏感數據部分，或全部進行遮蓋、替換，讓其完全失去與原數據或自然人的關聯。匿名化是不可逆的，常用的匿名化技術包括數據遮蓋（DataMasking）。5.數據加密：采用數據加密算法，如國密對稱算法 SM4，普密算法 AES，對敏感數據進行加密，生成密文（Cipher），除非獲取如密鑰管理系統（KMS）加密密鑰授權，無法進行解密，獲得明文。注意與假名化 Token 不同的是，密文只能解密出明文后才能使用，沒有任何直接使用屬性。因此密文只能用來存儲和信息傳遞，大大限制了使用范圍，例如搜索、關聯、查詢、匹配等數據分析場景。運維/安全2022年美團技

77、術年貨圖 5Token 化邏輯示意圖1.隨機化：Token 完全隨機生成，并通過保存一一映射關系表（這種是狹義的Token 化生成方式）。因為 Token 與明文沒有算法關系，只能通過 Token 化服務才能進行正、反向關聯，因此是最安全的方案。但這個方案的缺點是，為保證 Token的高度一致性，新 Token 生成邏輯不能并發，否則會出現一對多的一致性問題。為保證數據一致性，將犧牲一定的分布式能力、性能。無形增加了可用性風險，尤其是遠程異地場景。圖 6Token 化生成方法 12.MAC 方式：通過統一的加鹽哈希 HMAC 算法，任何進程、任何位置都能生成相同的 Token，保證一致性。生成

78、后的 Token 與明文的映射關系落表，實現反 Token化能力。該方式優點是可以跨地域實現分布式，缺點是犧牲了一定的安全性。攻擊者運維/安全2022年美團技術年貨3.4Token 化方案邏輯架構圖 9Token 化邏輯架構圖Token 化服務需要滿足全業務場景兼容性、安全性和可用性，主要通過多種接入集成方案。并集成必要的安全措施。Token 化服務按邏輯分為接入層、服務層和存儲層。1.接入層：主要用來對接業務應用和人員訪問，完成 Token 與明文之間的轉換即 Token 化和反 Token 化請求需求。分別提供人機接口（Portal）、服務接口（API）調用和大數據任務請求。由于 Toke

79、n 化安全要求，接入層需要保證可靠的安全措施，如細粒度訪問控制、IAM、服務鑒權和大數據作業鑒權能力。2.服務層：實際執行 Token 化和反 Token 化的行為。主要是完成 Token 的生成、存儲以及查詢。3.存儲層：存儲層主要包含線上存儲和數倉。由于安全性考慮，Token 化映射表并不存儲明文而是保存加密后的密文。同時，通過 HMAC 算法建立HASHToken 密文的關聯關系實現明文換 Token（正查）和 Token 換明運維/安全2022年美團技術年貨組件說明：1.線上數據源敏感數據的主要數據來源，一進入公司需要對接 Token 化服務 API 兌換成 Token，并落庫存儲。一

80、定場景，數據也會接入數倉。數據源另外角色是向下游提供分享敏感數據，可通過 API、MQ 或共享存儲如 S3 等媒介。2.數倉數據源直接倒入或來自線上，敏感數據進入數倉，需要啟用 Token 化任務，將明文轉換成Token，并隨后向下游其他大數據應用提供。3.Token 化服務a）Token 化線上服務通過 API 為線上交易、事實任務提供明文換 Token 服務。b）Token 化離線 Hive，為大數據任務提供離線數據清洗服務，將明文轉換成 Token。4.KMS 和加解密a）為 Token 化派發加密密鑰，并將明文加密形成密文字段。b）為所有具有解密權限應用派發解密密鑰，進行解密。5.數據

81、應用a）常規中間應用：基于 Token 就能完成業務功能的服務。從數據源獲取 Token，并向下游傳遞。b）解密應用：按業務需求，滿足安全基線前提下，用 Token 換取密文，并對接加解密模塊進行解密，獲取明文。運維/安全2022年美團技術年貨Token換明文邏輯只返回密文，由請求服務利用 KMS 本地進行解密，集中控制解密權限；UI 提供用戶人工進行 Token 與明文，加解密的能力。要求必須經過 IAM，并支持基于 ABAC 的細粒度、基于風控的訪問控制。2.生態上下游服務、應用產生的次生安全不論數據源，還是下游的明文數據消費方，因具有 Token 化接口訪問授權，技術上是可以遠程調用接口

82、，遍歷出全量的 Token 和明文的映射關系。因此，安全措施需要延伸到這些系統和用戶，保證不會因為這些錯誤行為或程序漏洞導致的數據泄漏。a）構建數據應用安全基線，約束上下游數據使用行為；b）嚴格禁止任何形式的非法明文，尤其是 Token 與明文的映射關系數據轉發轉存行為；c）禁止設置代理，必須由數據服務主體直接對接 Token 化服務；d）所有生態系統必須進行完整的安全評審，包括后續的變更。確?；€合規；e）對上下游所有的服務，納入監控體系，包括其存儲、數據接口以及應用代碼邏輯、血緣；f）全局監控、掃描，確保所有不合規的處理及時發現、處理。5.工程實踐經驗Token 化服務從設計上并不復雜，一

83、旦實施，將徹底改變組織數據使用習慣，從根本上解決數據使用效率與安全合規間的矛盾。然而，其強大的防護效力是基于對數據使用邏輯的改造，打破舊有的明文數據使用習慣，落地過程面臨在巨大的挑戰，包括疏于維護應用代碼，冗余的、混亂的歷史數據、復雜混亂的訪問邏輯，這些問題都會為系統改造帶來障礙。需要所有涉及敏感數據的業務配合改造，這種規模項目，必須從流程規劃、組織保障和技術支撐等多方面運維/安全2022年美團技術年貨6.未盡事宜后續，數據安全治理還將繼續延伸。在數據層面，Token 化沒有解決類似圖片、視頻等非結構化數據?？赡苄枰苯油ㄟ^加密。Token 化沒有解決跨企業信任邊界的數據交換問題，這部分需要隱

84、私計算、多方安全計算等新技術。Token 化主要對象是存在 DB、Hive 中的結構化 PII 信息。對于隱藏的在 JSON 中的半結構化數據和日志、文件中的非結構化 PII 數據并沒有處理，需要配合強大的數據發現和數據治理工具完成。在整個數據安全體系中，PII 只是滄海一粟，Token 化實際上也僅僅解決企業內部數據使用場景，但卻開了一個默認安全和設計安全的先河。由于 PII 信息是個人敏感信息的核心數據，功過 Token 化，上可以溯源到數據采集、下可以延伸到三方數據交換。此外，通過 Token 去關聯，可以實現無損數據刪除等能力。數據安全是一個巨大的課題，尤其是在數字化變革的強大發展需求

85、下，面對紛繁復雜的數據應用，網絡安全需要更多的技術創新，我們希望通過 Token 化“拋磚引玉”，激發出更多數據安全的創新之路。7.本文作者志剛，美團安全架構師，密碼學、云原生和 DevOPS 安全，數據安全和隱私合規專家。運維/安全2022年美團技術年貨海外資料BlackHat在 BlackHat2021 的峰會中，Datadog 工程師 GuillaumeFournier 帶來主題為WithFriendsLikeeBPF,WhoNeedsEnemies?的分享，他介紹了 eBPF 如何被惡意利用，包括如何構建一個 rootkit、如何利用，并將檢測防御代碼放在了GitHub上。DEFCON

86、在 DEFCON29 峰會上，安全研究員 PatHogan 也分享了一些 eBPF 被惡意利用的案例：WarpingReality-creatingandcounteringthenextgenerationofLinuxrootkitsusingeBPF，這里介紹了 eBFProotkit 的應用場景，包括網絡、運行時等場景，以及如何檢測 eBPF 被惡意利用等。代碼也放在了 GitHub上。運維/安全2022年美團技術年貨eBPF hook 位置從圖中可以看出，eBPF 的 hook 點功能包括以下幾部分：1.可以在 Storage、Network 等與內核交互之間；2.也可以在內核中的功

87、能模塊交互之間；3.又可以在內核態與用戶態交互之間；4.更可以在用戶態進程空間。eBPF 的功能覆蓋 XDP、TC、Probe、Socket 等，每個功能點都能實現內核態的篡改行為，從而使得用戶態完全致盲，哪怕是基于內核模塊的 HIDS，一樣無法感知到這些行為?；?eBPF 的功能函數，從業務場景來看，網絡、監控、觀測類的功能促進了云原生運維/安全2022年美團技術年貨內核再將該數據包轉發出去。按照 XDP 與 TC 在 Linux 內核中，處理 ingress 與 egress 的位置，可以更準確地確定 hook 點。XDP 的 BPF_PROG_TYPE_XDP 程序類型，可以丟棄、修改

88、、重傳來自ingress 的流量，但無法對 egress 起作用。TC 的 BPF_PROG_TYPE_SCHED_CLS 除了擁有 XDP“BPF_PROG_TYPE_XDP”的功能外，還可以對 egress 起作用。前者最常用的場景就是做網絡防火墻，用于網絡流量清洗，效率比傳統防火墻的高很多。后者常用于云原生場景下，容器、Pod 的網絡監控、安全訪問控制等。在這個例子中，要對進出流量都做調整，故兩個 hook 點都需要有。同樣，在 XDP 等階段的hook，在這里做相關包邏輯的處理，能更好地將通信包隱藏，tcpdump 等工具都抓不到。運維/安全2022年美團技術年貨/讀取 map，是否已

89、經存在該 client 信息struct netinfo client_key=;_builtin_memcpy(&client_key.mac,&pkt.eth-h_source,ETH_ALEN);struct netinfo*client_value;client_value=bpf_map_lookup_elem(&ingress_client,&client_key);/如果沒找到偽裝信息，則自己組裝if(!client_value)_builtin_memset(&client_value,0,sizeof(client_value);else bpf_map_update_ele

90、m(&ingress_client,&client_key,&client_value,BPF_ANY);/偽裝 mac 局域網 mac 信息pkt.eth-h_source0=0 x00;./替換偽裝 ip 來源，客戶端端口不變/更改目標端口pkt.tcp-dest=htons(FACK_PORT);/22/計算 TCP SUM layer 4ipv4_csum(pkt.tcp,sizeof(struct tcphdr),&csum);pkt.tcp-check=csum;/寫入已偽裝的 map，用于 TC 處理 egress 的原 mac、IP 信息還原。return XDP_PASS;比

91、較簡單的 Demo，即可實現 ingress 側 TCP 數據包的偽裝。同樣，TC 層處理egress 方向的數據包時，只需要對偽裝包的原始信息作還原即可。整個流程如下圖所示：運維/安全2022年美團技術年貨危害這個 rootkit 不主動創建 Socket，借用其中一個網絡發送包，把消息送達給后門使用者。對系統影響來說，只是一個不起眼的小網絡響應。在萬千 HTTP 包里，根本定位不到。1.iptables 防火墻繞過：利用對外開放的 80 端口作為通信隧道；2.WebIDS 繞過：流量到達服務器后，并不傳遞給 Nginx；3.NIDS 繞過：入侵者流量在局域網之間流傳并無異常，只是無法解密；

92、4.HIDS 繞過：是否信任了防火墻，忽略了本機/局域網來源的 SSHD 登錄。Linux 系統運行時惡意利用云原生生態下，涌現大批基于 eBPF 技術實現的集群網絡管理插件，比如 Calico、Cilium 等。而業務實現網絡管理服務是以容器化方式部署，且有需要給這些容器啟用SYS_BPF_ADMIN 權限以支持 eBPF 系統調用。這些服務的運行環境，也給攻擊者留下一個完美的發揮空間。實現流程回顧 eBPF 的 hook 點，作用在 syscall 的 kprobe、tracepoint 事件類型，倘若用運維/安全2022年美團技術年貨 var payload_shadow=fmt.Spr

93、intf(“%s:%s:18982:0:99999:7:n”,username,hash)/eBPF RewriteContants var editor=manager.ConstantEditor Name:“payload”,Value:m“payload”,FailOnMissing:true,Name:“payload_len”,Value:m“payload_len”,FailOnMissing:true,return editorfunc(this*MBPFContainerEscape)setupManagers()this.bpfManager=&manager.Manage

94、r Probes:*manager.Probe Section:“tracepoint/syscalls/sys_enter_openat”,EbpfFuncName:“handle_openat_enter”,AttachToFuncName:“sys_enter_openat”,.,Maps:*manager.Map Name:“events”,this.bpfManagerOptions=manager.Options ./填充 RewriteContants 對應 map ConstantEditors:this.constantEditor(),運維/安全ret;/判斷原 buff

95、長度是否小于 payload if(read_size file_type)case FILE_TYPE_PASSWD:/覆蓋 payload 到 buf，不足部分使用原 buff 內容 bpf_probe_read(&local_buff,MAX_PAYLOAD_LEN,(void*)buff_addr);for(unsigned int i=0;i=payload_passwd_len)local_buffi=;else local_buffi=payload_passwdi;break;case FILE_TYPE_SHADOW:/覆蓋 shadow 文件 .break;case FIL

96、E_TYPE_SUDOERS:/覆蓋 sudoers .break;default:return 0;break;1142022年美團技術年貨 /將 payload 內存寫入到 buffer ret=bpf_probe_write_user(void*)buff_addr,local_buff,MAX_PAYLOAD_LEN);/發送事件到用戶態 return 0;按照如上 Demorootkit 的設計，即完成了隨機用戶名密碼的 root 賬號添加。在鑒權認證上，也可以配合“eBPF 網絡層惡意利用”的 Demo，利用 eBPFmap 交互，實現相應鑒權。但 rootkit 本身并沒有更改硬

97、盤上文件，不產生風險行為。并且，只針對特定進程的做覆蓋，隱蔽性更好。整個流程如下圖所示：eBPF 在 runtime 安全場景惡意利用不管是在物理機上，還是給了 root+BPF 權限的容器上，都一樣生效。運維/安全2022年美團技術年貨更早，意味著常規 HIDS 并不能感知發現它們。傳統 rootkit，采用 hookapi 的方法，替換原來函數，導致執行函數調用地址發生變化，已有成熟檢測機制，eBPFhook 不同于傳統 rootkit，函數調用堆棧不變。這給檢測帶來很大的麻煩。那面對這種后門，我們該如何檢測防御呢？檢測防御從事件發生的過程來看，分為三個階段：運行前運行時運行后運行前在惡意

98、程序運行前，減少攻擊面，這個思路是不變的。環境限制不管是宿主機還是容器，都進行權限收斂，能不賦予 SYS_ADMIN、CAP_BPF 等權限，就禁止掉。若一定要開放這個權限，那么只能放到運行時的檢測環節了。seccomp 限制在容器啟動時，修改默認 seccomp.json，禁止 bpf 系統調用，防止容器逃逸，注意運維/安全2022年美團技術年貨復雜，所以不希望加入額外的功能，讓 BPF 更加不穩定。而是改變思路，讓字節碼加載時簽名，改為“執行 BPF 字節碼加載的用戶態程序進行簽名”，這個是已有的內核功能，不會增加系統復雜性。本文認為，這確實可以緩解大部分 BPF 字節碼加載的問題。但使用

99、系統原生命令（tcipbpftool 等）加載的話，仍面臨威脅。比如：ip link set dev ens33 xdp obj xdp-example_pass.o。ip 命令加載 eBPF 字節碼運行檢查大部分 eBPF 程序在重啟后不存在了，所以入侵者會盡可能讓后門自啟動。對于Linux 系統的自啟動、crontab 等計劃任務做好檢查。用戶態程序可以以各種形式存在，ELF 可執行文件、ELFso 動態鏈接庫都可以。在執行時，必定會調用 BPFsyscall 來加載 BPF 字節碼。若只是對可執行 ELF 做檢測，還不夠準確。運維/安全cmd=args-cmd;get_common_pr

100、oc(&bpf_context-procinfo);send_event(args,bpf_context);return 0;這里，我們開源的 ehids 項目做了一個 BPFsyscall 檢測的例子，大家可以 Fork 了解。倉庫地址為：GitHub/ehids。細心的讀者這時可能會有疑問，假如入侵者的后門執行比較早，對這個系統調用進行欺騙，那怎么辦呢？這是一個非常好的問題，我們將放到運行后的溯源章節進行討論。但對于大部分場景，HIDS 防御產品還是可以做到第一時間啟動的。審計&篩查上面我們討論了對 BPF 系統的調用進行監控。而在云原生場景中，基于 eBPF 實現的網絡產品會頻繁調用，

101、會產生大量的事件日志，從而給運營同學帶來較大的壓力。那么，對行為做精簡、做精確篩選，就成為我們接下來的目標。根據程序白名單篩選數據過濾，是解決大量數據壓力的一種方案。在一些 BPF 應用的業務服務器上，本身業務行為會產生大量調用，會給安全預警帶來較大審計壓力。對于已知的進程，我們可以根據進程特征過濾。1202022年美團技術年貨獲取當前進程 pid、comm 等屬性，根據用戶態寫入 eBPFmap 的配置，決定是否上報、是否攔截。也可以在用戶態做過濾，但內核態效率更高。如果是做攔截，那必須要在內核態實現。大家可以參考 saBPF 產品設計思路，用 eBPF 實現 LSMhook 點的鉤子程序，

102、完成相關審計調用。雖然 GitHub/saBPF-project的項目代碼還只是 Demo，但思路可以借鑒。根據 SYSCALL 類型篩選在 BPFsyscall 里，子命令的功能包含 map、prog 等多種類型的操作，bpf()subcommandreference里有詳細的讀寫 API。在實際的業務場景里，“寫”的安全風險比“讀”大。所以，我們可以過濾掉“讀”操作，只上報、審計“寫”操作。運維/安全2022年美團技術年貨溯源安全工程師經常需要根據不同場景作不同的溯源策略。本文給的溯源方式中，都使用了 eBPF 的相關接口，這意味著：如果惡意程序比檢查工具運行的早，那么對于結果存在偽造的可

103、能。短生命周期BPF 程序類型代表kretprobeuretprobetracepointraw_tracepointperf_eventsocketfiltersso_reuseport特點是基于 FD 管理，內核自動清理，對系統穩定性更好。這種程序類型的后門，在排查時特征明顯，就是用戶態進程。并且可以通過系統正在運行的 BPF 程序列表中獲取。bpftool 工具eBPF 程序列表命令 bpftool prog show，以及 bpftool prog help 查看更多參數。運維/安全2022年美團技術年貨通過查看 map 信息，可以與程序信息作輔助矯正。并且，可以導出 map 內數據用

104、來識別惡意進程行為。這部分我們在“取證”章節討論。bpflist-bpfccbpflist-bpfcc-vv 命令可以看到當前服務器運行的“部分”BPF 程序列表。以測試環境為例：rootvmubuntu:/home/cfc4n/project/xdp#bpflist-bpfcc -vvopen kprobes:open uprobes:PID COMM TYPE COUNT1 systemd prog 810444 ehids map 410444 ehids prog 5可以看到系統進程 systemd 啟動了 8 個 prog 程序。ehids 進程創建了 4 個 eBPFmap 與 5

105、 個 prog。但實際上前面也執行了 ip link set dev ens33 xdp obj xdp-example_pass.o 命令，在這里卻沒有顯示出來。意味著這個命令輸出的結果并不是所有 bpf 程序、map 的情況。運維/安全2022年美團技術年貨 nla_len=20,nla_type=IFLA_XDP,nla_len=8,nla_type=IFLA_XDP_FD,6,nla_len=8,nla_type=IFLA_XDP_ FLAGS,XDP_FLAGS_UPDATE_IF_NOEXIST ,iov_len=52 ,msg_iovlen=1,msg_controllen=0,

106、msg_flags=0,0)=52可以看到 IFLA_XDP_FD 后面的 FD 參數是 6。同樣，刪除 XDP 程序，需要把 FD設置為-1，對應 NETLINK 包構成如下：17:55:16.306843 sendmsg(3,.nla_len=20,nla_type=IFLA_XDP,nla_len=8,nla_type=IFLA_XDP_FD,-1,nla_len=8,nla_type=IFLA_XDP_FLAGS,XDP_FLAGS_UPDATE_IF_NOEXIST .,0)=52不止 ip 命令，TC 命令分類器也是支持 BPF 程序，將 BPF 程序作為 classifiers

107、和actions 加載到 ingress/egresshook 點。背后原理與 IP 類似，也是 NetLink 協議與內核通信，網卡維持 BPF 對象計數器。檢測機制使用原生 ip、tc 等命令，查看網卡加載的 BPF 對象ip link show運維/安全2022年美團技術年貨用 bpf_obj_get(“BPFFSpath”)就可以獲得 BPF 對象的 FD。BPFFS 在 Linux 的類型是 BPF_FS_MAGIC，默認目錄/sys/fs/bpf/，可自定義修改，但確保文件系統類型是 unix.BPF_FS_MAGIC。在檢測思路上，我們需要關注虛擬文件系統是不是 unix.BPF

108、_FS_MAGIC 類型。在 Linux 系統上，mount-t bpf 來查看系統所有掛在的文件類型，是否包含BPFFS 類型。確定 BPFFS 的目錄后，我們再查看目錄下的掛載點是否存在異常。取證內核已加載的 BPF 對象導出bpftool 工具可以導出有 FDid 的 prog、map。BPFprog 程序可以導出 opcodevisuallinum 等多種格式，并可以生成調用關系圖。具體可以查看bpftool 的幫助文件。rootvmubuntu:/home/cfc4n#bpftool prog helpbpftool prog dump xlated PROG file FILE|o

109、pcodes|visual|linum bpftool prog dump jited PROG file FILE|opcodes|linum BPFmap與 prog 類似，也可以通過 bpftool 導出內容，并支持 JSON 格式化內容。運維/安全2022年美團技術年貨內核未加載的 BPF 對象當定位到后門 rootkit 的用戶空間程序后，那么 BPF 字節碼肯定會被其調用。字節碼內容一般會放在一個獨立文件中，或者作為字節碼編譯到當前程序里。這也只需要使用 IDA 之類反編譯工具，定位到相關字節流，導出即可。以本文演示視頻中的 ehids 進程為例，使用 GitHub/ehids/e

110、bpfmanager 純 Go的 eBPF 模塊管理器 package，對于 eBPF 字節碼會使用 包對 BPF 字節碼進行加載、Gzip 壓縮，作為 Go 代碼的變量，在部署時比較邊界。運維/安全2022年美團技術年貨如何防御eBPF 在網絡安全場景的使用，除了做入侵檢測外，還可以用于防御。LSMPROBEhook 提供了相關功能。以容器逃逸場景為例，行為最明顯的特征是“父子進程”的Namespace 不一致，子進程創建完成后，判斷這個特征是否匹配，返回 EPERM覆蓋進程創建函數的返回值，從而起到防御的目的。相比內核模塊等防御實現，eBPF 實現更加安全、穩定、可靠，從而在源頭上解決容器

111、逃逸的問題。同樣，本文認為 eBPF 也是二進制層最優秀的虛擬補丁、熱更新解決方案。運維/安全2022年美團技術年貨系統兼容性 CO-REeBPF 的出現極大地簡化了編寫內核態代碼的門檻，極高的安全性，友好的加載方式，高效的數據交互，令 eBPF 深受追捧。然而和編寫傳統內核模塊相同，內核態的功能開發伴隨著繁冗的適配測試工作，Linux 繁多的內核版本更是讓適配這件事難度陡增，這也就是 BTF 出現之前的很長一段時間里，bcc+clang+llvm 被人們詬病的地方。程序在運行的時候，才進行編譯，目標機器還得安裝 clangllvmkernel-header 等編譯環境，同時編譯也會消耗大量

112、CPU 資源，這在某些高負載機器上是不能被接受的。因此，BTF&CO-RE 橫空出現，BTF 可以理解為一種 Debug 符號描述方式，此前傳統方式 Debug 信息會非常巨大，Linux 內核一般會關閉 Debug 符號，BTF 的出現解決了這一問題，大幅度減少 Debug 信息的大小，使得生產場景內核攜帶 Debug信息成為可能?？上驳氖?，通過運用 BTF&CO-RE 這項技術，可以幫助開發者節省大量適配精力，但是這項技術目前還是在開發中，還有許多處理不了的場景，比如結構體成員被遷入子結構體中，這時候還是需要手動解決問題，BTF 的開發者也寫了一篇文章，講解不同場景的處理方案 bpf-co

113、re-reference-guide。大型項目在國外，云原生領域產品發展較快，涌現出一批批基于 eBPF 的產品，包括 Cilium、Datadog、Falco、Katran 等，應用在網絡編排、網絡防火墻、跟蹤定位、運行時安全等各個領域，可以借鑒這些大型項目的研發經驗，來加快產品建設，包括多系統兼容、框架設計、項目質量、監控體系建設等。本篇以檢測防御為主，工程建設相關經驗，我們將在以后的文章中分享?？偨Y隨著云原生快速發展，eBPF 實現軟件、運行環境會越來越多。而 eBPF 的惡意利用也會越來越普遍。從國內外的情況來看，國外對這個方向的研究遠比國內超前，我們運維/安全2022年美團技術年貨如

114、何應對開源組件風險？軟件成分安全分析（SCA）能力的建設與演進作者：中文1.前言SCA概念出現其實很久了。簡單來說，就是針對現有的軟件系統生成粒度非常細的SBOM（SoftwareBillofMaterials軟件物料單）清單，然后通過風險數據去匹配有沒有存在風險組件被引用。目前，市面上比較出色的商業產品包括Synopsys的Blackduck、Snyk的SCA、HP的FortifySCA等，開源產品包括國內懸鏡的OpenSCA。但是，通過對這些產品調研和分析后我們發現，它們由于諸如風險數據庫完整度、與現有研發流程耦合程度、性能和社區支持不完整等原因，不能很好地融入企業內部的研發流程，但是在企

115、業內部，這一部分能力對于SDL工作而言，又是不可或缺的一種能力。所以，企業內部的信息安全團隊需要結合業務團隊的需求，安全團隊自身對于風險的理解，企業內部的研發流程現狀，以及現有的技術與數據能力、應用成本和ROI等現狀和問題進行綜合考慮，打造屬于自己的SCA能力，從而幫助業務團隊多、快、好、省地解決軟件供應鏈層面上的信息安全問題，安全團隊也可以更好地對組件風險問題實現全局的治理。從上述的內容可以得知，在企業內部建設SCA能力的過程中，會涉及到很多的產品和運營方面的問題，諸如跨部門協作、系統穩定性、業務和安全部門對于風險的定義不一致等問題。本文主要介紹SCA能力在企業內部實際落地的過程、遇到的問題

116、以及對SCA技術的看法和展望，希望可以為業界同仁提供一個可以參考的解決方案和范本。運維/安全2022年美團技術年貨而根據2020年Snyk發布的另一份開源組件與供應鏈安全的報告顯示，漏洞的數量仍然需要提高警惕，XSS漏洞仍然占據數量榜首，緊隨其后的是命令執行類漏洞，這些漏洞會嚴重影響系統的穩定性。在上述所羅列出來的風險當中，當注意力集中到惡意包（MaliciousPackages）上時，我們可以發現該類型的風險是2019年度上升幅度最快的威脅之一，這也引出了下面的問題。也就是軟件供應鏈相關的風險。2.2供應鏈相關的風險開源組件的生產-構建-發布過程，跟企業內部常規的系統研發上線的流程基本上是一

117、致的，簡單來說可以抽象成下圖中的樣子：運維/安全2022年美團技術年貨中打開”和“InstantMarkdown”，所有這些有問題的擴展累計安裝了大約200萬次，此次事件所造成的影響也是非常廣泛的。提交缺陷代碼：在軟件開發環節，開發人員因為水平、安全意識的諸多原因，往往會在開發過程中引入漏洞，這本身是一件十分正常的事情。但對于開源軟件而言，因為幾乎所有人都可以向開源項目提交代碼，并且通過審核后就可以Merge進項目，所以總會有不懷好意的人故意引入有問題的代碼，比較典型的Case是2021年4月，明尼蘇達大學KangjieLu教授帶領的研究團隊因故意向Linux引入漏洞，導致整所大學被禁止參與L

118、inux內核開發。拋開道德問題不談，這種風險實際上有可能因為審核的疏忽導致風險直接被引入。源代碼平臺被攻陷：其實Git平臺本身由于保護不當，也有極大的概率被攻陷。雖然說攻陷GitHub這種平臺本身不太現實，但是有很多開源項目都是自己搭設的Git平臺，再加上一些眾所周知的原因，Git平臺本身缺乏保護是一件較大概率發生的事情。在2021年3月，PHP的官方Git就遇到了類似的Case，由于PHP官方團隊在服務器上維護的php-srcGit倉庫中被推送了兩個惡意提交。攻擊者在上游提交了一個神秘的改動，稱其正在“修復排版”，假裝這是一個小的排版更正，并且偽造簽名，讓人以為這些提交是由已知的PHP開發者

119、和維護者RasmusLerdorf和NikitaPopov完成的。所以Git平臺的安全保護本身也是需要被提高重視的。代碼branch被篡改導致打包結果不一致：由于開源項目的Git倉庫是向所有人開放的，有些攻擊者會嘗試新建不同的branch植入代碼然后進行發布，雖然編譯過后的包帶有CI/CD平臺的簽名，但是仍舊會引發嚴重的安全隱患。早在2019年的DEFCON會議上，就有安全研究員就發現了WebMin的1.890在默認配置中存在了一個很嚴重的高危漏洞，1.882到1.921版本的WebMin會受到該漏洞影響。但奇怪的是，從GitHub上下載的版本卻未受到影響，影響范圍僅限于從SourceForg

120、e下載的特定版本的WebMin，后來經過調查后發現，是代碼倉庫沒有添加分支保護機制，從動導致出現問題，引發了此類的安全風險。運維/安全2022年美團技術年貨2.3過維護期的組件在實際的生產環境中，有很多的開發者使用的運行時版本、組件版本以及CI/CD平臺版本都是已經很久未更新的。當然，站在安全的角度上講，安全團隊希望所有的系統都用上最新版本的組件和中間件，但是事實情況是，基于業務自身的規劃迭代，或者因為大版本改動較多容易引發兼容性問題，從而導致升級遷移成本過高等諸多原因，使得落地這件事情就變的不是那么容易。為了讓安全性和易用性達到平衡，很多企業內部往往會進行妥協，通過其他手段收斂攻擊面并且建立

121、旁路的感知體系，來保證安全問題，也可以及時發現和止損。但是長久看來，引入過時版本的組件會引發諸多的問題：維保問題：因為開源社區的人力和精力有限，往往只能維護幾個比較主要的版本（類似于操作系統中的LTS版本，即Long-TermSupport，長期支持版本是有社區的長期支持的，但是非LTS版本則沒有），所以一旦使用過時很久的版本，在安全更新這一部分就會出現嚴重的斷層現象。如果出現了高危漏洞，官方不維護，要么就是自己編寫補丁修復，要么就是升級版本，達到“長痛不如短痛”的效果，要么就是像一顆定時炸彈一樣放在那里不管不問，祈求攻擊者或者“藍軍”的運氣差一點。安全基線不完整：隨著信息安全技術的發展和內生

122、安全的推動，版本越新的安全組件往往會SecureByDesign，讓研發安全的要求貫穿整個研發設計流程。但早期由于技術、思路、攻擊面的局限性，這一部分工作往往做了跟沒做一樣。感觸特別深的兩個例子，一個是前幾年APT組織利用的一個Office的0day漏洞，瞄準的是Office中一個年久失修的組件，這個組件可能根本連基本的GS（棧保護）、DEP（數據區不可執行）、ASLR（內存地址隨機化）等現代的代碼安全緩解機制都沒有應用。熟悉虛擬化漏洞挖掘的同學們可能知道，QEMU/KVM環境中比較大的一個攻擊面是QEMU模擬出來的驅動程序，因為QEMU/KVM模擬的驅動很多都是老舊版本，所以會存在很多現代化

123、的安全緩解技術沒有應用到這些驅動上面，從而引入了攻擊面。其實，在開源軟件的使用過程中也存在類似的情況，我們統稱為“使用不具備完整安全基線的開源軟件”。運維/安全2022年美團技術年貨重要且急迫的。追求“絕對安全”：有些業務同學也會直接問，到底該怎么做，才能安全地使用各種組件？話雖直接，但是能夠體現出背后的問題：安全的尺度和評價標準不夠透明。讓安全問題可量化，并且追求標準透明也是非常急迫的工作，考慮到這更像是運營層面的問題，在此也不展開敘述了。合規問題：很多業務因不了解開源協議，導致違反了開源協議的約束，引發了法務或者知識產權問題。從實際情況來看，業務同學并不排斥做安全工作，很多時候是因為缺乏一

124、個有效的機制，我們需要告訴他們引入的軟件依賴是否安全，需要完成那些操作和配置才能讓開源組件用起來更加安全。作為安全工程師，我們需要站在業務的視角去設身處地地想想，這些問題是不是真的不能夠被解決。由于業務和安全雙方都有關于組件安全相關的需求，恰好SCA這項技術可以很好地滿足業務和自身的需求，所以在整個SCA建設的過程中，我們需要不斷去挖掘這些需求。4.SCA 建設的過程其實，SCA并不是一項很先進的技術，只是在現代的研發過程中隨著流程的標準化、組件的豐富化、開源社區的活躍以及開發成本的降低等諸多原因，使得一個項目中純自己寫的代碼占整個項目中全部代碼的比例變得越來越低了。也就意味著供應鏈問題產生的

125、影響會越來越大，隨著DevSecOps的火爆，就重新帶火了SCA這一傳統的技術。根據很多企業內部的實踐，以及業界對于SCA技術的理解，我們認為SCA比較核心的功能主要包括以下幾點：軟件資產的透視：企業內部需要對所有的應用系統引用了哪些組件這件事情有著非常清晰的認知，在考慮盡量多的情況下，盡量覆蓋絕大多數的場景（業務應用系統、Hadoop作業等數據服務、Puppet等運維服務等），并且研究它們的開發流程，分析哪些階段可以引入SCA能力做風險發現。運維/安全2022年美團技術年貨息安全部門在現有的威脅情報經驗和數據上，對組件數據進行數據封裝和整合，建立一個單獨的開源組件風險數據庫，旨在收集來自于全

126、量互聯網上披露的風險，方便與后面的資產數據進行聯動。第二階段：SOP（StandardOperatingProcedure，標準運營流程）和概念驗證建設，信息安全團隊通過自己的漏洞修復經驗進行SOP的固化，通過不斷地調優，完成一個通用的漏洞修復SOP，通過實際的演練和概念驗證（PoC，即 Proof-of-Concept）證明，該SOP可以在現有的技術條件下很好地完成風險修復這一部分工作。同時結合SOP，對之前收集的資產數據和風險數據進行查漏補缺，完成對數據和數據鏈路的校驗工作，保證系統高可用。在這個階段，SCA的服務提供方需要開放部分的核心API給部分業務的質量效率團隊，幫助他們進行測試并收

127、集反饋，讓其融入到自己的風險治理環節。第三階段：平臺化及配套穩定工作的建設，當SOP初步成型并且完成了概念驗證之后，應當需要建設對應的平臺和子系統，讓這一部分工作脫離手動統計，使其接近100%線上化。得益于內部SOC的模塊化設計，可以在現有的平臺上輕松構建出SCA相關的子系統，完成能力的數據。針對終端用戶可視化風險這一問題，SCA子系統會提供核心的APIs給面向研發同學端的SOC平臺完成風險信息的同步。為了保證服務的高可用，后續還會建設配套的數據鏈路檢查機制，不斷完善數據的可用性。一些比較重要的工作如上圖所示。三個階段完成之后，SCA的能力大概就建設好了，但在建設過程中，安全團隊需要考慮很多東

128、西。如果說安全廠商的安全產品和服務可以被認為是問題解決的“分子”的話，甲方安全團隊的工作更多的是做大做全的“分運維/安全2022年美團技術年貨進行分析。離線引擎則是完成存量風險的周期性發現和治理工作。在討論完資產數據的采集之后，我們來談論風險數據的收集。早在威脅情報體系化建設階段，組件漏洞情報就作為基礎安全情報應用場景下漏洞情報的一個子集，一直存在。但由于之前局限于“漏洞=風險”的觀念，導致實際執行過程中只存放了組件漏洞相關的風險信息，在綜合評估完現有的需求和實際情況之后，我們發現當前組件漏洞數據，只能承擔一部分研發安全風險的治理工作。而像對于供應鏈投毒、開源組件基線情況等其他類型的風險數據，

129、由于當時還沒有數據能夠提供成熟的能力輸出給業務方使用，經歷過充分的討論和調研之后，決定將組件相關的漏洞數據獨立出來，并且新增采集供應鏈安全的其他風險數據，重新建立一個組件安全相關的數據庫，完成風險數據的存儲和應用。通過結合自身威脅情報的實踐，以及業界關于組件風險收集的最佳實踐，我們打算從5個維度對組件相關風險進行收集和存儲：NVD/CNVD/GitHub-GHSA等通用漏洞數據庫：這個是基本操作，旨在收集漏洞風險，結合漏洞實際情況進行人工和研判。Jira、Commit、Release和Bugzilia等Pull-Request相關的數據：通過獲取相關的數據，結合自研的NLP（NaturalLa

130、nguageProcess，自然語言分析）分析引擎對內容進行傾向性判斷，過濾并輸出安全相關的信息，然后組織人工或自動化研判，通過實踐，我們發現可以大幅度提前發現風險（筆者在ISC2019上曾經闡述過風險發現前置的必要性和落地經驗）。組件專用風險庫：經過我們對于漏洞數據相關的調研，諸如Github和Snyk這些機構會有專門的組件風險庫對外提供，通過獲取并分析這些信息，經過加工后可以得到可用性極高的組件風險庫，可按需研判。軟件風險相關的新聞資訊和RSS訂閱：這類源主要是解決0day和被APT組織在野利用等特殊披露的漏洞，同Pull-Request數據一樣，該類型的絕大部分風險數據都是需要通過NLP

131、分析引擎進行情報數據分析，進一步進行情感推斷后才達到可用的標準。運維/安全2022年美團技術年貨的基礎設施可以支持TB級別資產數據的檢索能力，返回時間不超過100毫秒；而在風險數據建設方面，目前覆蓋了共計10個技術棧（包含主流的Maven/Gradle、PyPi、NPM、SPM、APT/Yum、CocoaPods 在內）共計約59 萬條風險數據，更新周期在兩小時以內，通過計算引擎可以和資產數據進行快速匹配，節省了將近95%的排查時間，大大提升了運營效率。在匹配規則建設方面，因為數據來源較多且雜亂，我們通過自研的NLP分析引擎進行大規模的訓練和處理數據之后，可以統一到一個比較固定的數據結構里面，

132、在打標處理后可以實現和資產數據的高效聯動。鑒于NLP模型的訓練過程和訓練方法不屬于SCA建設過程中比較重要的技術，所以本文中不會展開敘述詳細的訓練過程和情感推斷訓練過程。除了資產信息關聯之外，風險數據庫可以同時實現對CVSS（即CommonVulnerabilityScoringSystem，即通用脆弱性評分系統）的匹配，及時推送滿足CVSS影響范圍（這里不是指CVSS分數，而是指CVSS的描述表達式）的漏洞信息，提醒安全運營的同學關注相關風險并及時進行研判。運維/安全2022年美團技術年貨漏洞-資產關聯規則缺乏一個成熟且有效的行業標準：在SCA領域，目前沒有一個成熟的可以匹敵NVD相關的生態

133、環境，在NVD體系下，有用來描述漏洞信息的CVE，有描述資產影響范圍的CPE（CommonProductEnumunation），有 描 述 攻 擊 路 徑 的CAPEC（CommonAttackPatternEnumerationandClassification），還有描述風險類型的CWE（CommonWeaknessEnumunation）。但是在組件安全領域，由于各家公司的基礎設施建設成熟度和技術選型差異巨大，所以沒有一個可用的完整生態可以做到“開箱即用”，所以我們需要基于現有的技術架構和基礎設施來設計自己的規則，同時推廣這套標準在安全運營工作中落地。數據質量與數據鏈路的可靠性：數據質

134、量和可用性問題是從立項開始一直到后期運營階段都會出現的問題，問題可能來自于上游采集邏輯不完備或采集錯誤，還有數據鏈路不穩定導致寫入計算引擎出現大批量丟失的問題，還有數據鏈路沒有檢查機制，導致不知道具體問題出在哪里，甚至由于使用的數據分析技術棧的原因，導致打過來的數據是錯亂的，錯亂的數據有可能會影響CEP規則的準確性和有效性。這當中的有些問題不是偶發的，甚至有些問題在真實應用的場景下會高頻出現，所以建立一個長效的數據撥測機制和數據污點追蹤能力是必要且必須的。風險數據的數據結構與準確度：由于在風險數據中引入了過多的來源，且大量引入了機器學習和NLP技術，將非結構化數據轉換成結構化數據，考慮到模型訓

135、練的精度、訓練樣本數據、訓練網絡等問題，導致平臺提取出來的漏洞信息很多時候會有一定的出入，并且由于風險情報數據比較依賴上下文和實效性，所以需要在各方面做取舍，這個問題其實和數據的問題一樣，不是一朝一夕能解決的，需要大量的實踐運營和撥測機制CasebyCase地去推動解決。CI/CD管制與非標準資產的治理：這一方面實際上與SCA落地的關系不是很大，但是提及的原因是SCA本身是一個需要強關聯研發流程的能力，好的SCA平臺除了可以提供標準化的APIs和GUI讓用戶快捷操作，同時也需要兼容非標準的發布流程和上線標準，這就是為什么除了主要的幾個技術運維/安全2022年美團技術年貨風險治理方面，也可以給大

136、家一個Cheatsheet做參考。當然，想要做到以上所有的項目，實際上對于企業的基礎架構和基礎設施都有一定的要求，但好在目前開源社區對于供應鏈安全治理提供了一些安全的解決方案，諸如國外由OpenSSF或者商業公司牽頭設計開發的一系列工具鏈，如ChainGuard.dev，SigStore，Anchore等等，當然國內也有很多優秀的開源解決方案?？梢栽谶M行一定修改之后，集成到現有的基礎架構中?？紤]到安全的對抗屬性在里面，SCA工具如果融合進企業內的研發流程中，必然會引發很多對抗SCA檢測的路子，況且在調研過程和實際處置過程中，繞過固有研發流程的情況是比較常見的，所以后續在繼續建設SCA能力的過程

137、中，我們會逐步加入對抗的檢測和加固，防止“漏網之魚”。7.結語以上是我們在整個SCA能力建設過程中積累的一些想法和實踐。在建設SCA能力的過程中，通過與各團隊的協同工作和溝通，了解了很多業務對于組件安全方面的想法和真實需求，通過需求得出需要建設的能力。在技術方案落地中，企業內部部署的很多安全產品，諸如HIDSAgent和RASP等，可以從主機的角度去反向驗證建設的過程是否正確。此外，SCA能力的落地離不開安全團隊與業務團隊的配合。實際上在SCA的建設過程中，我們如果再往更深層次去看，會發現諸如閉源軟件、開源軟件的跨架構、跨編譯器的識別、其他載體（比如容器鏡像、軟件成品）的安全分析等，這些技術挑

138、戰運維/安全2022年美團技術年貨9.參考文獻SoftwareCompositionAnalysis(SCA)reviewsReviewsandRatingsDeepdiveintoVisualStudioCodeextensionsecurityvulnerabilitiesThatTimeLinuxBannedtheUniversityofMinnesotaPHP sGitserverhackedtoaddbackdoorstoPHPsourcecodeWebminbackdoorblamedonsoftwaresupplychainbreachHighlyEvasiveAttackerL

139、everagesSolarWindsSupplyChaintoCompromiseMultipleGlobalVictimsWithSUNBURSTBackdoorOpenSourceSoftwareIsUnderAttack;NewEvent-StreamHackIsLatestProofStork:PackageManagementforDistributedVMEnvironmentsHelloopensourcesecurity!ManagingriskwithsoftwarecompositionanalysisIntroducingMicrosoftApplicationInspe

140、ctorCyberSupplyChainRiskManagementTHESOFTWAREBILLOFMATERIALSANDITSROLEINCYBERSECURITYCybersecuritySupplyChainRiskManagementC-SCRMIntroducingtheOpenSourceInsightsProjectAnnouncingaunifiedvulnerabilityschemaforopensourceGooglestakesnewSecureOpenSourcerewardsprogramfordeveloperswith$1MseedmoneyIntroduc

141、ingSLSA,anEnd-to-EndFrameworkforSupplyChainIntegrityBinaryAuthorizationforBorg:howGoogleverifiescodeprovenanceandimplementscodeidentityAKubernetesCI/CDPipelinewithAsyloasaTrustedExecutionEnvironmentAbstractionFrameworkAllStar:ContinuousSecurityPolicyEnforcementforGitHubProjectsGoogleopen-sourcesAlls

142、tar,atooltoprotectGitHubreposMeasuringSecurityRisksinOpenSourceSoftware:ScorecardsLaunchesV22022OPENSOURCESECURITYANDRISKANALYSISREPORTFocusontheStabilityofLargeSystems:TowardAutomaticPredictionandAnalysisofVulnerabilityThreatIntelligenceOpenSourceSecurityExplainedCycloneDXSpecification4KeySigstoreT

143、akeaways:RecapofTwitterSpacewithKelseyHightowerSLSAvs.SoftwareSupplyChainAttacksTheStateofOpenSourceVulnerabilities2021GitHub2020DigitalInsightReport2020StateoftheSoftwareSupplyChainMakingSenseofUnstructuredIntelligenceDataUsingNLPOpenSCA-CliMurphySecCodeScanMethodandsystemformonitoringasoftwarearti

144、fact運維/安全157MethodandsystemformonitoringmetadatarelatedtosoftwareartifactsMethodandsystemforevaluatingasoftwareartifactbasedonissuetrackingandsourcecontrolinformationsigstore-Anon-profit,publicgoodsoftwaresigning&transparencyservice10.團隊招聘美團信息安全部，肩負統籌與負責美團線上安全與平臺治理的重要職責。隨著業務升級與拓展，我們擁有諸多全球化安全與風控領域人才、依托前瞻的安全技術視野、創新的機器學習技術、領先的產品運營體系，構建全方位、多維度的智能防御體系，為美團業務生態鏈上億萬 C端、B 端用戶的安全提供有力保障。我們致力于建設業界卓越的安全團隊，落地更多業界認可的實踐，同時助力業務奔跑。期待你的加入，讓我們奔赴熱愛，無畏山海，共筑安全長城。目前團隊多個崗位熱招中，點擊了解詳情：安全團隊春季熱招崗位 vol.1、安全團隊春季熱招崗位vol.2，歡迎大家積極投遞簡歷。