变更流程：通过规范变更流程、接入GOC强管控、变更白屏化及变更自动化来提升变更效率，同时保障变更质量。

1）管控规范流程定义通过约束现有的管控变更行为如热升级、配置变更、DDL变更、约束配置变更、数据订正、黑屏操作等实现所有变更可监控、可灰度、可回滚。2）强管控接入通过对接集团强管控，来保障所有变更可追溯、可评审。（也期望可以通过平台对接强管控消除人肉提变更的繁琐）3）变更白屏化整合ECS全链资源、管控、诊断、性能、运维、可视化及老嫦娥运维能力，打造统一、安全、高效的弹性计算统一运维平台。4）变更自动化自动化一切需要人工干预的繁琐事项。

2.4 稳定性运营体系

稳定性体系的建设中，基础组件的容量性能优化、全链路稳定性体系建设、研发与变更流程的升级是其安身立命的基础，而若想细水长流则离不开文化的建立以及持续的运营。下面是ECS SRE在稳定性运营体系上做的一些探索。

on-call轮值：on-call 在Google SRE的模式是 7*24小时轮值，负责生产系统的监控预警处理，紧急故障救火等。SRE本质仍然是软件工程师，在ECS管控团队，SRE每个同学在负责研发的同时也要处理线上预警、应对紧急故障以及参与到疑难杂症的排查等日常繁琐的工作，为了保障SRE同学核心研发工作不被打断，我们开始尝试使用on-call轮值机制。1）on-call的职责

• 监控预警处理，第一时间处理生产环境的监控预警。
• 紧急故障救火，协同业务团队处理生产环境稳定性问题。
• 稳定性问题排查，挖掘生产系统稳定性隐患，进入深水区进行挖掘。
• 全链路稳定性巡检，生产系统核心业务SLO指标、错误日志、RDS健康度、慢SQL巡检等。
• 参与故障复盘，此处的故障包括GOC故障与线上的稳定性问题。
• 经验总结输出，将on-call过程进行的故障诊断、问题处理、故障复盘进行总结。

2）新人如何快速加入on-call

• on-call 模版化，新人按图索骥，目标明确。
• on-call 知识库，新人红宝书。
• 参与到轮值，实践出真知。

如何做故障复盘？

故障复盘机制针对产生故障或者影响内部稳定性的问题进行事后复盘，在ECS内部我们将影响生产稳定性的问题统一定义为“内部故障”，我们的观点是 所有“内部故障” 都可能转化为真实的故障，应该被给予足够的重视度。为此我们内部与集团故障团队也进行了多次的沟通合作，在内部故障的复盘与管理模式上进行了一些探索，下面将介绍故障复盘的一些基本理念及ECS管控在故障复盘上的一些实践。故障复盘不是为了指责或者惩罚，而是为了发现故障表象背后深层次的技术与管理问题。

• 避免指责
• 对事不对人
• 奖励做正确事的人
• 协作与知识共享

1）故障复盘的方式

• 责任人填写故障复盘报告。
• SRE与相关干系人参与评审（严重故障线下会议对齐）
• 故障干系人按照ETA保障故障Action落地。

2）故障复盘文档库故障复盘总结是我们重要的知识资产，我们内部针对每一次故障复盘进行了深刻的总结，形成内部知识库 《Learn From Failure》

稳定性日常运营

稳定性本身是一个产品，需要日常持续的运营，在ECS管控主要模式有稳定性日报与双周报。

• 稳定性日报，T 1 FBI报表，汇总全链路核心的指标数据如工作流、OpenAPI成功率、资源一致性及资损，主要目的是为了及时发现系统隐患，并推动解决。
• 稳定性双周报，双周发布，邮件模式，阶段性汇总全链路稳定性问题（包括故障、内部稳定性问题）、核心问题公示、核心链路指标分析等。

三、我认知的SRE

前文概要性介绍了ECS SRE过去的一些实践经验，笔者自18年开始以SRE的角色参与到ECS稳定性治理与研发工作，下文将谈一下自己这一年时间实践SRE的一些感悟，一家之言，供参考。

3.1 关于SRE的几个认知误区

1） SRE 就是运维

SRE不止于运维，确实部分公司的SRE岗位工作内容与传统的运维或者系统工程师相近，但 主流或者说未来的SRE是一个技能综合性岗位，不仅需要运维能力，也需要软件工程能力、技术架构能力、编码能力、以及项目管理与团队协作能力。

2） SRE 不需要懂业务

脱离了业务的架构是没有灵魂的！不懂业务的SRE是不合格的SRE，SRE要参与的技术与运维架构的优化与未来规划，同时也要协同业务团队完成故障排查，疑难杂症的处理，这些工作没有对业务的理解是无法很好的完成的（甚至无法完成）。

3.2 SRE能力模型

前面在“SRE=运维”的误区解答中，简单说明了SRE岗位对技术全面性的需求，下面笔者试着给出一个未来SRE能力模型，仅供参考。