Google那套SRE你还敢用吗？谁说SRE本质是个懂运维的资深开发？丨话题接力_谷歌 开发运维一体化系统

dbaplus社群本文部分内容依据史军艇老师和刘昊老师的〖deeplus直播：话题接力丨云原生下的SRE进化之路〗线上分享演讲内容整理而成。（文末有回放的方式，不要错过）
十多年前，Google提出SRE这一概念并开始应用，随着大型互联网系统的出现，以及云原生技术的发展，近几年SRE实践逐步在国内受到广泛关注和探索。区别于传统运维，SRE被提出了更为极致的稳定性及性能需求。但事实上，目前业界在SRE上的实践还相对匮乏，各行各业对SRE的职责划分也不尽相同，在初期落地过程中也存在着很多误区……本次专题讨论，希望通过汇集多位SRE专家的研究成果和实践积累，给大家进一步明确SRE的职能和发展方向，提供可参考、可落地的SRE体系建设实战经验。

为此，dbaplus社群邀请到浙江移动 SRE架构师-史军艇、哔哩哔哩基础架构部 SRE体系负责人-刘昊、小米运维部 存储计算运维负责人-刘志杰，希望通过汇集三位SRE专家的研究成果和实践经验，给大家在云原生的SRE进化之路上，提供借鉴和启发。


三位嘉宾也一一例举了各自企业所做的一些SRE实践，给大家提供参考：

史军艇

SRE体系框架大同小异，其中包含架构设计、集成交付、测试、发布、变更管控、一体化监控、线上治理、后度量和复盘等部分。因为各个公司在组织架构、人员能力等方面不同，所以在SRE实践过程中存在差异。
SRE的核心在于落地工程能为公司带来的真正价值度。浙江移动近几年在SRE方向也进行了不少探索与实践，主要可概括为以下部分：

• 架构盒子：全局架构基于区域、平面、渠道等维度建立模型，单系统架构基于C4模型；
• 运营指挥中心：作为数字化调度的运营平台；
• 盗梦平台：以混沌工程为底座，具备红蓝对抗、入网测评、架构“保鲜”等能力；
• 应用多活平台：具备接入层、应用层、数据层、业务降级开关等全维度的多活要素，在不同级别的故障场景下，快速完成流量或开关切换，实现业务7*24保活；
• 流量回放平台：集合各类自动化测试能力；
• 一致性交付系统：与开发无缝衔接，将架构标准、集成标准、测试、演练串接于一条交付流水线，实现标准化、一致性的系统交付；
• SRE塔台：融合监控与操作，协同的一站式工作台；
• ......

刘昊
SRE的体系构筑，业界的理解都很一致，无非就是团队构建和人员转型、On Call轮值、应急响应、容量规划、度量监控可观测性、混沌工程、交付和变更管控、业务协作机制（bp、prr机制）、大型活动保障等。
目前B站在这些方面都有所实践：

• 可观测性的一系列平台，日志、链路追踪和指标监控；
• 围绕业务应用的服务树，构造服务应用的全生命周期和服务画像，为周边系统提供服务的元信息和运行时上下文；
• On Call排班系统；
• 事件运营中心，实现稳定性度量指标的数字化、在线化运营，让应急响应、应急协同的过程靠平台来承载，拉通了故障发生先、发生中和解决后的各个场景的解决方案；
• 混沌工程底座系统；
• 团队内部运维同学的SRE转型。

刘志杰
小米的SRE体系围绕质量、成本、效率展开工作，在信息化建设的角度，我们的目标是成为业务解决方案专家，保障和助力业务健壮发展。
在质量和效率层面，整体在质量运营、变更管控、巡检保障、容量规划、接入层管理、服务可观测性、活动重保等多个方向进行工程化落地，如存储计算运维中台-轻舟Canoe、业务全链路监控-Aifault、质量运营指挥中心-MiGOC、快速排障系统-Horus、统一接入管理-Mife等；
在成本层面，SRE立足小米混合云的运维现状，依托现有的技术和运营能力，从Iaas/Paas/Saas多维度为业务提供降本支撑，细节很多在此不再赘述。值得一提的是，我们许多降本增效上的方案，也侧面推动了运维架构的演进，为整体的技术变革添上了浓墨重彩的一笔。dbaplus社群还搜集了一些SRE的痛难点，跟三位嘉宾一起探讨：

