如果你每天都在追问“服务可靠吗”“延迟为什么升高”“下一次会在哪里出故障”，那么 KubeCon + CloudNativeCon North America 2026 的难点可能不是内容太少，而是如何从大量与可靠性、性能、可观测性、事故响应和扩缩容有关的内容中，挑出真正适合自己的学习路径。
与其收集一长串演讲，不如围绕当前系统最昂贵的风险来安排行程，并要求每次学习最终变成一次实验、一项工程决策或一份可复用的运维资产。
用生产问题，而不是技术名词选择内容
SRE 的知识面很宽。选择主题时，可以先写下团队最近三个月遇到的具体问题，再把它们映射到相应领域：
| 生产问题 | 值得关注的方向 | 会后应带走的结果 |
|---|---|---|
| 发布后频繁回滚 | 就绪探针、渐进式交付、错误预算 | 一份发布门禁清单 |
| 高峰期延迟突然上升 | 性能分析、容量规划、排队与限流 | 一次可重复的负载实验 |
| 告警很多但定位缓慢 | 指标、日志、追踪以及信号关联 | 一个围绕用户路径设计的仪表盘 |
| 事故依赖少数专家处理 | 事件响应、运行手册、复盘机制 | 一份可以由值班人员执行的 runbook |
| 自动扩容启动太晚 | HPA、资源请求、指标延迟 | 一组经过压测验证的扩容阈值 |
| 担心依赖或节点突然失效 | 故障注入、Pod 分布、降级策略 | 一个限定爆炸半径的演练方案 |
这套方法可以避免“因为某个工具热门，所以去听它”的被动选择。工具会变化，可靠性问题通常更稳定。
还可以给候选内容打三个分：
- 相关性：是否对应当前生产风险？
- 可验证性：能否在一到两周内做实验？
- 可传播性：结果能否写进平台模板、运行手册或团队规范？
优先选择三个维度都较高的主题，而不是单纯追求日程数量。
把可靠性拆成可验证的工程假设
“提升稳定性”无法直接执行。更有效的方式是把它改写成可验证的假设，例如：
- 如果服务设置合理的
readinessProbe，未完成启动的 Pod 就不会过早接收流量。 - 如果资源请求接近实际基线，HPA 的 CPU 利用率信号会更有参考价值。
- 如果副本分布合理并配置 PDB，计划内节点维护造成的容量下降会更可控。
- 如果告警直接关联用户可感知的 SLI，值班人员会减少处理无影响噪声的时间。
这些假设也提醒我们注意边界：PDB 不能阻止节点意外宕机，HPA 不能代替容量规划，探针配置过于激进反而可能制造重启风暴，而“安装了可观测性平台”也不等于已经定义了可靠性目标。
可以直接改造的 Kubernetes 可靠性实验
下面是一套最小实验环境，用来观察探针、资源请求、PodDisruptionBudget 和 HPA 如何共同作用。运行前需要准备一个可用的 Kubernetes 集群；HPA 的 CPU 指标还要求集群安装 Metrics Server。
cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
name: sre-lab
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
namespace: sre-lab
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.27-alpine
ports:
- containerPort: 80
resources:
requests:
cpu: 50m
memory: 32Mi
limits:
cpu: 200m
memory: 128Mi
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 2
periodSeconds: 5
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 10
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: web
namespace: sre-lab
spec:
selector:
app: web
ports:
- port: 80
targetPort: 80
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: web
namespace: sre-lab
spec:
minAvailable: 2
selector:
matchLabels:
app: web
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web
namespace: sre-lab
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
minReplicas: 3
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
EOF
kubectl rollout status deployment/web -n sre-lab
kubectl get pods,hpa,pdb -n sre-lab
可以启动一个简单的集群内负载生成器：
kubectl run load-generator \
--namespace sre-lab \
--image=busybox:1.36 \
--restart=Never \
-- /bin/sh -c 'while true; do wget -q -O- http://web >/dev/null; done'
kubectl get hpa,pods -n sre-lab --watch
另开一个终端观察指标和事件：
kubectl top pods -n sre-lab
kubectl get events -n sre-lab --sort-by=.lastTimestamp
kubectl describe hpa web -n sre-lab
实验时不要只确认“HPA 有没有增加副本”，还应记录以下数据：
- 从负载升高到产生扩容决策用了多久。
- 新 Pod 从创建到通过就绪探针用了多久。
- 扩容期间请求是否出现错误或明显延迟。
- 负载停止后，副本何时开始缩减。
- 当前 CPU 请求值是否导致扩容过早或过晚。
结束后清理环境：
kubectl delete namespace sre-lab
这只是教学实验，不能直接当作生产模板。真实服务还需要考虑拓扑分布、反亲和性、优雅终止、启动探针、应用级健康检查、自定义指标以及流量生成器本身的资源上限。
从演讲笔记走到团队变更
参加相关内容时，可以把普通笔记改成三栏：
决策：我们准备改变什么？
证据：演讲中的哪个案例、指标或失败模式支持它？
实验：如何在隔离环境中验证，成功和回滚条件是什么？
例如，不要只记录“应该使用 SLO”，而应形成一个具体任务：为结账接口定义 30 天可用性目标，确定成功请求的统计口径，并用历史数据回放告警阈值。
如果团队使用 Prometheus，一个最小的 HTTP 成功率 SLI 可以这样表达。以下假设应用暴露了 http_requests_total，并带有 status 标签；实际使用时需要替换指标名和标签：
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
需要注意，技术成功率不一定等于用户成功率。超时、返回空结果、依赖服务降级以及客户端主动取消，都可能要求更精确的 SLI 定义。
一份更实际的参会与采纳清单
参会前：
- 列出三个最昂贵或最频繁的生产故障模式。
- 为每个问题定义一个希望验证的工程假设。
- 保存当前基线，包括 SLO、事故恢复时间、告警量和资源成本。
参会期间：
- 优先寻找失败案例、适用条件和迁移代价，而不只是成功架构。
- 记录方案依赖的组织能力，例如平台团队、值班制度或统一遥测标准。
- 对同一问题听取不同实现路径，避免过早绑定单一工具。
参会后：
- 一周内选择一个低风险实验，而不是立即推动全量迁移。
- 明确负责人、观测指标、停止条件和回滚方案。
- 把有效成果沉淀为模板、仪表盘、告警规则或 runbook。
SRE 成长并不等于掌握越来越多的云原生组件。更可靠的路径，是持续把问题变成假设，把假设变成实验，再把实验结果固化为团队可以重复执行的能力。这样，会议日程才会从信息洪流变成真正改善生产系统的路线图。