运维工程师如何从救火队转型SRE？我把MTTR从47分钟压到9分钟的5个步骤

我在杭州一家跨境电商SaaS做运维，团队7个人，管230台阿里云ECS、17个K8s命名空间、43个RDS实例、9套Redis。2023年3月我统计过，我们每月变更大概120次，P1故障5.2次，MTTR 47分钟。老板觉得我们“很忙”，但研发觉得“运维就是卡发布”。这个矛盾不是靠买监控能解决的。

先给一个可能挨骂的观点：很多运维工程师把SRE理解成“用Go写自动化”，我认为错了。SRE首先是财务模型，用错误预算把可靠性变成可交易的成本。传统运维考核“有没有故障”，SRE考核“故障花掉多少预算”。我们当时把核心链路SLO定为99.9%，按30.44天算是43分49秒/月，按30天算是43分12秒，差那几十秒别杠，看账。超过就冻结非必要变更，让产品自己排优先级。这个动作比多装10个Exporter有用。

对比三条路，别混着走：

• 传统运维：资产台账+脚本+电话告警，优点快，缺点人走知识走。
• DevOps：CI/CD+IaC，解决交付，但不解决线上决策。
• 平台工程：内部开发者平台，把运维能力产品化，适合研发超过100人的团队。 我们7个人，选的是“SRE轻量版”：先统一标签，再建黄金指标，最后才谈自动化。顺序反了，就是给混乱加涡轮。

第1步：资产和标签。别急着上CMDB，我们先用Ansible 2.14的setup模块+inventory，每晚2点跑一次，把230台ECS的hostname、IP、OS、内核、CPU、内存、磁盘、所属业务、负责人、到期时间写进MySQL 8.0.32。标签规范就4个：env=prod/staging/dev，app=order/payment/user，team=xxx，tier=core/edge。没有这4个标签，Prometheus查询就是垃圾进垃圾出。我们删掉了63条无效告警，因为标签对不上。

第2步：黄金指标。每个服务只看4个：延迟、流量、错误、饱和度。Prometheus scrape_interval=15s，evaluation_interval=15s；P99延迟告警for: 5m；错误率用5xx请求数除以总请求数，连续5分钟大于5%才告警。Nginx日志用Filebeat进ES，但只保留7天热数据、30天冷数据，省了约40%存储。Grafana 9.3做了4块看板：业务总览、K8s、中间件、主机。看板不超过4块，多了没人看。

第3步：告警分级和值班。以前每天386条告警，企业微信群里滴滴滴。我们分P1/P2/P3：P1电话+5分钟升级，P2企业微信+15分钟，P3工单+次日。PagerDuty没买，用Alertmanager route到电话网关。关键参数：group_wait=30s，group_interval=5m，repeat_interval=4h。改完每天23条，P1每月从5.2次降到1.3次。告警转化率=有效告警/总告警，我们要求大于70%，低于60%就删规则。

第4步：变更和复盘。所有变更走GitLab MR，至少1人review；生产变更窗口周二/周四14:00-17:00，周五禁止核心变更。回滚脚本必须和发布脚本一起提交，没有回滚不批。每次P1做无责复盘，只问3个问题：什么变了？为什么监控没提前发现？下次用什么自动化替代人工？我们攒了37个复盘，后来变成19个Ansible playbook和6个K8s operator。

第5步：错误预算和产品谈判。这是最难但最值钱的一步。SLO 99.9%给核心链路，99.95%给支付，99.5%给后台报表。错误预算烧完，发布冻结，除非CTO签字。研发一开始骂，后来发现“冻结”比“运维口头说不行”更可预期。运维也不再靠情绪吵架。我的观点：运维工程师如果不掌握错误预算，就永远在背锅位；掌握了，才是给可靠性定价的人。

最后说句不那么正确的话：别先学K8s源码，先把你们公司最常挂的3个服务画出来，跑通一次从告警到复盘到自动化的闭环。工具会过时，决策记录不会。我们团队现在还是7个人，机器涨到310台，K8s命名空间29个，但MTTR稳定在9分钟左右，不是因为我们更卷，是因为我们把救火变成了流程。