Q1：Google最先定义了SRE，且提出了相应的一套方法论，但Google SRE方法能否复制在我们的实践当中？有哪些可取和不可取的地方？

史军艇“不要把SRE当成是0-1的事物”

SRE最早是Google在2003年定义的一个岗位，最初它出现的主要目的是：解决“研发”和“运维”之间的矛盾，逐步演变为一种工程思维。后面有了Devops概念，SRE的使命就更加明确，除了研发外，需要一个新型的Ops团队，既保证配合研发高效迭代创造前端价值，又保证业务系统稳定运行创造后端价值。

Google、Netflix等公司在SRE上有了很优秀的实践经验，也同时抽象出了Google SRE方法论。对于国内企业，可以效仿或借鉴一些国外好的体系及方法论，毕竟那些顶级的互联网公司发展走在我们前面，也为我们少踩了很多坑。但是直接把方法论复制成实践步骤，那是两个维度的事情。谷歌的《The Site Reliability Workbook》这本书中有一个高度抽象的解释，“class SRE implements interface DevOps“。DevOps是文化或理念，SRE是这个理念下的一个具体实现类，各个公司根据自身组织差异、基础设施差异、市场经营环境差异，可以重写成适合自己的实现类。

举个例子，我了解到的有些企业为了快速组建SRE团队，就直接找了一些开发工程师，希望这些开发工程师具备所有的技能。这显然是不科学的。从我们公司自身的实践经验来说，SRE是一个体系，不断地运用体系后得出的工程生态圈，其中每一个工程都有相应的团队去实施，最后串联起来就是整个SRE。因为SRE并不是0-1的事物，而是沉淀了多年的传统运维经验，融合新型的软件工程的概念而来的，是0.5+0.5=1的事情。
刘昊“Google的SRE实现路径在国内并没有想象中容易”

Google定义了SRE，对SRE团队的职责做了一定的描述，像稳定性改进、延迟优化、性能优化、效率优化、变更管理，监控、应急响应以及容量规划与管理，在《Google SRE谷歌运维解密》这本书里面做了大量的说明。

我相信大多数公司在初期落地SRE时，都是以SRE书里面的内容作为纲领，然后无脑上的，最后发现目标非常棒，非常正确，但是实现路径没有想象中那么容易。并且在国内的行业大环境下，一些目标真的很难实现，仅限于说说就好。

下面是我认为在实践过程中一些可取和不可取的点：
 

• 可取

SRE里面的On Call轮值、应急响应、混沌工程和本身通过软件工程手段来解决运维问题是非常好的。我们在内部也都有相关平台落地，确实是给日常工作带来了很大便利，可以在业务快速增长的同时，控制团队规模不去线性增长，以及稳定性持续在一个高水位线上和科学可控的管理方法上。
 

• 不可取

在具体实践上，我们觉得招聘软件工程师在slo、错误预算、prr（Prodcution Readiness Review）这三个方面是很难做到的。这里以招聘软件工程师作为SRE组成来看，Google在03年组建SRE团队时，有几个背景，一方面google规模没那么大，另一方面国外对于OPS、PE的定义更多是系统管理员，当时对于运维体系和模型的认知还没有如今这么清晰。因此，Google首选用软件工程师解决这个问题，这在当时没有什么问题。

另外，据我所知，Google在SRE的边界、体系模型和运作方式也经历了多年的迭代和变化，并且在后续的经验积累下，形成的包括培养体系在内的体系都已经非常成熟。这个时候，从Google的角度去看，确实可以用软件工程师做SRE。以国内的情况来讲，运维这一岗位产生时间本就较晚，现在的SRE更是如此。国内企业在人员配置情况、岗位职能定义等方面也与Google存在差异。在这些大背景下，很多规模不够大的公司都不具备直接选用软件工程师作为SRE的能力，除去团队规模这一原因外，组织培养流程也是硬伤。
刘志杰“注意背后技术水平和文化的差异”

在16年Google SRE的概念引入国内后，就迅速得到了行业内众多工程师的关注。而近几年其热度不减，国内互联网的头部公司也纷纷设立了SRE的职位，可见SRE影响之深。

