Srenix – 30MB二進位制檔案中的自愈型Kubernetes（Apache-2.0）
Srenix 是一個開源的 Kubernetes 自愈工具，僅包含一個約 30MB 的 Go 二進位制檔案，能夠自動檢測、診斷並修復叢集問題，無需依賴大語言模型 (LLM)。它提供 16 個 Kubernetes 探測、14 個只讀分析器、30 個雲探測（AWS/GCP/Azure）和 5 個策略受限的修復器，所有修復操作都會重新驗證，並可整合 Slack、Alertmanager 等通知。支援離線快照模式和叢集內執行，保證 GitOps 相容，適用於值班工程師減少手動排查工作量。
Srenix 是一個新型的開源工具，旨在為 Kubernetes 叢集提供自動化的自愈能力。整個工具打包成一個約 30MB 的 Go 二進位制檔案，基於 Apache-2.0 許可證釋出。它的設計初衷是解決運維人員常見的痛點：凌晨三點被告警吵醒，然後花二十分鐘手動排查日誌，最後發現原因往往很簡單（比如過期的 Secret 金鑰、卡住的 ExternalSecret 或者未更新的證書）。Srenix 的目標是以確定性的方式自動完成這些排查工作，並提供可信賴的自動修復能力。
Srenix 的核心架構分為三個層次：檢測、診斷和修復。它內建了 16 個 Kubernetes 探測器和 30 個雲平臺探測器（覆蓋 AWS、GCP 和 Azure），能夠全面監控叢集和雲資源的狀態。14 個只讀分析器負責分析探測結果，定位根本原因並給出修復提示。當問題被識別且符合預設策略時，5 個策略受限的修復器會自動執行修復操作；否則，它會向人工提供精確的修復建議。所有自動修復都會重新驗證效果，並透過 Slack、Alertmanager 或 OpenProject 等渠道傳送報告。
為了確保安全性，Srenix 的熱路徑完全脫離大語言模型 (LLM)，採用純 Go 實現，保證相同輸入產生相同輸出。修復器僅處理預定義的安全模式（如過期的 Error Pod、重新命名 Secret 鍵導致的卡住 Job、過時的 ReplicaSet Pod 等），不會自動修改 Secrets、ConfigMaps 或通用 CRD。此外，它具備 GitOps 意識，會跳過由 Argo/Flux/Helm 管理的資源，避免與宣告式配置衝突。
Srenix 提供兩種執行模式：離線快照模式和叢集內即時模式。離線模式無需安裝或 RBAC 許可權，只需提供一個透過 kubectl get ... -o json 捕獲的叢集快照即可進行診斷。即時模式則透過 Helm Chart 安裝為 CronJob，使用兩個許可權範圍明確的 ClusterRole，並支援可選的 Operator (AgenticSRE CRD) 進行部署管理。
該專案目前包含 138 個釋出版本，最新版本為 agentic-sre-0.1.0-alpha.1。除了開源版本，Srenix 還提供企業版，增加基於 LLM 的 Investigator 和更高階的自動規劃功能，但所有核心功能在開源版本中均可正常使用。
Srenix 的建立者 Salil 表示，這個專案源於他個人的值班經歷，希望提供一個值得信任的、可無人值守的故障排除工具。社群可以透過 GitHub Discussions 進行交流，專案也歡迎貢獻。