從 Chef 巡檢到不可變映像:Slack 用 Shipyard 重造 EC2 部署平台
Slack Engineering · 2026-07-14
原本的問題
Slack 過去的 EC2 部署仰賴排程執行的 Chef 巡檢任務,持續檢查並重新套用長效實例上的組態。這套「持續配置管理」模式會定期修正任何組態飄移,但也意味著實例背景中不斷有變更在發生。工程團隊在文章中直言,即使加上更安全的滾動部署、更好的編排與更強的防護機制,持續更新長效 EC2 實例這個模型本身已經觸頂——飄移難以預測、跨層級的服務部署難以協調、系統行為也越來越難推理。
採用的方法與核心元件
Shipyard 的核心思路,是把基礎設施視為「可部署的產物」,而非「可無限變動的實例」,概念上類似容器映像分層。名為 slack-zero 的黃金基礎映像由 Compute Platform 團隊維護,內含作業系統基線、安全加固、網路與監控代理,以 AWS Image Builder(取代原本的 Packer)建置,並透過 SSM Parameter Store 發布最新 AMI ID,再由 EventBridge 與 Lambda 觸發下游服務映像的自動重建。服務團隊則在此基礎上疊加自家軟體與初始化邏輯,支援 AMD64 與 ARM Graviton 雙架構。
組態套用被切分為兩個階段:bake 階段在建置映像時完成套件安裝與環境一致的設定,provisioning 階段則只在開機時套用少量環境專屬設定(如密鑰、地區參數)。整個系統圍繞以下幾個內部元件運作:
- Gondola——部署編排器,將 AMI 與版本化的 Chef recipe 組裝為部署產物,支援 ASG 更新、Kubernetes(搭配 Karpenter)及自訂執行器,並具備指標驅動的漸進式發布與自動回滾
- Peekaboo——建立在 EventBridge、OpenSearch 與 Lambda 之上的庫存系統,取代 Chef Server 成為 EC2 艦隊的即時真實來源
- The Reaper——生命週期管理器,依外部訊號(安全工具、AWS 事件)標記「已污染」實例,並依服務策略排程汰換,內建依服務/區域/可用區分流的速率限制,以及可透過 S3 控制物件觸發的全域暫停「大紅按鈕」
- Consul Template——不可變原則下的例外,負責在不重建艦隊的情況下,持續從 Vault 更新密鑰與憑證
- Ship Quick——開發者用來在合併前測試 cookbook 變更的工作流,將變更打包上傳 S3 並交由獨立的 Longshoremen 工作實例執行、串流日誌
實際效果
由於絕大多數組態已在映像建置階段完成,實例開機時間從原本的分鐘級縮短到秒級。責任模型也因此重新劃分:平台團隊負責維護 slack-zero 基礎層與安全更新,服務團隊只需將最新基礎層併入自己的映像,即可自動獲得下游的安全修補與改進。目前 Slack 仍在將既有團隊由舊平台遷移至 Shipyard,下一階段的挑戰集中在資料節點、單例服務與 Atlassian JIRA 等第三方系統之類的長效實例——這些實例無法快速汰換,平台團隊正與各服務團隊合作,為 Gondola 開發能安全更新此類實例的新執行器。
從卡在舊核心到重回主線:Meta 用開源排程框架 sched_ext 重寫廣告服務的排程策略
Meta Engineering · 2026-07-13
原本的問題
Meta 廣告服務的伺服器艦隊平均每秒處理超過 500 萬次請求,對延遲極為敏感。當 Linux 核心從 v6.4 升級到 v6.9 時,新引入的 EEVDF(Earliest Eligible Virtual Deadline First)排程器造成廣告服務出現延遲退化。為了避免影響服務,團隊被迫讓部分廣告主機停留在舊版 v6.4 核心上,這造成了技術債與艦隊組態的長期分裂——既無法享受新核心的其他改進,也難以長期維護雙版本並行。
採用的方法與機制
sched_ext 是上游 Linux 核心中以 BPF 為基礎的可擴充排程框架,已於 v6.12 正式併入主線核心。Meta 與 Google ghOSt 專案的作者合作,共同設計出一套適合上游整合的排程器。他們針對廣告服務設計的自訂排程策略,會把 CPU「軟分割」成兩個資源池,分別容納延遲敏感的請求路徑執行緒與其餘較不敏感的工作負載,並依負載狀況以啟發式規則動態調整兩個池的大小,藉此維持執行緒的親和性,提升 L3 快取命中率並降低成本高昂的 DRAM 存取。
這套策略透過喚醒(wake-up)、進入佇列(enqueue)、派發(dispatch)、閒置轉換等事件驅動的回呼運作。整個排程策略以使用者空間的執行檔載入 BPF 程式來實作,這讓團隊得以快速反覆實驗新策略,而不必每次都重新編譯、部署核心。
實際效果
初期上線後,團隊觀察到多項指標同步改善,後續優化又帶來更進一步的延遲下降:
| 階段 | p99 延遲變化 | 其他指標 |
|---|---|---|
| 初次上線 | 降低 28% | 節省 3.28 百萬瓦電力;加權廣告排序指標提升 1.1% |
| 後續優化 | 再降低 60% | 逾時錯誤減少 18% |
這些改善讓原本因排程退化而滯留在 v6.4 的主機得以隨艦隊一同升級到新核心,同時不必在延遲與核心版本之間妥協。
一次金鑰交接失誤讓 .AL 網域集體斷線,Cloudflare 用新錯誤碼 EDE 33 讓「驗證繞過」不再隱形
Cloudflare Blog · 2026-07-14
事件經過
2026 年 7 月 3 日,阿爾巴尼亞通訊管理局(AKEP)在為 .AL 頂級網域執行 DNSSEC 金鑰交接時操作失序,導致所有 .AL 網域在支援 DNSSEC 驗證的解析器上一度無法解析。時間軸如下:
- 約 14:15 UTC:AKEP 發布新的 DNSKEY 並停用舊金鑰,但根區的 DS 紀錄仍指向舊金鑰(id=26319),導致驗證全面失敗
- 約 17:00 UTC:AKEP 移除新 DNSKEY 卻未恢復原金鑰,此時
.AL區域完全沒有 DNSKEY,根區 DS 紀錄卻仍指向 id=26319 - 17:15 UTC:Cloudflare 為
.AL在 1.1.1.1 全部基礎設施上部署 Negative Trust Anchor(NTA) - 約 19:15 UTC:AKEP 從根區移除 DS 紀錄,
.AL轉為未簽署狀態,解析得以恢復 - 7 月 4 日:根區修復後,Cloudflare 移除該 NTA
根本原因:NTA 與 EDE 機制
問題根源在於金鑰交接順序錯誤——操作方在更新根區對應的 DS 紀錄前就先替換了 DNSKEY,造成「信任鏈」斷裂:驗證端在 .AL 區域中找不到與根區 DS 指紋相符的 DNSKEY,因而拒絕所有回應,後續依序移除新金鑰與 DS 紀錄的操作又進一步拉長了中斷時間。Negative Trust Anchor 依 RFC 7646 定義,是一種指示解析器將指定區域視為未簽署、暫時繞過 DNSSEC 驗證以恢復可連線性的機制,但其代價是該區域在停用期間會暴露於 DNS 詐騙風險之下。
為了讓這種「繞過驗證」的狀態對外可見,Cloudflare 依 RFC 8914 定義的 Extended DNS Errors(EDE) 機制,在回應中加註新的 EDE 33 錯誤碼,語意為「已對此查詢套用 Negative Trust Anchor(見 RFC 7646)」。與此同時,EDE 9(DNSKEY 缺失)也被用來標示驗證失敗的直接原因;文章特別提到,這次事件中回報的 EDE 9 修正了先前 .DE 事件中錯誤回報的 EDE 22。
修補與偵測方式
在部署 NTA 之前,Cloudflare 曾嘗試直接聯繫網域操作方,並在 DNS-OARC 的 Mattermost 上公開示警,但均未獲得回應,最終在事件發生約三小時後才對 1.1.1.1 全球所有使用者部署 NTA。修復後的查詢結果會如下呈現 EDE 33:
$ kdig @1.1.1.1 google.al
;; Status: NOERROR
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'
;; ANSWER SECTION:
;; google.al. 300 IN A 142.251.142.196如今只要 1.1.1.1 在啟用中的 NTA 下提供回應,都會一律附上 EDE 33,讓操作方與監控工具能直接從回應本身得知驗證已被繞過,不必再查詢額外的狀態頁面。提出這項機制的 IETF 網際網路草案已取得 IANA 編碼分配,目前正由 IETF DNSOP 工作組審查,預計於 7 月 18 日至 24 日的維也納會議上討論。
原始來源:Cloudflare Blog