我个人理解，之所以Google SRE得到大家青睐，除了有硅谷公司背书外，Google SRE更代表了一类体系化的工程实践，同时也传递了一种工程师文化的理念。不得不说，在某种层面上来讲，SRE确实重新定义了传统运维，SRE体系在质量、效率、协同等方面已经打磨得很成熟，比如使用SLO/SLA去度量系统稳定性这个基本盘，并作为跨团队协同的重要依据，在应急故障管理的多人协作流程，自动化上的一些演进思考等，非常值得借鉴和学习。

当我们在实际落地的时候仍需注意要结合企业实际情况，比如小米的SRE体系，是围绕着质量、成本、效率进行展开。在落地过程中，我们要注意不要过分神化Google SRE，应以开放和谨慎的心态去面对这一件“舶来品”，在取其精华的同时，更应该注意工程实践和工程师文化背后技术水平和企业文化的差异。Q2很多人认为：SRE本质就是一个懂运维的资深开发，如何解读这种说法呢？大家对SRE这一角色，普遍存在什么认知误区？
 

史军艇“优秀的SRE需要集运维、开发、产品经理的能力于一体”

各大公司目前的SRE，如果细分的话，主要可以分为3大类，Infrastructure SRE、 Platform SRE 和 Business SRE，其中Infrastructure SRE主要负责最基础的硬件设施、网络，比较底层，一般都是很商业化的东西，动态性不强；Platform SRE提供中间件技术；Business SRE维护服务、应用、业务的正常运行，而这一类SRE是最偏向于我们说的传统业务开发的。

云原生时代下，SRE工作范畴，基本上除了纯业务研发外的所有活，都会深度参与。

开发的侧重点主要是在业务逻辑的实现、业务架构的主导，而SRE侧重的是技术架构，比如总体系统的分层模型怎么定，各层的技术方案怎么选，框架组件怎么用等。在我们公司，SRE实践了几年后，开发相比于之前还是省事了很多，项目立项完成后，SRE就会参与，包括架构方案、框架选型、集成方案等，SRE都是主导或者重要角色。所有开发可以专注于在“规范的地基上造房子”，做业务逻辑实现就可以。

SRE初期实践过程中，也踩过不少坑，第一支SRE团队主要还是以传统运维转型过来为多，虽然名字换了，还是很容易沉醉在日常事务中，他们对架构的理解以部署架构为主，思维很少有扩散到技术架构，更别说是业务架构，导致SRE和开发团队仍旧很少有共同语音。后面由于运维工具的盛行，公司会急着拉一些前后端的开发人员进入SRE，让他们主导运维转型，最终效果不佳，因为这些纯开发人员对生产系统运行的“战场”太陌生。很长一段时间，都是按需开发的模式。最终我们发现，在具备运维经验和研发能力的基础上，SRE身上还需要产品经理元素，衔接研发，要把业务架构中的某些通用逻辑，抽象出通用架构能力。衔接用户，会把系统稳定性当作一款产品去不断改良，精益求精。

云原生时代下的SRE 不仅需要 make things work，还要知道how things work。优秀的SRE除了运维功底之外，既是开发者，也是产品经理。

刘昊“运维能力常常被忽视”
 

• SRE本质就是一个懂运维的资深开发？

在某种意义上，我是认可SRE本质就是一个懂运维的资深开发这句话的，但是这里需要强调的是，一定是真正的懂运维这件事情。

我在团队里面经常讲，我们本质也是业务研发，只不过我们的业务范畴是运维这个领域。那这个问题也会引申出，一个好的研发是不是应该懂业务？

这个问题的答案也一定是要懂业务的，大家可以看看业务线的team leader和总监，每一个都是对自己所在业务领域有很深思考和建树的，因为只有这样才能通过技术去解决业务问题，产生大的业务价值和业务创新。

那再回到我们这个问题上，你只有真正的懂运维、理解运维，知道运维是从哪来？到哪去？这个时候如果你还是一名资深研发同学，那就可以通过研发的工程能力，帮助你快速解决运维业务领域的遇到的一些问题。
 

• 大家对SRE这一角色，普遍存在什么认知误区？

在国内的实践来看，大家对于SRE的目标认同感是很强的，基本上运维也都很欣然接受这一个新的岗位描述，说高级一点，是找到了职业的价值感和自我的实现途径；说通俗一点，就是SRE听起来更有逼格，比叫运维厉害多了。

