自動治療和自我恢復系統

1）什麼是自動保健,為什麼需要它

自動治療是在沒有人為幹擾的情況下自動穩定服務,其癥狀恢復（SLO）優先於根本原因搜索（RCA）。
目標：降低MTTR，保護預算錯誤，降低運營成本和人為錯誤。

• 細節（度量/logi/合成/事件）。
• 解決方案（規則/政策/ML啟發式方法）。
• 行動（重新開始/滑行/shedding/ficheflag/rollback/failover）。
• 驗證（SLO綠色到給定的窗口）。
• 退化時取消（revert）。

2）自動治療機制圖

在應用程序級別：idempotency, timeouts, retry+ backoff+jitter,電路斷路器,bulkhead,緩存降解（graceful）。

Kubernetes: liveness/readiness/startup probes, restartPolicy, PDB, HPA/VPA, Descheduler, Pod/Node auto-remediation.

網絡/edge： rate limits, per tenant配額,connection draining, fail-open/close, WAF規則。
隊列/流媒體：消費者-autoscale,基於lag的背景,DLQ/parking lot。

存儲庫/DB： 復制件,自動修理（rebuild）, throttled autovacuum, connection pool rebalancing.

CI/CD：金絲雀布局，漸進式交付，自動回滾。
事件編排：控制器/操作員，帶有返回策略的工作流引擎（Argo，Airflow）。
看門狗/Heartbeats：Dead Man's Switch for fend job。

3）安全自我恢復設計原則

1.SLO-driven：所有自動操作都是根據與用戶體驗相關的癥狀觸發的。
2.金絲雀第一：首先是局部/點點，然後是全局。
3.一路門護欄：回滾計時器/條件，風險操作的「雙鑰匙」。
4.Idempotency：每個動作（重新啟動、遷移、旋轉）在重復時都是安全的。
5.Observability-by-design：活動標簽，與軌道的相關性，「誰/什麼/時間/為什麼」日誌。
6.Least privilege：自動化具有最低限度的權利（RBAC, scoped secrets）。
7.成本獎勵：「昂貴」動作（縮放，egress，snepshots）的限制。

4）細節： 觸發自動治療的信號

Метрики: 5xx%, p95/p99 latency, Kafka lag, DB lock/lag, node pressure.

合成：藥房下降/路徑倒退（登錄/存款）。
Logs：新錯誤簽名,異常頻率。

События K8s: CrashLoopBackOff, NodeNotReady, FailedScheduling.

心跳：joba的沈默>N分鐘。

promql
API error regression sum (rate (http_requests_total{status=~"5"..}[5m]) )/sum (rate (http_requests_total[5m]))> 0. 01

Kafka: lag> threshold max by (topic, group) (kafka_consumergroup_lag)> 10000

K8s: pod в CrashLoopBackOff increase(kube_pod_container_status_restarts_total[5m]) > 3

5）自動恢復操作（劇本目錄）

5.1應用/網絡

在後端異常情況下,電路斷路器ON →快速失誤+緩存/答案。
Retry+ backoff+ jitter帶有極限和重印。
Rate limit/shed-load：過載時-優先考慮關鍵路徑。

5.2 Kubernetes

重新啟動容器（liveness）並刪除不健康的腳趾上的腳趾。
HPA/VPA：RPS/CPU/latency/lag自動滑行；VPA-僅推薦或超時應用。
Nod自動還原：在持久性問題（taints）下的cordon+drain。
Affinity/Topology spread防護AZ假。

5.3個隊列/流媒體

Auto-scale consumers по lag;暫時減少生產者。
有毒信息的DLQ；從存檔中復制。

5.4 DB/緩存

帶有狀態/配置檢查的副本失敗。
連接池在「泄漏」連接時重置。
帶有自動客戶回收功能的熱備用促銷。

5.5 CI/CD

在金絲雀交通中以5xx/p95的身高自動回滾。
Feature-flags：自動關閉問題仙女而不是全局回滾。

6）漸進式交付和自動翻滾

示例（Argo Rollouts金絲雀策略）

yaml strategy:
canary:
canaryService: api-canary stableService: api-stable steps:
- setWeight: 10
- pause: {duration: 5m}
- analysis:
templates:
- templateName: api-slo-check
- setWeight: 25
- pause: {duration: 10m}
- analysis:
templates:
- templateName: api-slo-check

如果分析模式返回「失敗」（超出錯誤/潛伏）,則滾動會自動回滾。

7） Ficha標誌作為自我恢復工具

Kill-switch用於問題場景（服務器側）。
定向：在細分/區域上關閉線程。
自動規則：如果5xx%來自fici> X在Y分鐘內是OFF並在backlog中滴答作響。
驗證：具有預算的SLO面板照片。

