用 Azure Chaos Studio 把“高可用”变成可验证的工程事实

预计阅读时间：7 分钟

很多团队都在架构图里写过“多区域”“自动故障转移”“弹性伸缩”，但真正的问题是：这些能力有没有在事故发生前被验证过？Azure Chaos Studio 的价值就在这里——它把停机、故障转移、网络中断、基础设施异常这些原本只会在生产事故中暴露的问题，提前变成可控实验。

它不是为了“制造混乱”，而是为了证明应用在混乱中仍然能按预期工作。

从演练文档走向可重复实验

传统韧性验证经常停留在几类活动里：架构评审、桌面推演、手工切流、压测后的人工观察。这些当然有用，但缺少一个关键能力：可重复。

Azure Chaos Studio 提供的是面向云资源的混沌实验能力。团队可以模拟：

区域级或实例级故障带来的服务不可用；
网络延迟、丢包、断连等连接问题；
基础设施层面的中断或资源异常；
故障转移流程是否真的按预期触发；
监控、告警、自动修复是否能及时响应。

这类实验的目标不是证明系统永远不会失败，而是回答几个更现实的问题：失败发生时，影响范围多大？多久能恢复？哪些告警会响？哪些自动化流程没有生效？

一个好的混沌实验应该先定义“稳态”

很多混沌工程实践失败，不是因为工具不够强，而是因为实验没有判定标准。

在 Azure 上做韧性验证时，建议先定义应用的稳态指标，例如：

/healthz 接口 99% 请求在 300ms 内返回；
关键 API 错误率低于 1%；
队列积压不超过某个阈值；
主区域不可用后，备用区域在 5 分钟内接管；
用户侧可见错误不超过约定的 SLO。

有了稳态，Chaos Studio 实验才有意义。否则你只能知道“我制造了一个故障”，却不知道“系统是否扛住了这个故障”。

可以这样实践：用脚本给实验加上外部观测

下面的示例不依赖具体 Chaos Studio 实验定义，适合作为实验前后的外部探针。你可以把 APP_URL 改成自己的健康检查地址，在运行混沌实验时并行执行它，观察应用是否保持可用。

#!/usr/bin/env bash
set -euo pipefail

APP_URL="${APP_URL:-https://example.com/healthz}"
DURATION_SECONDS="${DURATION_SECONDS:-300}"
INTERVAL_SECONDS="${INTERVAL_SECONDS:-5}"
MAX_LATENCY_MS="${MAX_LATENCY_MS:-1000}"

end_time=$((SECONDS + DURATION_SECONDS))
failures=0
checks=0

while [ "$SECONDS" -lt "$end_time" ]; do
  checks=$((checks + 1))

  result=$(curl -o /dev/null -s -w "%{http_code} %{time_total}" "$APP_URL" || echo "000 0")
  status=$(echo "$result" | awk '{print $1}')
  latency_seconds=$(echo "$result" | awk '{print $2}')
  latency_ms=$(awk "BEGIN {printf \"%.0f\", $latency_seconds * 1000}")

  if [ "$status" != "200" ] || [ "$latency_ms" -gt "$MAX_LATENCY_MS" ]; then
    failures=$((failures + 1))
    echo "FAIL status=$status latency=${latency_ms}ms"
  else
    echo "OK status=$status latency=${latency_ms}ms"
  fi

  sleep "$INTERVAL_SECONDS"
done

echo "checks=$checks failures=$failures"

if [ "$failures" -gt 0 ]; then
  exit 1
fi

运行方式：

chmod +x probe.sh
APP_URL="https://your-app.example.com/healthz" DURATION_SECONDS=600 ./probe.sh

这个脚本不能替代 Azure Monitor、Application Insights 或正式的 SLO 体系，但它很适合放进演练流程、CI/CD 验证，或者作为混沌实验期间的快速外部视角。

用 YAML 记录一次演练计划

Chaos Studio 的实验配置可以由平台团队管理，但应用团队也应该拥有一份清晰的演练说明。下面是一个可以改造的演练清单，用来描述一次网络中断或故障转移验证。

experiment:
  name: checkout-service-regional-failover
  objective: 验证结算服务在主区域异常时是否能完成故障转移
  steady_state:
    health_endpoint: https://checkout.example.com/healthz
    max_error_rate: 1%
    max_recovery_time: 5m
  blast_radius:
    environment: staging
    services:
      - checkout-api
      - payment-worker
    excluded:
      - production-database
  fault:
    type: network_disruption
    target: primary-region-app-instances
    duration: 10m
  monitors:
    - Azure Monitor alerts
    - Application Insights availability test
    - external probe.sh
  rollback:
    trigger: error_rate > 5% for 2m
    action: stop experiment and restore normal routing

这份 YAML 不是 Azure Chaos Studio 的完整资源定义，而是一个团队协作模板。它强迫大家在实验前讲清楚目标、影响范围、观测指标和回滚条件。真正落地时，可以把这些字段映射到 Azure 资源、实验步骤、告警规则和运行手册里。

不要一上来就打生产

混沌实验最怕两种极端：一种是永远不做，另一种是一开始就对生产核心链路下重手。

更稳妥的 adoption 路线是：

从 staging 或预生产环境开始，先验证实验流程；
每次只引入一种故障，避免无法判断原因；
明确 blast radius，限制影响范围；
实验期间打开监控面板，并指定负责人；
把每次实验结果转化为 backlog，而不是只写一份复盘；
在有足够信心后，再对低风险生产流量做小范围验证。

Azure Chaos Studio 的意义不只是“模拟一次宕机”。它更像是一套韧性证明机制：把高可用设计、故障转移流程、告警系统和团队响应能力放到同一个实验场里检验。真正成熟的系统，不是从不失败，而是知道自己会怎样失败，并且已经练习过如何恢复。