但是在真正的实践过程来看，其实差异还是蛮大的，特别是我在内部进行SRE转型实践指导，很多运维同学的软件工程能力提升和思维转变没有那么快。在运维工作中，大家应该都吐槽过研发同学怎么这么xx……

在自己转型时，自己在某种意义上就切换到了研发同学的角色，该犯的错一个都没少，并且因为缺少专业的教育背景和经验，初期的这条路子会走得更坎坷。像研发对于问题的抽象、解构一样，这个能力培养是需要一定时间的。

相信每家公司的运维系统都经常会被推倒重做，这个也是因为最初以为写写代码就好，做出一个平台就好，结果发现真正距离一个高质量、高扩展性和可迭代的某类运维系统差距还是挺大的。

大家在工作中应该都有用到K8s，K8s作为云原生的基础设施，就是一个非常好的例子。通过软件的设计思想，对底层硬件设施抽象到了整个系统级别，这就是SRE思想的很好体现。我们通过K8s可以很方便的处理系统部署、调度、可观测和进行服务流量治理等工作。

最后还要补充一点：SRE还要具备一定的产品思维。因为不比业务研发是有产品的，相信很多公司的SRE、运维研发团队都是没有配备产品同学的。而SRE的平台又都是运营性质平台，不是你界面有了增删改查就ok的，这个时候对于一个SRE类产品、运维类产品的定位、设计和后期走向就至关重要。这一块的压力也同样转化到了SRE同学上面来，这个是Google书里面没有提到的一点。

另外我们也招过Google的同学，Google内部的系统也了解过，其实做得一般般，所以大家也不好神话和过度解读，更多的是把Google SRE书里面所提到的目标，结合自己的工作实践理解更透彻一些，这样会对自己的职业理解更有帮助。

最后总结一下，就是SRE实际上是一个有很高门槛，需要多领域有涉猎和积累的岗位。

刘志杰“我认为SRE是懂开发的资深运维”

虽然觉得不必太较真，但如果非要一个答案的话，我个人还是不太苟同。SRE其实是懂开发的资深运维。说到这个问题，让我想起来了前几年关于DevOps和SRE的一些讨论，我个人觉得无论DevOps还是SRE，其本质是研运一体化或深度结合。

在我们SRE体系落地过程中，一些Dev的需求有时会被SRE“叫停”，我们也偶尔也受到一些研发同学的质疑。我想说的是，其实Dev和SRE的目标是一致的，就是系统服务的健壮发展。Dev侧比较关注的是系统功能和性能的快速迭代，而SRE侧更关注系统的稳定和架构。SRE侧的”叫停“，并不是阻碍系统的发展，而恰恰是我们在为我们身后的椅子负责。我们近期也在不断摸索Error Budget等其他手段，去拉齐双方工作。Q3在实践SRE的过程中，各位老师的团队制定哪些准则来指导日常的运维工作？如何规划SRE工具链的建设，哪些能力项在目前需要着力发展？

史军艇“三大体系及八大工程”

浙江移动为例，SRE后向协同研发，前向协同客户，我们有三大体系及八大工程，贯穿了架构工程、集成工程、测试工程、演练工程、布防工程、发布工程、线上防御工程到后度量整个生命周期。把全周期切割成了三大体系：故障抵御体系、上线发布体系和交付护航体系。近两年随着故障抵御体系的慢慢健全，我们不断地把触角往前移，重点在架构工程、测试工程、演练工程方向做了不少探索。
 

• 架构工程

我们分为全局架构模型和局部单系统架构模型，统一承载在架构平台上。结合空间和渠道维度，全局架构模型可规划新入网系统落到“架构盒子”，规范异地多活、单元化、独立渠道AZ等标准。针对单系统，C4模型融合部署模型，提升硬件到代码的透视度，为上层工程做好基础，实现各系统分层架构感知，理清流量入口、外围依赖以及服务内调用。
 

• 测试工程

自主研发了流量回放平台，以接口层业务日志流量为依托，通过实时流量归档，获得真实的业务场景和数据，经过流量预处理并按不同的策略形成分片流量，在测试时按需组装后再回放至待测环境进行大并发压力测试，无需人工设计和维护用例，大幅降低测试成本，实现测试边际效益最大化。平台适用从CI/CD到线上保障的全过程。
 

