自动治疗和自我恢复系统

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，保持预算错误并控制成本。