随着数字化进程的加速，企业业务对IT系统的依赖程度不断攀升，系统的稳定性和效率成为企业发展的关键因素。为解决由于业务规模快速增长带来的问题，谷歌提出SRE这一概念。
SRE是系统稳定性工程的简称，它是软件工程与系统运维的结合，通过可靠性架构演进、变更风险的管控、监控与应急能力的完善等措施，确保系统在高负载和复杂环境下仍能可靠运行，实现对外承诺的服务目标。SRE 转型已成为企业实现系统稳定运行的重要举措。
但是，SRE转型之路并不是一帆风顺的，有些企业实现了成功转型，有些企业在SRE转型的探索过程中遇到了很多问题，例如，怎么界定SRE工程师的工作职责，怎么培养SRE文化，如何构建适配于SRE的组织架构，怎么实现传统运维向SRE的过渡等等。
为了可以让企业更好的向SRE转型，技术社群的这篇文章《企业SRE转型之路十大难点和解决方案》邀请了金融行业SRE专家分享SRE转型的前沿理念与实践经验，值得学习了解。
【难点 1】领导要求企业传统运维转向SRE运维，重点要了解哪些方面？
首先，高层领导要求企业SRE转型，要明确实际目标，是政策原因、降本增效还是企业实际诉求等，不同目标方向类似结果天差地别。明确领导的实际诉求，才能确定高层领导对转型工作中整体预算、团队沟通等工作的支持力度。其次，执行转型任务的主管经理，对转型任务的解读和正确工具的选择也是一项挑战。市面上包含大量或商业或开源的工具。在跟厂商沟通中要减低其对自身产品夸大程度，降低信息噪声，根据自身企业实际情况选择合适工具，否则就是浪费时间和资源。最后，SRE转型是全企业相关各部门的问题，而非转型部门单独的任务。对工作任务的解读以及宣贯工作，能有利的推动转型工作。如果各相关部门对工作不理解，需要消耗极大的沟通成本，甚至转型工作会出现南辕北辙的情况。我觉得“传统运维转向SRE运维”，通常取决于一些背景，可以具体分析传统运维什么情况下需要转SRE能力转变，并不是所有企业都需要进行SRE能力转型的。1.短期已经出现瓶颈，而SRE的理念能够解决这个瓶颈；2.当前没有瓶颈，但是预判后面会出现不足，比如规模增加人员保持不变、系统越来越复杂等；以上3点如果有1-2个，我觉得可以推进SRE能力转变。在领导对转型SRE的必要性、转型的价值已经有所了解和思考的情况下，作为执行者，我更建议在“如何转型”上面思考，给领导更明确的建议：1.同业调研，看看先进同业在SRE转型方面的规划和实践，比自己摸索要容易点。2.制定自己的SRE转型规划，要结合同业及自身的情况，明确转型目标、转型路径，从哪里开始转，短中期重点工作是什么等等，确保转型有序推进。3.其他专家也提到转型最重要的是人。所以，打算如何构建SRE文化，梳理SRE工程师的能力要求，开展SRE工程师的培养，建立相应的组织架构及考核方法，也是需要考虑的。4.转型所需要的成本分析。比如说人员调整，平台工具引进等等。【难点 2】传统IT团队如何快速转变为专业的SRE团队，主要存在哪些挑战？
1.对内观念转变：SRE价值文化，保障可用性为目的的自动化思维。2.对内刻画系统风险的故障管理：好的故障管理收集跟进是SRE 团队的Dashboard。3.对内SRE 工具自动化的开发要求：监控发现、自动化止损和无人值守开发能力。4.对外标准：技术开发和测试可用性要求左移能力的push驱动能力。SRE强调采用软件工程的思路去推动稳定性保障工作，解决稳定性保障遇到的问题。要求SRE需要具备软件工程的能力，但由于传统IT团队的人员流动性不高，企业里的人员能力上不会发生很大变化，所以，员工个人能力是很多企业SRE转型的挑战。但是，运维组织最关键的不是转变成为什么样的团队，而是做对的事，做适配于运维组织价值的事。如果当前已经面临痛点，就要预测接下来还可能遇到痛点，再去考虑转型。总的来说，当前运维团队的核心价值并没有发生根本性的变化。SRE中所提到的一些文化、人员能力、重点工作，更适合对现有流程机制进行优化。所以，需要分析SRE中强调的内容，结合自身的禀赋，选择能够帮助自身去帮助实际运维价值的措施，去推动相关措施的落地。转型企业要进行SRE团队建设转变的最大挑战在于文化和能力。文化上，要解决的是现有的员工转型意愿。如果是推着他们转，事倍功半。但如果是他们主动要转，事半功倍。所以，有时候加一两条鲶鱼很有用。能力上，现有团队能力提升太慢了。如果确定要转型，找1-2个这方面的专家，或者相对有经验点的人。有老师带着走会少走很多弯路，也会比自行摸索快得多。【难点 3】SRE岗位的人才如何培养？需要掌握哪些技能？
SRE培养需要专业的指导和培训、实践，这块国内还是很缺，主要是缺真正的SRE专家。SRE需要掌握的技能很多，核心在于意识、技术感悟力。如果没有技术感悟力，成为不了一个好的SRE。实际技能方面，需要懂研发，应用研发、工具研发，然后懂基础设施、懂OS、懂数据库和数据分析，懂产品、懂架构等等，懂学科交叉。SRE的全局架构能力应该是比较关键的能力。很多大厂把工作职责分的太细，不具备真正的全局架构能力，所以合格的SRE可能很少。2.制造危机感，或者引入一些鲶鱼，让大家自觉动起来。我让你转，远远比不上我自己要转。这个是一门艺术。3.SRE完全转型难度可能很大，可以先从某些点开始。SRE的职责那么多，要做的事情那么多，可以分批分阶段。4.梳理典型典范，让大家跟着榜样走。也能在一定层面形成一种力争上游的竞争局势。5.至于你问题提到，是内部人员转SRE，还是从外部引入，我觉得可以两者相结合。老人也不能抛弃，要给他们进步转变的机会。但外部也要引入，鲶鱼很重要。跟不上团队节奏的，该淘汰就淘汰。一个优秀的SRE专家，一定是从实战中锻炼出来的。通过实操进行培养，把他放在这个岗位，一开始不一定给他提很宏大的目标，分阶段制定不同的目标，这个季度提升这个系统的监控发现率，下个季度进行这个系统的架构分析和研发，识别这个系统架构的优化点，下下季度分析过去一年的故障响应情况，找到故障应急的改进方法……一段时间下来，他会找到方法的。但是，未来的路，还需要他自己在上面继续钻研和投入。总的来说，不管内部培养，还是开发人员转型、运维人员转型，都可以，但是目标不能变。- 稳定性是核心职责，这也是SRE岗位跟之前运维相关岗位的名称(像SA、OP、PE等)之间最大的区别；SRE这个岗位在名称中重点突出了岗位目标——稳定性，而SA、OP、PE等岗位名称则没有明确出目标；
- 然后SRE人员需要通过建设工具、平台、基础设施的建设来提高效率；
- 最后一个核心目标是成本，连同上一个点——效率，可以用一个现在比较流行的词来概括——「降本增效」。这个点之所以重要，原因是多方面的，可以明确的是现在企业(当然也包括互联网行业)对成本控制的重视程度是越来越高了。
SRE也可以切实的通过技术手段来达成“优化服务运行成本”的目标，这也是SRE团队对于企业的一个重要价值体现。提供一个行业内共识的数据，SRE团队的百分之七十的人员需要具备代码能力，这一点对于实现SRE目标是有必然联系的。1.知识（一专多能）：① 监控管理 ② 应急事件处理 ③ 问题根源分析 ④ 测试、发布 ⑤ 互联网安全 ⑥ 敏捷开发 ⑦ 产品设计；2.专业技术：① 精通云计算平台 ② 掌握GitLab等研发运维平台 ③ 熟悉Linux 、Docker、K8s等主流互联网技术；3.行为技巧：① 灾难预案与演习 ② 书写事后总结的文化 ③ 自动化与降低日常运维负载 ④ 结构化的、理智的决策；4.经验资格：① 专注可靠性设计的经验 ② 用户体验经验 ③ 安全经验。SRE需要用软件工程的思维思考运维，需要围绕系统稳定性，主动串连起软件生命周期。即需具备：1.系统架构师：清楚应用系统部署架构，懂应用逻辑架构，掌握上下游系统、高可用、容灾架构等，即既要推动基础设施团队打造可靠的基础设施（比如云），也要推动研发、架构师在应用架构层面的可靠性。2.业务架构师：清楚核心业务功能业务逻辑，当核心功能不可用，甚至一笔关键交易异常时，能够及时发现，并快速应急解决，或利用混沌工程加强业务风险点。3.可用性工程师：善于利用工具，落实可用性改进，容量规划，延迟优化，性能优化，业务架构优化，应急演练，应急预案编写等工作。4.运营分析师：具备数据思维，能够让系统运行，业务运作，客户体验，流程管理等数字化，并利用掌握的运营数据驱动研发、测试、业务持续优化。5.软件工程师：具备能够以软件工程师思维，借助工具解决问题、消灭问题的能力。6.运维操作员：各类监控发现、舆情感知、故障应急、根因分析、系统巡检、咨询反馈、变更交付、IT服务等工作。【难点 4】SRE体系建设主要包含哪几个方面的内容？
SRE体系建设取决于服务器数量，应用系统数量，机房规模，行业性质等方方面面，在建设SRE体系初期可以尝试组建一个小的运维团队，包括基本的系统，网络，数据库，安全等运维人员，SRE体系后期根据发展需要再扩容器，虚拟化，自动化等人员，总之什么样的环境需要匹配对应的SRE团队保障，当然，保障质量也有关系，SRE体系建设是多方面的，需要分阶段来建设，切勿一次性，毕竟团队人员的认知和理解上都很多不一致的地方，希望我的建议能给你带来一定的参考价值。相较于运维，SRE更聚焦在系统的稳定性，我建议从能力角度推动建设方向，以下举例一些，具体是哪些还需结合企业自身情况而定：1.故障的可恢复：① 运维左移到架构韧性、高可用的架构设计 ② 运维左移到系统配套的应急工具（区别于运维外挂式的N板斧） ③ 系统上线后对系统架构韧性的评估与优化 ④ 应急预案 ⑤ 业务连续性计划；2.性能的可扩展：① 容量管理 ② 性能压测 ③ 弹性基础设施；3.业务的可监控：① 数据埋点 ② 业务、功能、体验、错误层面的的监控 ③ 传统运维监控；4.问题的可观测：① 可观测的三驾马车(metrics、logging、tracing) ② 运行感知；5.变更的可管控：① 变更场景 ② 变更防御 ③ 变更前风险评估 ④ 故障的变更定位；6.配置的可管理：① CMDB ② 部署数字化 ③ 资产 ④ 效能和成本。【难点 5】SRE团队的工作成效如何评价，从哪些维度体现其工作价值？
工作成效的评价主要从几个方面进行，第一就是可靠性保障，第二是应急，第三是效率提升，第四就是资本化。SRE的核心职责是保障系统的稳定性和高可用性。可以通过SLA（服务级别协议）、SLO（服务级别目标）和SLI（服务级别指标）来量化系统的稳定性表现。例如，系统的可用性是否达到99.9%或更高，故障恢复时间（MTTR）是否在可控范围内。SRE团队在故障发生时的响应速度和处理能力是重要评价指标。包括故障发现的时间（MTTD，Mean Time to Detect）、故障恢复的时间（MTTR），以及事后是否能够通过事故复盘（Postmortem）总结经验，避免类似问题再次发生。SRE团队通过自动化工具和流程优化减少人工干预，提升运维效率。可以通过自动化覆盖率、手动操作减少量、发布频率（如CI/CD流水线的效率）等指标来衡量其工作成效。SRE团队在保障系统稳定性的同时，还需关注资源利用率和成本控制。例如，通过容量规划、资源调度优化和云成本管理，降低基础设施成本。【难点 6】针对生产环境系统未知的故障原因，SRE如何做好快速响应？
故障定界，只需要故障位置，不需要追究故障原因。针对故障位置采取响应的应急措施，例如：2.同城双活系统站点级故障，且只有单站点故障，直接切流。1.具备快速的排查能力，排查故障对象或关联对象近期是否有变更。前提是需要对变更进行精细化管理，实现变更目录管理，明确变更所实施的对象，以及关联影响对象。这里的对象包括网络设备、存储、服务器硬件、OS、软件等，甚至上层的应用，应用颗粒度最好去到模块级别。2.可预见故障场景的梳理。一般依赖于对历史故障的总结以及专家的头脑风暴，通过可预见故障场景，明确故障现象、监控告警的表现，以及相应的定界方法和应急方法。这个过程很难，对于一些典型的故障很有效，但覆盖面很难做全。3.大量的故障没法用经验覆盖，需要完善工具的建设，通过工具实现数据的联动，为定界分析提供更多的信息输入。方法上，可以基于专家的经验，也可以基于AI技术的应用。例如：· 建设基于专家规则的排障引擎。技术专家提前定义各类告警发生后所需要检查的指标项，告警发生后可以一键自动检查，通过指标的检查情况，可以快速缩小排查范围。· 基于横向交易调用链的分析和纵向的资源拓扑分析。主要还是基于CMDB数据以及全链路数据、告警数据的整合，是一种很有效的手段。· AI技术的应用，短期内还处于探索阶段，暂时普适性还不是很强，可以保持探索。· 定界方法有时候需要综合应用，单靠一个手段很难包打天下。所以，业界有人在告警界面实现“定界看板”，本质上就是把各个定界工具的信息进行整合展现，给技术专家提供辅助。生产环境保障业务可用性是第一优先级任务。根据系统的架构，通过隔离、切换等方式将故障设备与实际业务分隔开。根据各系统告警时间信息和业务逻辑上下游状况确定故障具体系统，根据报错现象和各模块报错日志确定故障的直接原因。如果重大问题，需要追根究底的分析故障根本原因，可以使用鱼骨分析法。【难点 7】SRE如何改进监控与应急处置流程，以减少故障对业务的影响？
要减少故障对业务的影响，其实就是要加快故障的应急处置效率，缩短故障影响时长。结合我们的实践，可以从监控、定界、应急、协同上面来改进。在监控上，最主要是要快速发现故障，避免跑冒滴漏，不要动辄这个故障没发现，那个故障也没发现，那缩短应急时长就无从谈起了。
1.加强监控系统的架构健壮性设计，不能因为局部问题导致全局监控服务不可用，不能数据采集中断也一无所知。加强告警风暴抑制能力的建设，减少风暴对值班的干扰；对告警级别进行梳理和优化，明确每个告警级别的处理要求和处理时效，让致命告警真的是致命的，值班人员才可以专注处理致命、重要告警。2.要开展监控告警的治理，对一些不合理的指标、不合理的策略进行治理，要推动监控完整性的补全。定界是最难的，直接影响了应急的速度。目前业界定界能力的做法，可以笼统归为三类。1.专家流派。基于专家经验进行应急预案、应急场景的梳理，再将这些预警、场景与告警关联。通过历史故障的梳理、头脑风暴，可以补充很多这类经验。在某些故障场景下，这种实践准确度挺高，但局限性也很明显，多数故障无法枚举，也不可预见。2.技术流派。通过AI或者规则引擎，在告警发生后触发进行诊断。比如排障树、一键体检、故障根因分析等，都属于这种流派，对企业的技术能力要求更高，从同业情况来看，目前没有达到预期效果，属于还在不断迭代改进中。现在很多企业都提出了应急三板斧或者六板斧，本质上就是明确应急能力，并尽量通过脚本、菜单来实现，降低应急的操作复杂度。这里重点提几点：1.如果有同城双活系统，基础设施层的故障切流是最有效最快的解决方式。但是，程序层面或者数据层面，切流无能为力。3.所有应急能力，要想办法和监控对接，最好可以直接从告警直接一键触发（不一定自动，每个企业对风险的容忍度不一样）。4.如果有一线值班团队的话，要想办法把一些标准故障场景下的应急能力交接给一线团队，在明确的故障场景发生后（比如告警中明确告知某系统某交易在某数据中心成功率下跌，某数据中心正常），一线值班人员可以直接执行切流操作。协同很多人会忽视，但对应急秩序的维系至关重要。例如：1.建立明确、大家认可的应急响应流程、定义清晰的应急响应级别，梳理明确的应急响应分工。2.在故障发生后，值班经理或者指挥官要第一时间触发响应流程，定义初始的响应级别，用系统工具开始call人、开权限、开门禁，要维系应急现场的秩序，让网络、数据库、系统、应用各司其职，该检查的要检查，该反馈的要反馈，该上升的要上升，该报告的要报告……一般情况下，这些协同工作应在协同系统上实现。SRE可以推动监控细化分层来加快对故障排查定位的时间，从而降低故障对业务的影响。健全应用层、中间件层、数据层、网络层、平台层等全方位监控体系，通过统一告警平台归集起来，平台还需做好告警汇聚工作，将重复告警汇总显示，降低信息噪声。由于各系统业务实际情况不同，也需要做差异化调整。完善的监控告警系统需要长期打磨，不是一蹴而就的。SRE也可以将应急处置流程从优先解决故障转变为优先恢复业务，先通过隔离等手段恢复业务，在业务已经恢复的情况下慢慢进行故障处理。通过自动化的手段将各系统的应急手段统一归纳，尽可能缩短人为处理时间。监控方面，需要覆盖多维度的指标，比如应用性能、基础设施、日志和链路追踪。这能确保全面发现问题。动态阈值和异常检测比静态阈值更灵活，能适应业务变化，减少误报。统一监控平台整合数据，避免信息孤岛，方便团队协作。告警管理方面，分级和收敛是关键。优先级划分确保紧急问题优先处理，告警去重和依赖分析避免信息过载。自动化根因分析能加速故障定位，比如通过机器学习或预设规则。应急处置方面，标准化预案和自动化工具必不可少。预案需要详细步骤和责任人，定期演练保持更新。自动化如故障自愈和弹性扩缩容能快速恢复服务。灰度发布和回滚机制减少变更风险，避免全量故障。事后必须进行复盘，分析根本原因，优化系统。持续改进监控规则和预案，形成闭环。还要考虑如何将监控与CI/CD集成，实现持续反馈，预防问题复发。【难点 8】SRE工程师在软件的设计、开发阶段应提出哪些标准规范来提高系统的可靠性、性能及安全性？
这类标准和规范，我们会以非功能性需求的形式，在项目研发阶段就给研发项目组。1.NAS的规范。主要规定NAS在不同应用使用的使用，比如，各个应用之间非必要不复用NAS卷、任何程序或代理禁止直接调用NAS中的可执行文件。2.端口规范。主要是确保应用启动的端口在允许的端口段之内。3.架构规范。比如应用模块必须支持负载均衡架构，原则上不允许复用等等。4.监控规范。规范每个应用、应用模块必须输出什么内容。5.目录规范。主要规范每个目录的的使用。什么信息该放在什么文件系统下。6.日志规范。主要规范应用日志的输出规范及要求，比如必须支持循环日志，最长保存多久等等。7.数据库规范。包括表设计规范等等。比如大表必须分历史表和当前表，大数据量更新必须分批提交，分区表要提前创建等。8.应用规范。主要规范了应急六板斧，应用在在研发阶段必须实现的应急能力。以上内容是一部分片段，应根据工作环境实际需求做增加或裁剪。1.可靠性方面，SRE需要推动容错设计，比如服务降级、熔断机制，这样在部分故障时系统还能运行。还有冗余设计，确保关键组件有备份，避免单点故障。另外，设计时考虑故障自愈能力，比如自动重启或切换备用节点。可能还会要求设置合理的超时和重试策略，防止级联故障。混沌工程测试可能也是一个点，定期模拟故障来验证系统的健壮性。2.性能方面，性能指标的定义和监控是关键，比如延迟、吞吐量、错误率等。SRE需要推动容量规划，通过压力测试确定系统的瓶颈，并预留资源缓冲。代码优化规范，比如减少数据库查询次数、使用缓存、异步处理等。分布式系统的设计原则，如负载均衡、分片处理，避免热点问题。可能还会要求性能测试自动化，确保每次发布都符合标准。3.安全性方面，安全设计原则如最小权限原则、数据加密传输和存储。漏洞管理流程，包括依赖库的安全扫描和及时更新。身份认证和访问控制机制，比如OAuth、RBAC。输入验证和输出编码，防止注入攻击。安全审计和日志记录，便于追溯和分析事件。威胁建模也可能被引入，提前识别潜在风险。4.标准化和自动化，比如CI/CD中的自动化测试、代码审查规范、发布流程的灰度发布和回滚机制。文档化要求，确保系统架构和运维流程清晰。此外，可能涉及资源隔离，比如容器化部署避免相互影响。不过，可能有些点需要更具体，比如在开发阶段的具体实践，如代码规范中的错误处理、日志记录标准，或者监控指标的埋点要求。另外，SRE强调SLO（服务等级目标）的定义，确保开发团队和运维团队对系统可用性有共同的理解。还有容量规划中的弹性伸缩策略，自动扩展以应对流量高峰。【难点 9】如何选择运维工具，进而提高运维工作效率和准确性？
根据实际工作环境，从投入成本、团队规模、技术栈、员工素质等多方面综合考虑， 决定是开源自研还是商业采购。首先，要了解当前团队的技术水平。无论如何培训，短时间内很难将团队技术水平提升一个层级，所以当前的水平决定了运维工具的投入成本和整体规划。团队技术薄弱需要完全借助商业采购，因此投入成本会高于预期情况。技术实力雄厚并且团队成员有足够的精力迭代产品可以考虑使用自研产品。1.必须明确实际需求，避免因为跟厂商沟通后需求被带跑。一个组织在开展运维工具体系的建设的时候，非常需要考虑组织目前的整体技术水平、工具建设现状以及成本预算。如果组织整体规模比较小，自研能力相对薄弱，目前工具属于一穷二白，那现在有很多一体化的工具可以直接买，开箱即用。如果企业规模大，运维开发资源充足，预算充足，我更倾向于自研，或者基于开源+自研，或者基于商业产品+定制。方法有很多，看自己的选择。在选择开源产品或商用产品的时候，POC是一种很有效的方法，不要单纯听销售介绍，自己测过还是王道。如果有预算，可以拉几家公司一起POC，一起PK，你会发现一来二往，你会成长很快。但切记，不要人浮于事，要沉下去了解每家公司的产品，否则你了解的，只是别人给你灌输的。从工具层面，我觉得可以有两类：一类是技术平台，一类的是景工具。1.技术平台是指监、管、控、析等通用技术平台，这些技术平台通常有一些行业成熟的商业化或开源解决方案。2.场景工具与运维工作场景相关，每一个场景涉及多个工具的融合。技术平台的选型重点关注可扩展性、成本，此时选择行业主流技术方向是一个比较好的方向。对于场景工具则需要广泛与用户沟通，选择与公司、团队禀赋相匹配的工具。总的来说，不是最全面的工具是最好的，适合自己的才是最好的。【难点 10】SRE在银行业中是否适用？在哪些方面可以提升效率和系统稳定性？
SRE思维在运维领域应用的范围内均适用，专职的SRE工程师要具体情况具体分析。一个行业的范围太大，应该关注本公司具体情况，包括当前工作环境的技术实力、成本规划等。SRE可以从优化架构和加快故障解决等角度提升系统稳定性；。提效方面，建立敏捷架构，推广敏捷CI CD方法，提高开发团队效率；从优化故障解决、系统上线等工作时间角度，提高运维团队执行效果。SRE强调聚焦系统稳定性的运行保障，并鲜明的提出了人员能力上需要有软件工程能力，需要加强系统架构韧性、容量性能管理、应急管理等。这些工作与银行业当前 的工作类似，最大的区别是工作投入的比例发生变化。例如：1.SRE 在系统稳定性的运维左移与平台工程方面的投入程度会提高很多，这两块能够提升效率和系统稳定性。2.SRE 需要更加了解系统，并左移到软件生命周期上线前的设计与变更准入环节，推动系统架构韧性的故障可恢复、性能可扩展，以及系统业务监控、可观测能力非功能性需求的落地。3.在平台工程方面，需要运维人员更加主动的推动平台化的工作模式与管理策略的落地。
通过广泛的讨论和业内诸多专家的经验分享，通过“如何SRE”和“SRE该做什么”两个主要角度解析了在SRE转型工作中遇到的痛点和难点。通过整合SRE团队建设和SRE工作任务这两个角度的多个议题，形成一套与SRE相关的方法论。抛砖引玉，给各企业SRE转型任务作为参考：
（一）SRE团队建设
1.在准备转型SRE之前，要明确转型的目的，确定转型的必要性。
2.转型过程中，通过文化宣传等方式推动员工从被动转型变为主动转型。
3.能力方面，SRE对员工能力要求较高，培养周期较长，推荐由SRE专家带领团队从实战中逐步走向成熟。
4.SRE体系建设主要围绕可靠性、应急和降本增效三个角度，根据实际需求安排任务优先级。这也是SRE的价值体现。
（二）SRE工作任务
1.SRE最直观的价值体现是应急快速响应。明确保障业务可用性作为应急流程的首要任务。根据故障定界结果采取针对性动作快速恢复业务。
2.SRE通过完善监控体系、自动化应急操作和优化协同流程等多个角度进一步缩短应急流程，加快业务恢复速度。
3.由于变更是故障主要来源之一，规范化的变更也能降低故障发生概率。因此。推动变更标准化也是SRE工作的重要组成部分。
4.SRE可以推动运维工具落地，通过平台化的工具增加运维工作中的自动化占比，提高工作效率，降低人为操作失误。
综上所述，SRE工作和文化都能进一步提高企业运维质量。在要求系统稳定性越来越高的当下，SRE团队能产生举足轻重的作用。但由于SRE岗位对个人能力要求较高，即使有专家带领，仍需要较长周期才能完成团队建设。“好风凭借力，扬帆正当时。”
如果您认为这篇文章有些帮助，还请不吝点下文章末尾的"点赞"和"在看"，或者直接转发朋友圈，