• 演练工程

浙江移动结合纸牌推演和混沌演练，对每项架构点做反脆弱的失效影响分析（FEMA）和优化，确保项目入网前基本完成重点风险的提前布防布控。同时，基于沙箱环境，开展日常的红蓝对抗演练，确保始终对运维各类应急预案的反腐治理能力。“盗梦”演练平台实现故障注入及多维度编排功能，并融合了架构评级、自动化演练及红蓝对抗的能力，可助力企业高水平完成演练治理一体化。
刘昊“三大准则+三大能力项建设”
 

在实践SRE的过程中，各位老师的团队制定哪些准则来指导日常的运维工作？

在SRE实践的过程中，我们在团队内部在几年来也沉淀了很多准则，通过这些准则来知道日常的工作。具体的准则如下：
 

• On Call准则。On Call轮值不仅是SRE，更是各个团队的重要职责，这项任务的目标是保障服务的可靠性和可用性。在具体的On Call工作中，On Call同学一旦接受到报警信息，工程师必须确认（ack），On Call工程师必须及时定位问题，并且尝试解决。必要的话可以联系其他团队，或者升级（escalate）请求支援。在On Call工作的安排上，需要有主On Call、副On Call人值班，或者关系密切的团队相互作为副 On Call，互相值班，共同分担工作压力。在任何一个生产环节时间，包括事件根源分析、事件处理，以及事后总结，至少需要6个小时。每次轮值周期最多只能产生两个紧急事件，否则要触发轮值。每个工程师每个月至少要参与On Call一次，最好两次，保证有足够多的生产环境操作经验；

• 应急响应准则。该准则主要分了4块：优先止损、及时通报、故障排查和复盘总结。在优先止损中，处理故障的目标是减轻影响并尽早将服务恢复到先前的状态；在处理过程中，若10分钟内仍无法恢复或没有明确可行的恢复方案，应立刻考虑止损。常见的止损手段诸如降级、限流、切量、回滚、重启和扩容等。此阶段不需要去定位问题的根因，切记；在故障通报中，关注点是以有效的方式协调团队的响应工作，并确保响应者和故障相关团队之间的信息流通。故障发生时，将有效的信息及时同步给你的领导和相关团队至关重要。这里要注意以下几点：1、务必及时通报故障信息，因为你看到的影响可能不是故障的全部；2、及时通知到你的上级和相关团队，有利于问题的快速解决和正确处理；3、问题涉及多团队时，应拉起专项讨论群，同时在值班群定期同步事件进展：发生了什么事情（哪几件事情）？每件事情分别产生了哪些影响？每件事情当前处于什么阶段、预计什么时候恢复？每件事情接下来需要谁做什么？等等；在故障排查中，故障涉及方、当日值班人应主动牵头故障的处理和协作。
• 在“优先止损”的前提下，提供如下信息供进一步定位：1、已被引流（生产流程已切走）的故障节点；2、系统快照（KernelDump、JavaDump等）；3、日志（详细的系统日志、应用日志等）；4、监控（系统层、应用层，历史的趋势数据、和SAR细粒度的精细数据；5、链路追踪（跨组件间的 Trace、血缘 等）。最后复盘总结方面，对问题的总结是成长的最快方式。对事不对人、吸取故障的经验、以点概面地去解决隐患。这里要关注的3个要点是聚焦深度分析问题和广度评估隐患、多方商讨改进方法和制定落实改进计划。在故障结束后，由主要责任人或指定同学牵头梳理故障过程。故障报告编写应包含“事件上下文”、“关键事务的细节”、“明确可执行的计划人和时间点”，并定期回溯待改进事项。

 

• 变更管理准则。专业机构调研：90%的故障都出自于变更。管理变更对于日常安全生产至关重要，所以需要做到提前准备、适时操作、事后观测、降低风险。常态化变更包含内部主动计划内变更和外部计划内变更。在时间上，我们定义了变更窗口期，诸如规避业务高峰和特殊日期。在变更阶段上，细分变更的前中后，并且在每个阶段都有对应的变更平台和更细化的变更操作SOP，在具体落实变更操作钱进行double check，确保变更内容的一致性。
• 如何规划SRE工具链的建设，哪些能力项在目前需要着力发展？

