產業脈動 2026 年 5 月 23 日

2026-05-23 — Discord ScyllaDB 自動化 36h→2h、WordPress 7.0 AI 連接器、Slack EMR SSH→REST

primary=https://discord.com/blog/how-discord-automates-scylladb-clusters-at-scale primary=https://wordpress.org/download/releases/7-0/ primary=https://slack.engineering/from-ssh-to-rest-a-security-driven-modernization-of-slacks-emr-data-pipelines/

Discord ScyllaDB 叢集自動化:7 名工程師管理數百個節點,部署時間從 36 小時縮至 2 小時

discord.com · 2026-05-22

Discord 的 Persistence Infrastructure 團隊僅有 7 名工程師,卻需管理跨多個可用區的數十個 ScyllaDB 叢集與數百個節點。叢集擴容、OS 升級、版本驗證等操作原本需要工程師持續監控長達 36 小時以上;2026 年團隊開源了內部工具 Scylla Control Plane(SCP),將這些操作的人工參與時間壓縮至 2 小時內的例外處理。

SCP 三層架構

SCP 建立在三個概念層次之上:

  • Task:最小工作單元,對應節點或叢集層級的單一操作(如「滾動重啟」)。Task 必須定義前置條件(precondition)並實現冪等性——執行兩次與執行一次的結果相同。
  • Workflow:以 YAML 定義的 Task 有序序列,可配置 retry 次數、並行度限制等參數;操作員可在不重新編譯的情況下調整這些參數。
  • Job:將 Workflow 綁定至特定叢集的一次執行,狀態持久化至 SQLite,允許中斷後從斷點續跑。

並行控制與可用區安全

concurrency_unit 參數以可用區(zone)為批次單位控制並行,確保不同 zone 的節點不會同時重啟,保留 ScyllaDB 的高可用性。concurrency_limit 限制同時處理的批次數量。Task 透過 API 輪詢等待叢集達到預期狀態(如節點啟動完成並加入 ring)才繼續下一步,而非依賴固定的 sleep 時間。

錯誤分類與告警

SCP 區分兩類錯誤:可恢復錯誤(自動 retry,例如暫時性的 API 不可用)與不可恢復錯誤(立即停止並透過 webhook 告警,例如節點無法加入叢集)。這讓工程師得以在接到告警時才介入,而非在整個操作過程中全程待命。大部分等待時間為被動的節點啟動(bootstrapping),不需要工程師注意力。

原始來源:Discord Engineering Blog


WordPress 7.0:AI 供應商連接器框架、導覽覆疊設計器與視覺修訂時間軸

wordpress.org · 2026-05-19

WordPress 7.0 於 2026 年 5 月 19 日正式發佈。這個版本的核心主題是平台化 AI 整合——引入標準化的 Connectors 框架讓任何外掛皆可接入外部 AI 供應商,同時大幅改善內容建立流程中的幾個長期痛點。

AI Connectors 框架

新的 Connectors 畫面提供單一入口管理所有外部服務整合,包括 AI 供應商。使用者選擇接入的供應商後,可選 AI 外掛(optional AI plugin)隨即解鎖編輯器內的工具:生成標題與摘要、生成和編輯圖片、建議 alt text。任何需要連接外部服務的外掛都可透過相同的 Connectors API 進行認證管理,避免各外掛各自實現憑證存儲的分散問題。

導覽覆疊設計器

WordPress 7.0 新增專屬的導覽覆疊(navigation overlay)設計畫布。開發者和網站管理員可從預建範本出發,或完全從頭設計:支援多欄版面、字體大小調整、對齊控制。整體行為類似 block 群組,但套用了主題的全站設定。

Pattern 作為單一 Block

過去在頁面上放置 Pattern 後,其內部是一組巢狀 block,需要逐層展開才能找到要編輯的元素。WordPress 7.0 讓插入的 Pattern 表現為單一 block,從 inspector 可直接調整文字、圖片與樣式,而不需要進入巢狀 block 層次。

視覺修訂時間軸

修訂歷史現在以時間軸滑桿呈現,可拖曳到任一版本時間點,並在文件上看到 block 層級的變更標記(新增、刪除、修改分色顯示)。找到目標版本後一鍵還原。這個功能填補了 WordPress 長期以來只有文字差異比對而無視覺比對的缺口。

原始來源:WordPress 7.0 Release Notes


Slack EMR 資料管道現代化:700 個 SSH 操作者替換為 REST 閘道,歷時三季

slack.engineering · 2026-05-05

Slack 資料平台在 2024 年累積了超過 700 個基於 SSH 的 Airflow 操作者,分佈於 8 個資料地區,負責在 EMR(Elastic MapReduce)叢集上執行 Spark 任務。SSH 連線的無狀態特性在 Kubernetes 環境下引發了一系列故障,最終 Slack 以 Quarry 內部 REST 閘道取代整個 SSH 層,歷時三季完成遷移。

SSH 模型的失效場景

SSH 連線在 Kubernetes pod 重啟時斷開,導致任務失敗或變為孤立程序(仍在跑但 Airflow 已無法追蹤狀態)。長時間任務的成敗判斷失去可靠性,運維團隊需要手動登入 EMR 節點確認。SSH 操作者的任務直接在 EMR master node 執行,彼此競爭資源而非使用 YARN 的容器隔離機制。安全層面,SSH 金鑰分散在所有 Airflow worker 上,輪換代價高,審計日誌分散在多個系統。

Quarry 閘道與 YARN Distributed Shell

Quarry 是 Slack 的內部 REST 服務,負責認證(service-to-service token 取代 SSH key)、任務提交(呼叫 YARN REST API)、狀態追蹤(server-side 監控)。關鍵突破是利用 YARN Distributed Shell:將腳本上傳至 S3 後,透過 YARN 標準 REST API 提交,YARN 負責資源限制(vCores、記憶體)、容器隔離、重試與容錯。API 互動模式為 POST 取得任務 ID → GET 輪詢狀態 → DELETE 取消,任務在 server-side 持久執行,不受 client 連線狀態影響。

遷移過程

遷移分五個階段歷時三季:POC 驗證 → 資安審查 → OKR 驅動執行(達到 80% 遷移里程碑)→ 跨團隊批量遷移(5 個團隊、8 個地區)→ SSH 操作者棄用。其中最大的技術障礙是虛擬記憶體強制執行(SSH 模式繞過了 YARN 記憶體限制,遷移後部分任務因超限被殺死)以及各地區網路隔離的差異。

原始來源:Slack Engineering Blog


End of article
0
Would love your thoughts, please comment.x
()
x