- 综合排序
- 最热优先
- 最新优先
- 来自专栏SRE转型
SRE转型：银行 SRE 转型与 SLO 管理的深度融合
直达原文：【SRE转型】从理念到实践：银行 SRE 转型与 SLO 管理的深度融合摘要：本文探讨了银行在SRE转型中如何通过SLO管理提升系统可靠性与业务连续性。 涉及关键词：银行、SRE转型、SLO、业务连续性01.引言随着金融行业的数字化转型加速，银行面临着越来越复杂的技术环境和日益增加的运营压力。 因此，银行在进行SLO管理转型时，除了需要解决技术挑战，还需要在组织文化、流程优化等方面进行调整，以确保能够顺利过渡到更加灵活、高效的SRE模式。 2）制定服务级别目标（SLO）服务级别目标（SLO）是SRE管理服务质量的核心，通过为每个关键服务设定明确的可靠性目标，SLO帮助团队量化和控制系统性能。 2）挑战二：多样化的业务需求与客户期望银行的业务场景极为复杂，不同业务领域、不同客户群体对系统的可用性、性能等方面的要求不同。在这种情况下，设定统一的SLO目标显得尤为困难。
39210编辑于 2025-02-13 SRE 转型关键：SRE 与 DevOps 团队如何高效协作
本文来自腾讯蓝鲸智云社区用户: CanWay直达原文：【SRE转型】银行SRE和DevOps团队的协作摘要：本文通过深入分析SRE和DevOps在银行中的角色与职责，详细阐述了它们在核心协作点上的紧密配合 涉及关键词：银行运维，SRE转型，DevOps协同01.引言在现代银行的信息化转型过程中，系统的稳定性、性能和灵活性变得尤为重要。 两者的结合，为金融行业的数字化转型提供了有效的支持，尤其是在保证高可用性和灵活性的同时，能够支持快速部署和频繁迭代。2）银行面临的挑战银行的运维面临着多方面的挑战。 2.自动化与基础设施管理：自动化是SRE的一项重要原则，它帮助减少人为错误并提高效率。SRE团队负责实施自动化运维，涵盖了从自动化部署到自动化监控、自动化故障修复等多个领域。 2.推动自动化与效率：SRE与DevOps都注重自动化，推动从代码部署到故障恢复的各个环节的自动化，以提高运维效率和开发速度。
23310编辑于 2026-01-30- 来自专栏SRE转型
深度剖析：银行 SRE 转型中 SRE 与 DevOps 团队的协作
直达原文：【SRE转型】银行SRE和DevOps团队的协作摘要：本文通过深入分析SRE和DevOps在银行中的角色与职责，详细阐述了它们在核心协作点上的紧密配合，尤其是在自动化流程、SLO与CI/CD的结合 涉及关键词：银行运维，SRE转型，DevOps协同01.引言在现代银行的信息化转型过程中，系统的稳定性、性能和灵活性变得尤为重要。 两者的结合，为金融行业的数字化转型提供了有效的支持，尤其是在保证高可用性和灵活性的同时，能够支持快速部署和频繁迭代。2）银行面临的挑战银行的运维面临着多方面的挑战。 2.自动化与基础设施管理：自动化是SRE的一项重要原则，它帮助减少人为错误并提高效率。SRE团队负责实施自动化运维，涵盖了从自动化部署到自动化监控、自动化故障修复等多个领域。 2.推动自动化与效率：SRE与DevOps都注重自动化，推动从代码部署到故障恢复的各个环节的自动化，以提高运维效率和开发速度。
30500编辑于 2025-03-18 - 来自专栏SRE转型
银行 SRE 转型，模式推广策略剖析
直达原文：【SRE转型】银行SRE模式推广策略摘要：随着数字化转型的深入，SRE（Site Reliability Engineering）模式作为一种全新的运维理念，逐渐在银行业得到了应用。 2）SRE模式在银行推广的注意事项SRE（Site Reliability Engineering）模式作为一种现代运维与开发的融合方法，强调通过工程手段和自动化提升系统可靠性。 2.组织文化与协作模式：银行传统运维团队以稳定性为核心目标，而SRE更强调在容忍失败的基础上提升效率，这种理念需要逐步渗透和落地。 以下是不同维度的梳理方法及其作用：2）业务系统服务类型划分的考量银行系统的服务类型直接影响其SRE实践的应用模式。 以下是针对不同类型银行系统的SRE应用模式分析和实施策略：04.各系统的SRE推广计划1）推广优先级SRE模式推广的优先级应基于 服务类型、技术架构和业务现状 综合评估，以下是优先级划分的建议：2）组织保障为了确保
35910编辑于 2025-03-04 - 来自专栏SRE转型
SRE转型：不同团队规模下的银行SRE团队组建策略
原文链接：【SRE转型】不同团队规模下的银行SRE团队组建策略摘要：本文分析了银行在不同规模团队下的SRE转型策略。 涉及关键词：银行、SRE转型、团队建设01.引言在银行IT团队推进SRE（站点可靠性工程）转型过程中，不同规模的团队在实践落地的方式上存在显著差异。 快速构建稳定的SRE基础能力，为后续扩展做准备。2）中型银行（IT团队规模：30-100人）特点：具备一定的资源，能够实现更细化的团队职责分工。新业务需求和传统系统维护并存，需要权衡稳定性和创新性。 2）工具SRE（Tools SRE）职责：开发和维护支持SRE活动的内部工具和平台，提高开发与运维的效率。支撑所有其他SRE团队的工作，通过工具化手段提升可靠性与自动化水平。 2）循序渐进的技术演进快速构建基础能力，如监控、自动化部署等，作为SRE转型的基础。随着团队能力提升，引入更高级的技术（如IaC、全链路监控、AIOps），实现递进式优化。
45900编辑于 2025-02-13 - 来自专栏腾讯技术工程官方号的专栏
云原生背景运维转型之 SRE 实践
作者：yorkoliu，腾讯 IEG 业务运维专家 一、前言 上一篇文章《云原生背景下的运维价值思考与实践(上)》 重点介绍了云原生背景下运维转型的思考，围绕着整个 DevOps 交付链，贴近业务不断输出运维的能力与价值 本文的出发点也是站在巨人肩膀之上，结合自身业务服务场景，思考在云原生背景下，运维转型还有多少种可能性，本文或许只给出其中一种答案吧。 图3.1 - SLO跟踪统计报表 四、工具链建设 SRE 的准则与方法论固然重要，但没有强有力的工具链来作为支撑，在执行面将面临步步维艰，因此我们在 2 年前就开始着手规划 SRE 工具链的建设，根据 图6.3 - 精简流程，提升效率 2）故障注入原子 玄图混沌平台能够模拟的故障非常丰富，通过故障原子组合可以模拟出云服务异常，机器故障，操作系统故障，网络故障，应用层故障，以及根据特定场景定制的故障等。 如图 7.1 所示，QPS 到 1 万的时候，资源负载是 20%，根据经验预估 QPS 到 3 万负载到 60%，容量是充足的，流量涨 2 倍没问题。
3.3K20编辑于 2022-01-17 - 来自专栏SRE转型
银行运维SRE转型：挑战与应对策略
2）错误预算（Error Budget）错误预算是SRE实践中的重要工具，它定义了系统在一段时间内可容忍的故障范围。 2）传统架构与新型SRE架构的融合许多银行仍然使用传统的单体应用架构或是混合架构，这与SRE模式的要求（尤其是微服务、容器化及云原生架构）存在一定的差距。 2）制度与流程建设SRE的实施不仅需要合理的组织支持，还需要有完善的制度和流程来保障高效运转。 APM应用性能监控：可以帮助SRE团队追踪分布式系统中的请求流，及时识别性能瓶颈和故障源。2.自动化工具自动化是SRE的核心原则之一，它能显著减少人工干预，提高系统的一致性和可靠性。 SRE通过对系统运行状态的持续监控和智能化运维，能够快速发现和解决潜在的风险，保障系统的高可用性。2）支持新兴技术的应用SRE团队通过监控、自动化和弹性设计，可以为银行快速迭代的新技术提供支撑。
65310编辑于 2025-02-08 - 来自专栏东风微鸣技术博客
「笔记」某电信公司转型 SRE 运维体系交流
痛点 •传统竖井式IT架构（封闭、隔离、非标、难运维） •X86 服务器硬件稳定性不足 •开源软件可靠性不足，且不可控 •出了故障，被动救火救不完 转型 由此催生了转型升级的需求： 1.运维智能（SRE ）的转型 SRE运维模式 核心职责 保证： 1.业务连续性 2.应用连续性 3.平台连续性 职责分工 1.综合运维岗1.7*24 在线或远程值班 2.业务监控 3.业务运维操作 4.故障处理 5.应急处理 2.运维专业组（由基础架构的：主机、存储、网络、中间件、数据库岗位演化而来） 1.系统架构梳理和优化 2.新建系统评审 3.故障演练 4.新技术引入 5.专业职责和经验赋能给综合运维岗，如提供数据库自动化脚本 、数据库切换演练流程标准化等 3.运维开发 1.为综合运维岗开发运维工具、运维系统 2.收集分析运维专业组自动化、监控等需求 3.DevOps、自动化运维、智能监控系统、容器平台等系统开发和持续迭代演进
65430编辑于 2022-04-22 - 来自专栏SRE转型
银行SRE转型：如何突破传统运维困境，打造高效团队
摘要：银行SRE团队的建设是应对数字化转型挑战的关键策略。本篇文章详细分析了传统运维与SRE的差异，并通过分阶段的转型路径说明了如何从规划到核心能力建设，再到全覆盖推广，逐步构建高效的SRE团队。 涉及关键词：银行、SRE转型、团队建设01.引言随着金融行业数字化转型的加速，银行面临着越来越复杂的技术环境和运营挑战。 2） SRE组织的特点与传统运维组织不同，SRE组织强调通过工程化手段提升系统的可靠性和可维护性，同时注重团队间的跨职能协作。 3）银行传统运维和SRE组织的对比03.SRE团队组建面对传统运维模式的转型需求，组建一个高效的SRE团队需要系统的规划和分阶段实施。 1名安全工程师，确保转型符合行业合规要求。2）核心能力建设1.打造SRE核心能力，夯实基础设施完成启动阶段后，SRE团队需要集中精力，建立可靠性的关键能力和工具体系。
49510编辑于 2025-02-08 - 来自专栏老张的求知思考世界
《SRE实战手册》学习笔记之认识SRE
； 最佳实践：业内稳定性领域的最佳实践是Google SRE； 1、SRE包含哪些工作事项 稳定性规范制定，监控、压测、服务治理、大促稳定性保障、故障应急管理、组织架构建设； 2、SRE常见的问题与困惑 2、SRE认知误区 管理的角度：SRE就是一个具备全栈能力且能解决所有稳定性问题的岗位； 运维的角度：做好监控，快速发现问题、快速定位问题根因； 平台的角度：加强容量规划，学习Google做到完全自动化的弹性伸缩 提升稳定性的2个措施：提升故障时间间隔，降低故障修复时间，SRE以这两个指标为宗旨。 1、衡量可用性2种方式 一个是时间维度，一个是请求维度，计算公式如下： 时间维度：Availability=Uptime/(Uptime+Downtime)：从故障角度对稳定性进行评估； 请求维度：Availability =Successful request/Total request：从成功请求占比角度出发，对系统稳定性进行评估； 2、衡量稳定性的三要素 衡量指标：如系统请求状态码； 衡量目标：如非5XX占比达到95%
1.8K10编辑于 2022-04-01 - 来自专栏老张的求知思考世界
《SRE实战手册》学习笔记之切入SRE
理解SRE中的指标和目标 SRE强调稳定性，一般是看整体的系统情况，也就是常说的"3个9"、"4个9"这样可量化的数字。 监控体系是SRE体系中很重要的组成部分，也是最直观的指标产出展示方式。 2、常见的监控指标 3、选择监控指标的考量点 两个因素 要衡量谁的稳定性？ SLO方式计算：Availability=SLO1&SLO2&SLO3（即综合维度的指标衡量）； SLO1：99.95%状态码成功率； SLO2：90%RT<=80ms； SLO3 参考：推动稳定性共识机制的2个指导原则 预算充足或者未消耗完之前，对问题的发生要有容忍度； 剩余预算消耗过快或即将消耗完之前，SRE 有权中止和拒绝任何线上变更； 从推行的角度来讲，涉及到跨团队沟通共识机制 2、设定SLO的四大原则 2.1核心应用的SLO要更严格，非核心应用可以放宽。这么做是为了确保SRE精力能够更多地关注在核心业务上； 2.2强依赖之间的核心应用，SLO要一致。
2.2K10编辑于 2022-04-01 - 来自专栏XINDOO的专栏
DevOps和SRE
之前总是把SRE和DevOps混为一谈，总觉得这两个是同一种东西在不同公司的叫法，知道前两天google又放出了《The Site Reliability Workbook》 ，书中对比了SRE和DevOps 无论是实践还是理论，SRE和DevOps都得用数据说话。 - 在管理生产服务的过程中总是免不了出问题，SRE和DevOps都实行不问责的事故处理方式。 - 归根到底，DevOps或SRE是一种全局工作，两者都希望通过某种特定的方式使得分散的部分组织协同的更好。 速度是SRE和DevOps都想要的结果。 或者，换句话说，SRE相信与DevOps相同的东西，但原因略有不同。 作为一个具体的职业，SRE对他们产生的影响高度敏感，反而对信息壁垒不太关注。 SRE支持持续集成和持续交付不是因为商业需求，而是因为持续集成和持续交付涉及到运维。 换句话说，SRE和DevOps相信同样的事，但不是因为同样的原因。
97520发布于 2021-01-21 - 来自专栏云云众生s
SRE与AI
当思考Site Reliability Engineering(SRE)以及使软件可靠的一般概念时，很容易看到AI可以发挥重要作用。 以系统监控和服务指标(SLO)为例，这是SRE领域两个常见难题。概念上它们很简单。系统监控就是观察系统输出以确保正常运行。
56610编辑于 2024-03-28 - 来自专栏老张的求知思考世界
《SRE实战手册》学习笔记之SRE落地实践
这个环节，主要做两件事： 1）判断出现的问题是不是故障（主要依赖于监控和告警体系）； 2）确定由谁来响应和召集人进行处理（需要一套明确清晰的决策及消息分发机制）； 这两件事，其实就是SRE中的On-Call 3、建立有效的应急响应机制 3.1流程机制 1）故障发生后，On-Call的SRE最开始是IC，有权召集相关角色和资源，快速组织线上消防； 2）如果问题和恢复过程非常明确，IC仍是SRE不做转移，由他指挥每个人要做的事情 )； 2、系统架构的演变历程 要引入SRE体系，并做对应的组织架构调整，首先要看技术架构是否朝着服务化和分布式方向演进。 2、SRE落地如何以赛带练？ 以赛带练的策略放在系统稳定性建设中非常适用。 通过选择类似的真实且具备高压效果的场景，来充分暴露稳定性存在哪些问题和薄弱点，然后有针对性地进行改进。 场景如下： 1）核心应用变更及新应用上线评审； 2）周期性的技术运营以及汇报工作场景； 概括总结：实践是检验SRE的唯一标准 落地实践，小步快跑胜过考虑太多！
3.4K10编辑于 2022-04-01 - 来自专栏SRE运维实践
云原生SRE
2 为什么需要云原生SRE？ 所有的这些，也就促成了云原生SRE的诞生，云原生SRE属于平台级运维，属于数据化运维，如果这些SRE有脑子的话，那么可以摇身一变，变成智能化运维。 ? 高端的产品必然有高端的食材，这就是云原生SRE的舞台。 3 云原生SRE的核心能力 数据化运维，对于各种微服务来说，前端的数据，中间的数据，后端的数据，存储的数据，各种各样的数据，各种各样的APM，收集数据，存储数据，分析数据，利用数据，数据服务化 serverless 所谓的serverless，表面意思是无服务器，初步意思是serverless=faas+baas，也就是函数计算和后端服务，都使用api的方式来进行调用，现在的各种数字化转型
1.6K30发布于 2020-12-22 - 来自专栏运维开发故事
SRE食用指南
作者：乔克 博客：www.jokerbai.com SRE，多么美妙的一个词，它就像黑暗中的一盏明灯，为运维指出了前进的路。 但是，国内大部分企业的运维人员对 SRE 都不感冒，觉得它就是理论的巨人，根本无法落地实践。 SRE 是谷歌提出的理念，旨在做到以应用为中心，以稳定为前提，做到自动化、智能化、平台化，需要工程师的技术能力拉满： 会产品 会开发 会测试 会运维 会架构 大家一看到这，就直接把 SRE 拉黑了， 在我看来，SRE 并非一定特指某个人，而是一群人，如果一个公司只招一个 SRE，要么公司不知道 SRE 是什么，要么公司是傻逼中的战斗机。 目前国内玩 SRE 玩的比较好的都是大厂，比如百度、蚂蚁、腾讯等，他们的团队规模都很大，这么大团队，如果每个人都会上面的技能，那会是什么场面？
41530编辑于 2022-12-06 - 来自专栏人力资源数据分析
人才数字发展转型（2）
1、 培训课程的录制 我们平时都有很多线下的课程，可以对线下的课程进行现象的视频录制，然后进行编辑剪辑，可以作为线上的课程素材 2、 在线课程的设计 培训人员可以根据课程规划，进行微课的设计，一般微课都是以多媒体的形式呈现
45020发布于 2020-01-02 - 来自专栏让技术和时代并行
SRE最佳实践
什么是站点可靠性工程(SRE)? 站点可靠性工程(SRE)的概念起源于谷歌。这个想法与DevOps的原则密切相关。它是It运营的一种方法。SRE团队使用软件来管理系统、解决问题和自动化操作任务。 为什么SRE很重要?好的SRE团队需要具备哪些条件? SRE就像是软件工程和IT操作之间的桥梁，填补了它们之间的空白。在几乎所有地方，SRE都在为生产系统中的故障做准备时发挥作用。 SRE的主要目标是提高性能和运行效率。 所以，SRE不仅仅是负责编码的行动人员。另外，SRE是开发团队中拥有不同技能集的成员，特别是在部署、配置管理、监视、度量等方面。 既然我们知道了为什么SRE很重要，那么让我们继续讨论在拥抱SRE文化时必须遵循的SRE最佳实践。 SRE最佳实践 在实现SRE时，您可能需要一些时间来改进您的策略和定制实践，以满足您的操作需求。 引用 https://sre.google/sre-book/service-best-practices/ https://opensource.com/article/18/10/sre-startup
1.9K20编辑于 2023-03-18 - 来自专栏SRE运维进阶之路
SRE 学习路线
SRE 工作职责 要制定学习路线，首先我们要搞情况 SRE 的工作职责。 SRE（Site Reliability Engineering）站点可靠性工程是一种结合软件工程和运维运营原则的角色和方法论，旨在在系统、服务或产品的设计、开发、部署和运维过程中，采取一系列措施来确保其持续稳定运行 SRE/稳定性保障具体措施包括但不限于： 高可用性： 确保系统能够在大部分时间内持续提供服务，即使在出现故障或意外情况下也能够快速恢复。常见的高可用性措施包括冗余设计、故障转移、负载均衡和容错机制。 SRE 稳定性保障体系 SRE 主要工作是保障稳定性，稳定性就是不出故障，围绕着故障周期，整理出 SRE 稳定性保障体系。 SRE RoadMap 根据工作职责和稳定性保障体系，整理出学习路线。
78521编辑于 2024-04-23 - 来自专栏锅总
锅总浅析SRE
SRE与传统运维的区别 理念不同：SRE强调用软件工程的方法来解决运维问题，而传统运维更多依赖手工操作和经验。 自动化程度：SRE更注重自动化，尽量减少人为干预；传统运维则可能依赖较多的手工操作。 SRE需具备关键能力 SRE（站点可靠性工程）需要具备一系列关键能力，以确保系统的可靠性、性能和可扩展性。以下是一些SRE需具备的关键能力： 1. 2. 自动化能力 自动化运维：开发和维护自动化运维工具，减少人为干预，提高工作效率。 配置管理：使用Ansible、Puppet、Chef等工具自动化系统配置和部署。 3. 初级SRE：年薪大约在 ₹700,000 到 ₹1,200,000 之间。 中级SRE：年薪大约在 ₹1,200,000 到 ₹2,000,000 之间。 高级SRE：年薪大约在 ₹2,000,000 到 ₹3,000,000 以上。 顶级SRE或团队主管：年薪可以超过 ₹3,000,000，有些大型科技公司可能提供更高的薪酬和股票期权。
1.2K10编辑于 2024-08-05
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号