做了这么久的SRE工具链和平台，我绝对对于一个公司比较重要的几块能力：可观测性、混沌工程，这些我就不讲了，因为业界讲得很多，并且这个也成公司技术标配了。
 

• 以应用为核心的CMDB，互联网公司一般叫做服务树。通过服务树来组织服务、业务和组织的关系，维护应用相关核心元信息；
• On Call系统。维护好组织、业务、职能和人的元信息，确保出问题能够找到对的人，并且非值班同学不会被骚扰。这个也是达成Google所说的50%时间的利器；
• 事件运营。像故障处理中经常提到的MTTR和MTBF，这些稳定性的指标如何去运营和控制提升，都需要有平台承载，通过平台将应急响应、应急协同、进展实时同步、故障覆盖等一系列事情都给串起来，避免让公司一个超级兵驱动所有事情。

刘志杰“提倡走技术运营路线”

说到准则可能偏鸡汤一些，我觉得SRE最重要的践行工程师文化，对事不对人。同时保持团队内开放包容的氛围，是让整个团队富有活力和战斗力的关键点之一。在日常运维工作中，我们提倡走技术运营路线，也建议大家使用大数据技术和自动化方案，支撑存储计算SRE体系，这样我们既是使用方又是管理员，何乐而不为。

在小米存储计算的SRE体系中，为了闭环存算服务的生命周期，我们结合存算服务自身的特点，打造了存储计算运维中台-轻舟。我们基于数仓体系构建的一套运维数据集市，为服务整体的可观测性提供有效的数据支撑。与此同时，我们在自研发布系统Minos的基础上，定制了发布系统2.0版本，在可视化集群管理的同时，也融入了低代码和任务编排的特点，解决了诸多运维痛点。在数据和发布之上，我们也构建了容量管理、巡检管理、机器故障管理等多个自动化CO模块，提升整体运维效率。Q4SRE的核心职能是保障线上服务的稳定性，但同时也对其提出了效率和成本的要求，如何平衡三者之前的关系？各位老师在实践中是如何度量评估的？
史军艇“稳定性是衡量三者的基本”

SRE关心的指标，总结起来就是以稳定性为基础，把成本和效率做到最佳（降本增效）：
稳定性：直接体现的就是MTTR和MTBF，当然细化后会有很多指标，自上而下分层，可以分为业务层、应用服务层、paas层、基础设施层。业务层焦在最终用户业务的可用性、性能方面，比如访问量、业务办理成功率、业务办理耗时等；应用服务层主要包含延迟、流量、错误和饱和度四大黄金指标；paas层偏向于基础组件以及容器云平台的控制面指标；基础设施更偏向底层，硬件、云IaaS、网络等。
成本：通过资源使用总量，单位资源的使用率做成本分析，依据分析做容量规划。
效率/效益：以运营视角、市场维度去评价架构优化后的成效。和成本相辅相成，集成效率、发布效率、系统运行效率、需求上线效率。
刘昊“稳定第一，综合综效，不断创新”

稳定性、效率和成本，不论是现在SRE还是之前的运维，都是老生常谈的三个大目标。首先稳定性一定是SRE的核心职责所在，这个从SRE的名字上就可以看出。其次，从SRE的On Call轮值和工程思维来看，我们需要通过工程化能力，其实也就是平台化能力来进行自动化，进而提升交付、变更等方面的效率。

最后一点就是成本，企业经营目标、团队价值，特别是SRE这种团队不属于营收团队，除了稳定性之外，我们需要通过成本的降低来体现团队的价值，像我们今年的大目标就是降本增效。
关于这三者的关系，在我看来他们即是独立的，又是互相依存的。比如容量规划、容量管理，即牵扯成本，又牵扯稳定性。在管理的过程中，如何高效的去管理各类资源的容量，更快速地引导SRE、研发、预算财务等角色参与进来开展工作，这都牵扯到了三块。
那再比如内部的各个变更平台，以作业为例，为了避免人工变更的低效和变更隐患带来的高风险，通过作业平台来进行管控，那这在一定程度上，即提高了变更效率，又提升了产线稳定性，还降低了人力成本。
其次，在优先级上面的话，也是一个动态平衡的关系。我以应用来举例，我们应用做了服务分级，那L0的高优先级服务，自然可以投入更多资源，确保日常的一个低水位线和更大的人力投入。而L3的低优先级服务，在配套的人力和资源方面都会有所减少。
同样，像服务等级这种服务画像属性，也是指导我们日常工作的一个关键因素。
刘志杰“降本增效的前提是要保障服务质量”

