技能介绍

要解决的问题

很多团队在稳定性上投入不少，却总是在救火：告警太多没人信，事故复盘变成追责，容量规划靠拍脑袋，发布速度和稳定性永远在打架。开发想转 SRE 时更常陷入迷茫——指标、日志、链路、SLO、错误预算、oncall……知识点零散，不知道先补哪个、怎么练才能真正落地。

技能如何工作

这个技能把 SRE 与生产工程拆成五层能力阶梯，每层对应一个可直接练习的输出目标：

可观测地基：先把 指标 / 日志 / 链路 三件套搭好，保证出问题时能定位，而不是凭感觉排查；
有效告警：每条告警都要对应「必须有人动作」的场景，删掉纯噪声告警，避免「狼来了」式疲劳；
容量管理：通过压测和容量规划，让系统扛得住业务峰值，而不是等到故障才临时扩容；
事故响应：明确 IC（ incident commander ）和记录等角色，编写 runbook，通过演练让团队在故障时知道谁做什么；
SLO 与错误预算：用 错误预算 把「发布速度」和「系统稳定」变成可谈判的工程指标，而不是凭情绪拍板；
复盘文化：事故后做无责复盘，聚焦根因改进，而不是追责罚人，让问题真正被解决。

技能内置了落地检查清单和常见陷阱：

核心服务是否都有 SLO 与对应仪表盘？
告警是否每条都需要人动、无噪声？
是否做过容量压测与峰值预案？
复盘是否无责且落到根因改进？

同时会提示避免三个高频陷阱：告警风暴淹没真问题、无 SLO 瞎优化导致资源错配、复盘变追责没人敢说真话。

适用边界与注意点

这个技能适合想系统建立 SRE 能力的团队或个人，但它不是银弹。SRE 实践需要结合团队的真实业务场景，比如电商大促的容量规划和内容社区的告警策略完全不同；事故处理和容量决策也要参考 Google SRE 等官方方法论与权威资料核实，不能照搬清单。技能不会替代工程师的判断——比如 SLO 的阈值怎么定、告警优先级怎么排，仍需结合业务实际调整。