自动治疗和自我修复

（部分： 技术和基础设施）

简短摘要

自动治疗不是"Kubernetes魔术"，而是一组学科：正确的采样和限制，受控的猎物，有故障的实例隔离，SLO自动化以及按键/机器人操作的runabook操作。目标是减少MTTR而不发生"雪球"过载，并保持p95/p99，付款和TTW甚至达到顶峰。

1）自我修复原则

1.Fail-fast&isolate：快速识别和隔离不良的病例/实例。
2.Backoff+Jitter：任何转发/滑行-具有指数延迟和抖动。
3.SLO-aware：自动化在快速燃烧的错误预算中打开或放大。
4.Idempotency：重复操作是安全的（尤其是付款/队列）。
5.深层防御：样本，配额，限制，巡回决胜局，断路器喷射，限度，降级模式。

2） Basis in Kubernetes

2.1样本：liveness/readiness/startup

startupProbe可防止过早重启重型服务。
readinessProbe定义了流量准备（加热缓存/连接）。
livenessProbe将重新启动"挂起"进程。

yaml readinessProbe:
httpGet: { path: /health/ready, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 3

livenessProbe:
httpGet: { path: /health/live, port: 8080 }
initialDelaySeconds: 20 periodSeconds: 10 failureThreshold: 3

startupProbe:
httpGet: { path: /health/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 30

2.2限额、PDB和优先事项

requests/limits不包括"噪音邻居"。
PodDisruptionBudget （PDB）可防止所有垫子同时下降。

yaml apiVersion: policy/v1 kind: PodDisruptionBudget spec:
minAvailable: 2 selector: { matchLabels: { app: payments-api } }

PriorityClass用于关键路径（payments, gateway）。

2.3重新启动和放弃策略

"maxUnavailable： 0"用于关键服务；rollingUpdate小步。
PodAntiAffinity在底部/区域中分配底部。

3）自动滑行和事件缩放

HPA （CPU/自定义指标）

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
minReplicas: 3 maxReplicas: 30 metrics:
- type: Resource resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }
- type: Pods pods:
metric:
name: http_requests_per_second target:
type: AverageValue averageValue: "50"

VPA

用于背景操作员/批处理任务；在prod-API中-小心（重新启动）。

KEDA（队列/外部事件）

Kafka lag，RabbitMQ，Redis，Prometheus查询的触发器-当工作积累时，会增加消费者。

4）网络保护： 巡回赛决胜局和选择"坏"

Envoy/Istio outlier detection (идея)

yaml outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

电路断路器限制同时查询/连接，以免破坏依赖性。

Rate limiting

限制输入呼叫/PSP路线/游戏提供商,以免中断浪潮加剧事故。

5）Retrai，taymauts和backoff with jitter

规则：首先是定时器，然后是转发，总是带有抖动和尝试限制。

python def backoff(attempt, base=0. 1, cap=2. 0):
import random, math sleep = min(cap, base (2 attempt))
jitter = random. uniform(0, sleep 0. 4)
return sleep + jitter

对于支付-等效密钥+重复数据消除。
对于队列-死信和延迟的重试。

6）在队列/流媒体中自我修复

DLQ+成长；孤立的重新处理。
Lag Control：自动滑板消费者（KEDA），制作人的背景。
Exactly once/at least-once-有意识地选择；手术是偶然的。

7）缓存和扭曲

用于安全残疾/回滚的测试密钥（"v2："）。
DB/PSP连接的温暖池；在切换前加热（蓝绿色/金丝雀）。
Stale-wile-revalidate，以减少对DB的"寒冷"打击。

8）基于SLO的自动重制（信号操作）

• Stop canary / rollback при fast-burn.
• "queue_lag_seconds"生长时的规模化制造者。
• 启用degrade模式（简化UX,禁用重型幻灯片）。
• 在timeouts spike中切换PSP路线。
• 激活feature-flag kill-switch。

yaml alert: WithdrawalsQueueLag labels: { action: "scale_workers", target: "withdrawals-consumers", by: "+5" }

9）降解模式（graceful degradation）

简化UI（少查询）,关闭"昂贵"小部件。
更多缓存，更少的风扇输出/aggregation。
对于LLM/建议,减少上下文/模型大小,启用"快速路径"。

10）GitOps自动制造方法

所有自动还原策略和参数（时间限制，阈值）均在Git中。
任何自动操作都会在Grafana中创建注释,并在更改日志中写入。
金丝雀策略和SLO门也是代码。

11）混沌工程： 我们检查治疗是否有效

注射故障：网络延迟，下降POD，PSP仿真器故障，排队。
游戏日场景：我们测量MTTR、自动动作质量、人工制品存在。
结果→更新符文，阈值，ficheflags。

12）自动治疗的可观察性

Exemplars：从p95度量快速跳到赛道。
带有"trace_id"和字段"retry"，"attempt"，"degrade_mode=true"的逻辑。
Dashbords release compare （stable vs canary）, SLO卡。
自动操作审核：谁/什么/何时,原始指标,结果。

13）安全性和合规性

自动还原的逻辑/度量中没有秘密。
对于付款行动-双重确认/角色。
Geo/PII-不要将流量带到failover下的"错误"区域。

14）实用模板

Istio DestinationRule — connection pool & outlier

yaml trafficPolicy:
connectionPool:
http: { http1MaxPendingRequests: 1000, maxRequestsPerConnection: 100 }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

Flagger-金丝雀与汽车废物/回滚

yaml analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke

KEDA ScaledObject — Kafka lag

yaml triggers:
- type: kafka metadata:
topic: withdrawals bootstrapServers: broker:9092 consumerGroup: w-consumers lagThreshold: "5000"

15）实施支票

1.定制startup/readiness/liveness和健康端点。
2.限制/资源请求+PDB/反关联。
3.API和Workers的HPA/KEDA；lag/throughput度量。

4.Circuit breaker, outlier ejection, rate-limit in gate/mesh.

5.带有backoff+jitter的retrai，支付操作的幂等。
6.转化缓存和阶梯模式。
7.SLO →自动操作（rollback/scale/reroute/kill-switch）。
8.GitOps策略代码+操作审核、发布注释。
9.关键场景的混沌测试和游戏日。
10.MTTR/Alert Quality dashbords和自动修复报告。

16）反模式

由于暂时依赖于flapping，Liveness"钉住"→过程。
没有taymauts/jitter的retrai →一阵查询。
IO依赖性服务的CPU的HPA →"无处可去"。
回滚→数据损坏时无版本共享缓存。
自动操作无需审核/Runbook URL。
没有DLQ/衡量标准 lag →沉默的债务积累。
自动治疗和"隐藏问题"的混合：自动治疗症状，根部无法消除→重复事件。

结果

自我修复是一门工程学科：高质量的样本和限制，合格的后退和隔离，对SLO信号的自动操作，以及混沌检查和审计。这样的轮廓使平台具有抗故障性，减少了MTTR，并节省了iGaming的关键指标-p99，支付转换和TTW-即使在最热的时钟也是如此。