我个人理解，首先SRE要站在企业发展的角度去看待三者之间的关系，并且需要灵活调整，通常商业场上的事情是瞬息万变的，而技术发展相对滞后。比如当公司业务高速发展，这时候需要在质量的基础上适当上调效率的优先级，成本略微下调，当然一定要注意并不是完全不计成本；当公司业务稳步提升，需要精细化治理的时候，我们需要在质量的基础上适当上调成本的优先级。

其次，在小米存储计算SRE体系中我们为质量、成本、效率都定制了核心指标。用来辅助我们日常运维工作的决策。
 

• 质量：通常我们以SLO作为质量关键指标，针对HDFS、HBase、MQ等分布式系统，我们基于Request-based模型，使用独立的Canary去计量的每个服务/集群的可靠性；
• 成本：我们借助公司的云式账单模型并自建了存算运维数据集市，可度量服务任意时间维度的成本概况，做到服务/集群成本了然于胸；
• 效率：我们在自研的运维中台-轻舟上，为发布管理、容量管理、机器管理等运维功能模块定义了多维度效能指标，助力我们高效运维。

最后我想说，关于质量、成本和效率三者并不是非黑即白的，我觉得为三者相辅相成的，在自动化提升效率的同时也会提升系统质量，也会带来降本效果。而在降本的时候，我们需要尤其关注和打磨服务质量，保障质量指标维持在均线之上。Q5业务团队应该如何支持稳定性SRE人员？在故障复盘、容量规划、业务协同、SLI/SLO/SLA等方面，需要对大家提出怎样的要求？如何构建SRE稳定性运营意识？
史军艇“业务团队应该支持走完SRE的标准化体系”

企业中SRE的组织架构适配完成后，把SRE体系做起来，团队的分工和能力也会随之上来，业务团队往往离不开SRE，因为从项目立项开始，基本所有事项都是和SRE共同完成的。比如组件选型、框架的非功能适配、性能压测、标准化集成部署、演练验收等，这些工作都是一个优质项目中不可缺的步骤，业务团队应该支持走SRE的标准化体系，也是为了后面线上运行做前置条件。因为这样走完后，上线后业务团队也会很省事。大家的软件认知是同一水位的。所以从我个人经历来看，感觉业务团队对SRE的支持不用刻意去规划，是由SRE主动后双方自然而然就会达到的一种平衡。

为什么前面说优秀的SRE不仅是一个开发者，还是一个产品经理。这个产品经理必须是以客户为中心的，用运营的理念去引导整个团队的价值驱动。比如在日常方面，做好故障复盘的运营，其实复盘过程中除了技术bug的分析之外，都会有用户影响的关联。另外，对于容量规划、SLI/SLO/SLA等方面，都可以结合成本/效率的角度，融入到运营日报机制中去。这样整个团队的运营意识也会有很大的提升。
刘昊“业务团队本身就离不来SRE”
 

• 业务团队应该如何支持稳定性SRE人员？

业务团队同学如何更好配合SRE通过做好稳定性运营工作，这里更多是共识和分工。大家需要对稳定性的目标以及达到这一目标的路径、方法、行为有共识，然后是在各块具体工作上的详细分工，再接下来才是分工之间的配合。比如研发更关注的业务架构、代码质量、技术改造、服务治理这些相关职责，其次是度量监控、应急响应和服务治理这些会和SRE有更密切关联的行为。

基于这些，也就要求业务侧需要有一个懂稳定性的人，然后作为接口人去和SRE同学在工作上有更多交互。因为公司的规模上来之后，我们SRE同学再去做业务稳定性工作的时候，不可能说要去和每个研发都进行沟通，这块很困难。如果在业务团队有这样的一个角色之后，就可以把SRE的目标更清晰的传递到业务团队，并且在日常的执行上能够落实更彻底，阻力更小，能够达到双赢甚至多赢的结果。

具体方面的话，我以故障复盘这一场景，来分享下研发和SRE的分工和合作模式：

