早上九点，某互联网公司的运维团队正在处理一场线上接口超时的告警。值班工程师一边翻看监控图表，一边在群里@SRE同事。这种场景在过去几年里越来越常见——SRE（Site Reliability Engineering，站点可靠性工程）不再只是谷歌的专属名词，正逐渐渗透进国内各类企业的技术体系中。
大厂先行，模式初成
像阿里、腾讯、字节这样的头部公司，早在五年前就开始尝试引入SRE理念。他们用“研发驱动运维”的方式重构团队结构，把原本被动救火的运维角色，转变为通过代码和系统来预防故障的工程岗位。比如字节内部的SRE团队会负责核心服务的SLI/SLO制定，并通过自动化平台实现故障自愈。
这类企业通常有足够资源搭建完整的可观测性体系。Prometheus + Grafana 做指标监控，Jaeger 跟踪链路，ELK 收集日志，再配合自研的发布控制系统，形成闭环。一个典型流程是：
<rule name="high_error_rate">
<when metric="http_5xx_rate" threshold="0.01" duration="5m" />
<then action="trigger_roll_back" service="user-api" />
</rule>一旦某个接口错误率超过阈值，系统自动触发回滚。这已经不是未来构想，而是很多大厂每天都在跑的规则。
中小企业：想动又不敢动
可走到中小型公司，情况就变了。不少团队还在用“开发写代码，运维重启服务器”的老套路。老板听说SRE能提升稳定性，也想搞，但现实是人手紧张、系统老旧、文档缺失。
有个创业公司的CTO跟我聊过：他们试过设一个SRE岗位，结果新来的同学发现，数据库没备份机制，K8s集群还是单节点部署，连基本的健康检查都没有。想推SLO？先得把服务能不能活着都说清楚。
更普遍的情况是，“SRE”成了运维换了个名字。表面上设立了SRE小组，实际工作还是半夜被叫起来查日志、清缓存、扩实例。真正的工程化投入少得可怜。
工具容易学，文化难复制
很多人以为上一套开源监控工具就是搞SRE了。其实工具只是最表层的东西。SRE的核心在于用软件工程的方法解决运维问题，比如把变更流程变成可测试的代码，把容量评估做成模型预测。
但国内不少企业卡在“重交付、轻维护”的思维定式里。项目上线庆功宴都办了，没人愿意花两周时间去做故障演练。直到出了事，才想起要“加强稳定性建设”。
还有个细节值得提：事故复盘。谷歌提倡 blameless postmortem（无指责复盘），可在一些公司，一出故障就要追责到人。结果大家写报告时拼命甩锅，真正的问题根源反而被掩盖了。
本土化尝试正在发生
尽管有差距，但变化也在出现。有些金融、电信类企业开始结合ITIL流程和SRE原则，搞出混合模式。比如把变更窗口管理与自动化灰度发布结合，既满足合规要求，又降低人为失误。
也有团队从最小可行动作做起：先定义关键服务的可用性目标，比如登录接口全年99.95%可用；再通过监控数据反推改进点。哪怕没有专职SRE，开发自己顺手写个巡检脚本，也算迈出一步。
现在国内技术社区里，关于SRE的讨论越来越多。从B站上的故障分析视频，到微信群里的告警配置互评，再到各种线下 meetup 上分享的土办法，都在推动这个角色慢慢扎根。
SRE在国内不是要不要做的问题，而是怎么适配现实土壤的问题。不是每家公司都能照搬谷歌模式，但把“稳定优先”的意识融入日常开发，谁都可以开始。