系统学习 学习路径总入口：先选领域，再建立模型，最后用故障演练验证

    SRE 岗位学习路径：用 30/60/90 天把值班、SLO、事故指挥、变更与容量串成一条工作流

    使用方式

    这不是又一条按技术栈排列的学习路径，而是按 SRE 的岗位交付物倒推：第一个月能安全值班，第二个月能用 SLO 和可观测性定义“正常”，第三个月能指挥事故并管住变更，之后能对容量和成本负责。

    四个阶段对应 30/60/90 天和一个持续运营阶段。每个阶段先读岗位会用到的页面，再在测试环境或只读权限下完成任务，最后用可验证的结果过关。

    建议每周留出一次两小时的复盘：把本周处理的告警按“可行动、可自动恢复、误报”分类，挑一条最常出现的告警补 runbook 或改阈值。到第 90 天，你应该能拿出四份记录和一份自己的值班改进清单，而不是只读完一串页面。

    阶段一：第 1–30 天，先能安全值班

    目标：能完成一次完整交接，收到告警后判断影响面、找到负责人并按升级路径推进，而不是先重启或先追根因。

    阅读顺序：

    1. sre-oncall-checklist — 交接、分级、止血和复盘的固定检查项。
    2. on-call — 轮换、备份值班、告警分级和升级时限。
    3. runbook — 让告警真正可执行的 runbook 结构与验证方式。
    4. observability-roadmap — 值班需要的指标、日志、追踪和告警能力。
    5. http-status-cheatsheet — 从状态码判断故障在入口、网关还是上游。
    6. linux-performance-triage — 主机层 CPU、内存、磁盘和网络的第一轮排查。
    7. kubectl-cheatsheet — 现场查看 Pod、事件、日志和发布状态的常用命令。
    8. amtool — 查询告警、创建静默并验证 Alertmanager 路由。

    动手任务：跟一次完整班次，只读参与。交接前整理上一班未闭环告警、进行中变更和风险窗口；对一条测试告警执行查询、静默、解除静默，并记录它最终路由到哪个 receiver。

    amtool alert query --alertmanager.url=http://localhost:9093
amtool silence add alertname=TestAlert --duration=30m --comment='drill'
amtool silence query --alertmanager.url=http://localhost:9093
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/

    过关标准：

    阶段二：第 31–60 天，用 SLO 和可观测性定义“正常”

    目标：能为一个核心服务定义 SLI 和 SLO，算出 28 天错误预算，并把燃烧率告警、看板和发布门禁连起来。

    阅读顺序：

    1. slo — SLI、SLO、SLA 的区别，窗口选择与燃烧率告警。
    2. error-budget — 错误预算的计算、消费和发布冻结策略。
    3. observability-learning-path — 从指标、日志、链路到 SLO 和值班的依赖顺序。
    4. observability-mental-model — 用信号、标签、基数和证据回答未知问题。
    5. prometheus — 指标采集、存储和告警规则的组织方式。
    6. promql-cheatsheet — 编写成功率、错误率和燃烧率查询。
    7. alertmanager — 告警去重、分组、抑制和路由。
    8. grafana — 把 SLO、预算和值班信号放进同一块看板。
    9. loki — 按标签聚合日志，补上指标看不到的错误细节。
    10. logql-cheatsheet — 用 LogQL 从日志中量化错误和延迟分布。

    动手任务：选一个只读服务，写出成功率 SLI 的分子分母，用 recording rule 固化 5 分钟错误率；计算 99.9% SLO 在 28 天窗口的可用分钟数，配置快慢两条燃烧率告警，并用 promtool 校验规则。

    awk 'BEGIN {printf "允许不可用: %.2f 分钟\n", 28*24*60*(1-0.999)}'
