“优秀的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等其他手段，去拉齐双方工作。

在实践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模块，提升整体运维效率。

SRE的核心职能是保障线上服务的稳定性，但同时也对其提出了效率和成本的要求，如何平衡三者之前的关系？各位老师在实践中是如何度量评估的？

“稳定性是衡量三者的基本”

“稳定第一，综合综效，不断创新”

“降本增效的前提是要保障服务质量”

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

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

最后我想说，关于质量、成本和效率三者并不是非黑即白的，我觉得为三者相辅相成的，在自动化提升效率的同时也会提升系统质量，也会带来降本效果。而在降本的时候，我们需要尤其关注和打磨服务质量，保障质量指标维持在均线之上。

业务团队应该如何支持稳定性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一定要有入局者的思维，在做到方法论和实践的有机结合更是重中之重。

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