腾讯游戏 营销SRE负责人

• 腾讯游戏营销SRE负责人，腾讯T12级技术专家，国家工程实验室兹聘专家（工业大数据应用技术）。曾荣获：华章最有价值作者、中国十大杰出IT博主、WOT十大优秀讲师、OpsWorld金牌讲师、TOP100优秀出品人、中国数据质量杰出专家奖、DAMA中国数据治理专家奖。个人著作：《python自动化运维：技术与实践》《循序渐进学Docker》《第一次使用Docker就上手》《破解数据治理之谜》《研发效能权威指南》等，发明专利12个。个人热衷于开源技术的研究，擅长海量服务运维与规划、SRE工具链、云原生技术、大数据治理、数据中台与业务中台的建设等工作。

首先直接完全复制到我们的实践当中肯定是不可取的，原因是Google SRE这套方法论诞生的背景，是满足Google面对全球庞大服务的稳定性保障的诉求，它整个的系统与架构是非常复杂，同时它又具备较为强大的基础设施及资源的调度管控能力，存在一定的独特性。但是我们可以做深度的借鉴，比如SLI与SLO的设定，错误预算的应用，OnCall轮值机制、高可靠与自动化的实现方法等等。根据我们的经验，这些方法在实践过程中都非常有参考与学习价值。现阶段我认为不太可取的地方是，Google SRE建议SRE工程师至少有50%或更多时间投入在研发，其它时间用于运维，这个跟每个团队的转型路径与成熟度有关，不要一开始以这样的规定来要求SRE工程师，这样达不到想要的预期。

其实放眼在国内运维行业的发展历程，不少企业也在潜移默化在形成自己的发展路径，实践与Google提出的SRE具有异曲同工之妙，缺少的是进一步做抽象，形成一套完整的方法论体系。要达到Google SRE这样的一个水平，我认为要优先解决下面三个问题：

这个说法也没错，我个人更趋向于是一个懂开发的资深运维，这两者还是有本质的区别，相当于两种不同角色的能力加持，“懂运维的资深开发”，说明他本身就是一个研发，只不过额外加持了运维的能力，提倡让研发来做转型，我不太建议这种模式；

另外一种是“懂开发的资深运维”，说明他本身就是一个资深运维，开发是额外增强的能力，因为在国内很多SRE都是由传统运维转型而来，不少企业干脆直接将原先运维团队名直接改成SRE技术部之类，一些企业内部都有运维开发或运营开发这样的角色，负责运维工具的建设。

在国内，我认为现阶段最佳的SRE转型模式，便是要求运维人员快速具备运维开发这样的能力，但不一定比专职的运维开发那样专业，这两种角色是要分层来协作的，我们的经验是运维开发负责整体Paas层、平台框架、研发标准化的构建，或者是打造一体化的低代码平台，SRE在最上层负责运维工具或SaaS的开发，因为SRE非常清楚自己需要什么样的工具，来解决什么样具体的问题，自己来操刀再适合不过，最终将达到开发运维一体化的目标。

首先从Google解释DevOps与SRE之间的关系不难看出两者是敌是友，它的解释是说：SRE是DevOps的一种实现方式，也是Google在运维领域的一种具体实践，个人也比较认同这个解释，有些人认为DevOps包括了SRE，我认为也是正确的，因为DevOps广义上的边界比SRE要宽广很多。事实上DevOps和SRE文化、理念与追求的目标上非常相似，两者都有鼓励开发和运维人员的高度融合，一起来承担共同的目标，并专注于实现更加自动化和可靠性保障的目标。如真的要讲SRE与DevOps之间的区别，这里引用刘峰老师的一句话来概括：“SRE是运维拥抱研发，DevOps是研发拥抱运维”。