故障复盘的话，更多是一个标准和流程的事情，这块完全可以靠平台化来去覆盖和保障。从流程机制上讲，比如一个case发生之后多久需要进行复盘，复盘要达到一个怎样的目标，内容填写的细致程度，故障时间线、处理过程、隐患阶段、待办项产生等，这一些目标要求和对应的具体填写标准，SRE要写哪些，研发同学要写哪些都是需要协商好的。

这里的话，有四个点可以具体在谈一下。
 

• 一个是要让业务能够认识到复盘的价值，能够通过复盘去挖掘和暴露出日常工作中的不足点、项目架构的隐患点。这样业务会更愿意、更深度去配合搞这个事情。具体的例子比如，做复盘的时候，业务团队的team leader都不参与，那这样一线的同学肯定会懈怠，对case的整改粒度也一定不会下达到位。
• 除了找到事故发生的 root cause，还需要从中发现存在的隐患，而不是 case by case 的解决问题，复盘的目的是阻止类似的事情再次发生，必要的时候，可以引入业务、产品、技术共同解决。
• 故障复盘不能演变为批斗会，变成一个追责的过程，这样很容易导致参与复盘的各业务方陷入互相指责、洗脱责任的怪圈，从而忘记了复盘的根本目的，并且浪费大量时间，引起不必要的内耗。只要是参与复盘的人，都是有责任在身上的，需为将来的故障负责，如果类似事故再次发生，或者没有在复盘中发现应该发现的隐患，参与的人都难辞其咎。
• 复盘结果要避免惩罚为目的 —— 除非违反了规章制度（底线，不排除有些是恶法，但不在讨论范围内）。否则甩锅、不作为的氛围会日渐滋生，自省有担当和有作为的个人或者团队，很容易成为吃亏的一方。

通过看一个公司的事故复盘，能够发现这个公司各个团队组织文化和技术氛围的一个缩影情况。
 

• 如何构建SRE稳定性运营意识？

SRE稳定性运营意识，我理解是一种可以面对各种复杂工程的稳定性提升保障时思考意识。这个意识的组成也就是上面的我说的这些，像应急响应、度量监控、容量规划、变更控制、轮值和协同等。这些意识的形成，我以内部一个实习生的心态演化来举例：
 

• low：完全不懂，觉得稳定性就是做别人安排好的一些表格和梳理，不知道自己该做啥，稳定性好low；
• 烦：各种重复的会议，做好了是应该的，做不好就是责任，很烦很焦虑；
• 知道该做什么，但是累：各种报警和风险，每天需要担心，想要不管又过不了自己心里那关；大促时候天天熬夜，各种压测，最终自己累得够呛；
• 发现结合点：发现在采用系统化思维之后，稳定性与系统自身的结合变得紧密，稳定性成为一种基线，找到了稳定性中的关键点和重点；
• 主动驱动：发现线上业务和线下业务的稳定性差别，理解并主动调整在不同业务团队采取的稳定性策略，探究在稳定性中的自动化、工具化，系统化建立稳定性机制；
• 形成体系：形成稳定性体系化思考，明确稳定性每一个点在业务团队大图中的位置，探究系统弹性建设；

刘志杰“站在业务的角度，拉齐共识”

多团队协作实际上是SRE体系落地过程中绕不开的一个课题。不同团队的工作目标和方向都是不同的，而SRE的目标是为了助力业务健康有序发展。

在SRE工作开展之前最重要的就是站在业务角度，拉齐共识。实际上在目前的工作中对这点感触还是比较深的，当业务团队和SRE团队目标拉齐，并持有利他心态，能够站在对方角度思考问题和开展工作时，真的会做到相互成就、共同成长。

SRE实际上是一个非常综合性的职业，除了运维、开发的基本功外，还需要在产品管理和项目管理上有所涉猎。因此在应急响应、故障复盘、容量规划等工作开展时，SRE需要纵观全局，并且以解决方案专家的客观视角对待每个问题。

经常有人问我怎么才能成为优秀的SRE，如何才能做好SRE的稳定性工作。除了上面我们提到的点以外，优秀的SRE一定要有入局者的思维，在做到方法论和实践的有机结合更是重中之重。

最后引用曾国藩的一句话与君共勉：躬身入局,挺膺负责,乃有成事之可冀。特别鸣谢