8）超負荷： 如何不把自己「治愈」致死

Shed-load：拒絕/降級QoS非關鍵請求（票價、重型報告）。
Token-bucket/leaky-bucket和tenant/key配額。
Adaptive concurrency （在代理/SDK級別）-在潛伏期增長時降低並發性。
Bulkhead：隔離流/連接池。

9）一致性和相容性

等效密鑰（request_id）→重復保護。
擔心交易（付款，註銷）-雙階段流程，確認/補償（saga）。

Outbox/Inbox и exactly-once через idempotency storage.

10）安全和合規性

自動化的最低RBAC（僅限所需資源）。
審核所有活動：誰/何時/什麼信號/什麼效果。
手動覆蓋和「紅色按鈕」以禁用自動操作。
法律保留事件文物和自動日誌。
秘密-通過秘密管理器，在自我協助下旋轉鑰匙。

11） FinOps： 「自我實現」的價格"

最大自動軌道的限制不會在激增時崩潰。
每項行動成本指標：1個重啟、1個復制品、1 TB egress的成本。

聚合： cost per SLO-minute saved, cost per mitigated incident.

「夜間模式」政策：如果業務流量低，自動化的侵略性會降低。

12）自動可觀察性

圖上的標簽是：'remediation_action='rollback'，'source='argo'，'reason='slo_burn'。
單獨的dashbod：自動輔助頻率，成功，median恢復時間，滾回率。
相關性「SLo →作用」以評估收益。

13）Configi和示例

13.1 K8s：提問和重啟政策

yaml livenessProbe:
httpGet: { path: /healthz, port: 8080 }
initialDelaySeconds: 20 periodSeconds: 10 timeoutSeconds: 2 readinessProbe:
httpGet: { path: /readyz, port: 8080 }
periodSeconds: 5 failureThreshold: 3 startupProbe:
httpGet: { path: /startupz, port: 8080 }
failureThreshold: 30 periodSeconds: 5

13.2警告→自動動作（偽）

yaml rule: api_5xx_rate_high action:
type: feature_flag target: "payments. new_flow"
set: false guardrails:
cooldown: 10m max_actions_per_hour: 2 rollback_if:
- condition: "5xx% not reduced within 5m"

13.3 Kafka lag autoscale（定制度度HPA）

yaml metrics:
- type: Pods pods:
metric:
name: kafka_consumer_lag target:
type: AverageValue averageValue: "500"

14）自動保健測試（混沌和遊戲日）

混沌註入：網絡暫停，pod/nod殺死，DB/緩存降級。
Game days：具有超時限制和MTTR指標的腳本練習。
影子交通：向金絲雀出租交通，不影響用戶。
Dry-run自動化模式（寫作但不寫）。

15）「自動恢復準備」標準"

• SLO是定義的，度量是穩定的，有合成。
• 樣品/healthz,/readyz,/startupz正確反映狀態。
• 相同性和雙倍保護（特別是在付款方面）。
• Ficha標誌和金絲雀布局可用。
• Guardrails： cooldown, rate-limit操作,高風險操作的雙鍵。
• Dashbord自動化和審核日誌。
• 「手動超速」計劃和runbooks以防堵塞。

16）按階段實施（4次叠代）

1.基數：定義SLO,添加probes,包括重新開始/基本的異常。
2.本地動作：ficheflag-kill-switch，lag滑板消費者，自動翻滾金絲雀。
3.Infra Level： node remediation, failover DB/cache,負載推送。
4.優化：guardrails，FinOps限制，混沌測試，用於檢測的ML啟發式。

17）頻繁的錯誤和反模式

將原因治療為癥狀→長MTTR。
沒有金絲雀階段的全球行動。
沒有回滾或取消標準。
假健康支票（成癮破裂時為200）。
沒有限制/成本門檻的汽車軌道「膨脹」。
盲目後退風暴,沒有後退和重復數據消除。

18）迷你常見問題

ML是否需要自動轉彎?

沒有。從SLO/度量標準和 guardrails規則開始；ML對於異常和謂詞很有用。

為什麼不總是重新啟動有助於?

如果根依賴性（DB、緩存、網絡），重啟只會加劇風暴。需要breaker/shedding/failover。

如何證明好處？
比較MTTR和有缺陷的預算消費前後。添加cost per mitigation度量。

底線

自動治療是系統而不是「重新啟動拐杖」集合：SLO探頭→安全的點動作→驗證→退縮。結合probes，金絲雀布局，幻燈片，滑板，shedding，failovers和嚴格的護衛，您可以減少MTTR，保持預算錯誤並控制成本。