promtool check rules slo-rules.yml
curl -s localhost:9090/api/v1/query --data-urlencode 'query=job:http_errors:ratio_rate5m'
amtool alert query --alertmanager.url=http://localhost:9093

    过关标准：

    阶段三：第 61–90 天，事故指挥与变更管理

    目标：能在事故中承担 IC 或明确配合角色，冻结变更、组织止损和沟通；在发布前用渐进式交付和回滚预案控制爆炸半径。

    阅读顺序：

    1. incident-response-playbook — 分级、角色、沟通、止损和复盘的完整流程。
    2. incident-command — IC、Ops Lead、Comms Lead 和 Scribe 的职责边界。
    3. postmortem — 无责复盘模板、时间线和改进项闭环。
    4. public-postmortem-index — 按根因对照公开事故，校准自己的判断。
    5. migration-readiness-checklist — 变更前的依赖、回滚和数据兼容检查。
    6. progressive-delivery — 金丝雀、蓝绿和自动回滚的决策依据。
    7. argo-rollouts — 用 Rollout 和 AnalysisTemplate 固化发布步骤。
    8. poddisruptionbudget — 滚动发布和节点维护时的可用性下限。
    9. runbook-k8s-upgrade — 控制面、节点和 addon 的升级顺序与回滚点。
    10. k8s-upgrade-checklist — 升级前的版本、兼容性和容量检查。
    11. chaos-engineering — 用受控实验验证回滚、切流和降级确实有效。

    动手任务：组织一次 45 分钟 game day，模拟“核心 API 错误率 8%”。指定 IC、Ops、Comms 和 Scribe，只允许回滚、切流、扩容、降级四类止血动作；事后产出一条带 UTC 时间的时间线和三条有 owner 的改进项。再为测试服务配置 1% → 5% → 25% 的金丝雀和自动分析。

    kubectl argo rollouts get rollout payment -n test --watch
kubectl get pdb -A
kubectl rollout undo deployment/payment -n test
kubectl rollout status deployment/payment -n test
kubectl get events -A --sort-by=.lastTimestamp | tail -30

    过关标准：

    阶段四：90 天后，容量、成本与持续运营

    目标：能用峰值而不是平均值做容量预测，区分 HPA、VPA 和节点扩缩容的职责，并把成本、灾备演练纳入日常运营。

    阅读顺序：

    1. capacity-forecasting — 峰值预测、水位阈值、扩容公式和采购提前期。
    2. capacity-planning — 节点选型、装箱率、资源预留和超卖。
    3. hpa — 按指标扩副本的适用条件、指标链路和扩缩容抖动。
    4. vpa — 调整 request 与 limit，减少资源错配和 OOM。
    5. cluster-autoscaler — 节点层扩容、缩容和 Pending 的关系。
    6. karpenter — 按 Pod 需求快速供给合适规格的节点。
    7. cost-optimization-checklist — 闲置资源、规格、存储和网络成本检查。
    8. finops — 成本分摊、预算告警和优化优先级。
    9. opencost — 按命名空间和工作负载拆分集群开支。
    10. dr-drills — 灾备演练的频率、场景、验收和失败回退。

    动手任务：为一个服务做 90 天容量报告：取至少 6 周峰值 QPS 做线性趋势，按 P99 延迟和安全并发算所需副本；核对单可用区故障后的 N+1 余量；再用 OpenCost 给出该服务前三大成本项和一条可执行的优化建议。

    kubectl top nodes
kubectl get hpa -A
kubectl describe hpa <name> -n <namespace>
kubectl get pods -A -o wide --field-selector=status.phase=Pending
kubectl get pdb -A

    过关标准：

    常见误区

    参考链接

    读完自测

    合上页面，先回答，再展开对照。

    1. 为什么 SLO 不应该设成 100%？错误预算耗尽后应该怎么调整发布策略？
    2. 事故刚开始时，IC 的第一小时应该做什么，不应该做什么？
    3. 容量规划为什么看 request 和峰值，而不能看 limit 和平均值？
    答案
    1. 100% 目标没有错误预算，任何一次失败都变成违规，团队会倾向于隐瞒问题或冻结所有变更。合理做法是保留小比例预算，并用燃烧率而不是瞬时错误率告警。预算耗尽后应冻结功能发布，只做可靠性改进，直到复盘完成并恢复到阈值以上。
    2. IC 应先确认影响面、定级、指定角色、建立单一频道并冻结相关变更，然后推动回滚、切流、扩容或降级等止损动作，同时安排固定节奏的对外更新。IC 不应亲自查日志或长时间做技术定位，也不应在止血前承诺根因和恢复时间。
    3. Kubernetes 调度按 request 预留资源，limit 只是运行上限，按 limit 估算会高估可调度容量；容量决策要看每天峰值和增长趋势，平均值会掩盖突发流量、活动日历和单区故障后的 N+1 需求。

    相关条目
    全部条目 · 故障诊断向导 · 每日复习
    收藏本站请使用 Ctrl+D 或者 Command+D
    共搜集到 201 个指南条目
    京ICP备16007053号-1
    本站由 dos2un1x 构建维护 · 代码开源 →
    微信小程序码：扫码打开命令速查小程序

    小程序版

    微信扫码，随时查命令