- 综合排序
- 最热优先
- 最新优先
- 来自专栏SRE转型
SRE转型：不同团队规模下的银行SRE团队组建策略
原文链接：【SRE转型】不同团队规模下的银行SRE团队组建策略摘要：本文分析了银行在不同规模团队下的SRE转型策略。 本文将深入探讨不同规模团队的SRE组建策略，分析基础架构SRE、工具SRE、业务SRE的定位。02.不同规模银行IT团队的SRE组建策略在银行SRE转型过程中，团队规模是规划组建策略的重要因素之一。 快速构建稳定的SRE基础能力，为后续扩展做准备。2）中型银行（IT团队规模：30-100人）特点：具备一定的资源，能够实现更细化的团队职责分工。新业务需求和传统系统维护并存，需要权衡稳定性和创新性。 2）工具SRE（Tools SRE）职责：开发和维护支持SRE活动的内部工具和平台，提高开发与运维的效率。支撑所有其他SRE团队的工作，通过工具化手段提升可靠性与自动化水平。 小团队先从核心需求切入，逐步扩展；中大型团队需注重职能分工和操作规模的统一。2）循序渐进的技术演进快速构建基础能力，如监控、自动化部署等，作为SRE转型的基础。
45900编辑于 2025-02-13 SRE 转型关键：SRE 与 DevOps 团队如何高效协作
2.自动化与基础设施管理：自动化是SRE的一项重要原则，它帮助减少人为错误并提高效率。SRE团队负责实施自动化运维，涵盖了从自动化部署到自动化监控、自动化故障修复等多个领域。 2）DevOps团队的主要职责DevOps（Development and Operations）是一种文化与实践模式，旨在打破开发与运维之间的壁垒，通过加强协作、自动化和持续反馈提升软件交付的速度和质量 2.持续集成与持续交付（CI/CD）：DevOps团队负责设计和实施持续集成和持续交付（CI/CD）管道。这些自动化流程能够帮助银行系统在不断变化的环境中，快速、高效地交付新功能或修复。 2.推动自动化与效率：SRE与DevOps都注重自动化，推动从代码部署到故障恢复的各个环节的自动化，以提高运维效率和开发速度。 2）SLO与CI/CD的结合在DevOps中，持续交付要求开发团队能够频繁交付新功能，而在SRE中，服务级别目标（SLO）则确保系统在发布和更新过程中不会影响用户体验或系统稳定性。
23310编辑于 2026-01-30- 来自专栏SRE转型
深度剖析：银行 SRE 转型中 SRE 与 DevOps 团队的协作
2.自动化与基础设施管理：自动化是SRE的一项重要原则，它帮助减少人为错误并提高效率。SRE团队负责实施自动化运维，涵盖了从自动化部署到自动化监控、自动化故障修复等多个领域。 2）DevOps团队的主要职责DevOps（Development and Operations）是一种文化与实践模式，旨在打破开发与运维之间的壁垒，通过加强协作、自动化和持续反馈提升软件交付的速度和质量 2.持续集成与持续交付（CI/CD）：DevOps团队负责设计和实施持续集成和持续交付（CI/CD）管道。这些自动化流程能够帮助银行系统在不断变化的环境中，快速、高效地交付新功能或修复。 2.推动自动化与效率：SRE与DevOps都注重自动化，推动从代码部署到故障恢复的各个环节的自动化，以提高运维效率和开发速度。 2）SLO与CI/CD的结合在DevOps中，持续交付要求开发团队能够频繁交付新功能，而在SRE中，服务级别目标（SLO）则确保系统在发布和更新过程中不会影响用户体验或系统稳定性。
30500编辑于 2025-03-18 - 来自专栏SRE转型
银行SRE转型：如何突破传统运维困境，打造高效团队
2） SRE组织的特点与传统运维组织不同，SRE组织强调通过工程化手段提升系统的可靠性和可维护性，同时注重团队间的跨职能协作。 具体任务如下：2.人员安排规划高层支持：IT总监与运维负责人提供战略指导和资源保障。试点团队组成：2~3名资深运维工程师，负责梳理系统现状及优化流程。1~2名开发工程师，负责自动化工具的开发与实施。 2）核心能力建设1.打造SRE核心能力，夯实基础设施完成启动阶段后，SRE团队需要集中精力，建立可靠性的关键能力和工具体系。 具体任务如下：2.人员安排规划外部支持：IT总监与运维负责人提供战略指导和资源保障。核心团队扩展 至5~7人：3人负责监控与自动化工具建设。2人专注故障响应与性能优化。 具体任务如下：2.人员安排规划团队规模扩展至10~15人：按业务模块划分小组，确保每个小组都与业务目标紧密对接。设立业务联动机制：为每个SRE小组配备1名业务负责人，推动技术目标与业务目标一致。
49510编辑于 2025-02-08 - 来自专栏老张的求知思考世界
《SRE实战手册》学习笔记之认识SRE
； 最佳实践：业内稳定性领域的最佳实践是Google SRE； 1、SRE包含哪些工作事项 稳定性规范制定，监控、压测、服务治理、大促稳定性保障、故障应急管理、组织架构建设； 2、SRE常见的问题与困惑 2、SRE认知误区 管理的角度：SRE就是一个具备全栈能力且能解决所有稳定性问题的岗位； 运维的角度：做好监控，快速发现问题、快速定位问题根因； 平台的角度：加强容量规划，学习Google做到完全自动化的弹性伸缩 提升稳定性的2个措施：提升故障时间间隔，降低故障修复时间，SRE以这两个指标为宗旨。 7、DevOps和SRE的协同 7.1：DevOps以驱动价值交付为主，搭建企业内部功效平台，SRE需要协调多团队合作来提高稳定性。 如： 与开发和业务团队落实降级； 在开发和测试团队内推动混沌工程落地； 与开发团队定制可用性衡量标准； 与开发、测试、devops、产品团队，共同解决代码质量和需求之间的平衡问题； 7.2：SRE解决运维领域的故障目标
1.8K10编辑于 2022-04-01 - 来自专栏老张的求知思考世界
《SRE实战手册》学习笔记之切入SRE
监控体系是SRE体系中很重要的组成部分，也是最直观的指标产出展示方式。 2、常见的监控指标 3、选择监控指标的考量点 两个因素 要衡量谁的稳定性？ SLO方式计算：Availability=SLO1&SLO2&SLO3（即综合维度的指标衡量）； SLO1：99.95%状态码成功率； SLO2：90%RT<=80ms； SLO3 参考：推动稳定性共识机制的2个指导原则 预算充足或者未消耗完之前，对问题的发生要有容忍度； 剩余预算消耗过快或即将消耗完之前，SRE 有权中止和拒绝任何线上变更； 从推行的角度来讲，涉及到跨团队沟通共识机制 一定要自上而下推进周边团队或利益方达成共识。 2.4基于错误预算的告警 监控告警有一点很重要的是告警降噪收敛。即不要被“狼来了”的告警搞定疲惫不堪，要有对应的处理机制。 2、设定SLO的四大原则 2.1核心应用的SLO要更严格，非核心应用可以放宽。这么做是为了确保SRE精力能够更多地关注在核心业务上； 2.2强依赖之间的核心应用，SLO要一致。
2.2K10编辑于 2022-04-01 - 来自专栏XINDOO的专栏
DevOps和SRE
SRE是你让一个软件工程师组件一个运维团队的产物，它本质上是一个实体，是一个团队一个工种，是对DevOps的实践。 - DevOps 和SRE建立在变革的基础上了，没有改变何谈提升。 - DevOps的核心是协作，SRE的核心是共享。但两者的主要价值都是贯穿整个组织把各个团队联结在一起。 无论是实践还是理论，SRE和DevOps都得用数据说话。 - 在管理生产服务的过程中总是免不了出问题，SRE和DevOps都实行不问责的事故处理方式。 或者，换句话说，SRE相信与DevOps相同的东西，但原因略有不同。 作为一个具体的职业，SRE对他们产生的影响高度敏感，反而对信息壁垒不太关注。 SRE支持持续集成和持续交付不是因为商业需求，而是因为持续集成和持续交付涉及到运维。 换句话说，SRE和DevOps相信同样的事，但不是因为同样的原因。
97520发布于 2021-01-21 - 来自专栏云云众生s
SRE与AI
AI能够根据业务目标推荐更加贴合的标准和优先级，比任何一个人类团队都要快速高效。 当思考Site Reliability Engineering(SRE)以及使软件可靠的一般概念时，很容易看到AI可以发挥重要作用。 以系统监控和服务指标(SLO)为例，这是SRE领域两个常见难题。概念上它们很简单。系统监控就是观察系统输出以确保正常运行。 有了这种视角，它们可以比任何人类团队用更少时间和精力提出更符合业务目标的标准和优先级。 依赖AI视角的风险 归根结底，期望是一个可以分析大量业务数据和目标并提出建议的AI模型。 AI学习工具可以帮助跨团队欣赏和对整个系统有更全面的视角。想象“请求每个服务领域的PowerPoint摘要，并按使用数据细分”并在几分钟内得到结果。
56610编辑于 2024-03-28 - 来自专栏老张的求知思考世界
《SRE实战手册》学习笔记之SRE落地实践
5、On-Call机制的优势 1）最快最好的熟悉系统的方式； 2）培养和锻炼新人以及backup角色； 3）新人融入团队和承担责任的最佳方式； 故障处理：恢复业务为最高优先级 在MTTR环节中，MTTK 典型案例：互联网的SRE组织架构 在SRE体系中，高效的故障应对和管理工作，需要整个技术团队共同参与和投入。 )； 2、系统架构的演变历程 要引入SRE体系，并做对应的组织架构调整，首先要看技术架构是否朝着服务化和分布式方向演进。 要想在组织内引入并落地SRE体系，原有技术团队的组织架构或协作模式必须要做出一些变革。 3、互联网组织架构示意图 基础设施：传统运维这个角色所具备的能力。 平台服务：包括常见的技术中台(有状态的数据产品研发团队)和业务中台(无状态的具有业务共性的业务研发团队)以及业务前台(H5&前端&移动端产品研发团队)。
3.4K10编辑于 2022-04-01 - 来自专栏IT运维技术圈
老杨聊SRE 团队建设全攻略：从 0 到 1 的组织进化
许多团队用它来对齐研发和运维的节奏。 • Google SRE 的建议是把重复劳动（toil）压到 50% 以下。因为人力应该放在工程化，而不是一遍遍点按钮。 老杨的观点很直接。 把这三条落到制度里。 老杨把定义写成配置，团队都能看懂。 /... route: receiver:feishu-sre group_wait:30s group_interval:2m repeat_interval:1h routes: -match: 事项 负责 R 协作 A 咨询 C 知会 I SLO 制定 业务 TL SRE TL PM、测试 全员 告警规则 SRE 业务 开发 全员 发布策略 开发 SRE 测试 全员 事故响应 值班 SRE 开发 • 事故管理：飞书多维表 / 企业微信应用；小团队可用 GitLab Issues 做行动跟踪。 选型只看三件事。 可观测性统一。权限可控。回滚简单。
54910编辑于 2025-10-09 - 来自专栏SRE运维实践
云原生SRE
2 为什么需要云原生SRE？ 所有的这些，也就促成了云原生SRE的诞生，云原生SRE属于平台级运维，属于数据化运维，如果这些SRE有脑子的话，那么可以摇身一变，变成智能化运维。 ? 高端的产品必然有高端的食材，这就是云原生SRE的舞台。 3 云原生SRE的核心能力 数据化运维，对于各种微服务来说，前端的数据，中间的数据，后端的数据，存储的数据，各种各样的数据，各种各样的APM，收集数据，存储数据，分析数据，利用数据，数据服务化
1.6K30发布于 2020-12-22 - 来自专栏运维开发故事
SRE食用指南
SRE 是谷歌提出的理念，旨在做到以应用为中心，以稳定为前提，做到自动化、智能化、平台化，需要工程师的技术能力拉满： 会产品 会开发 会测试 会运维 会架构 大家一看到这，就直接把 SRE 拉黑了， 在我看来，SRE 并非一定特指某个人，而是一群人，如果一个公司只招一个 SRE，要么公司不知道 SRE 是什么，要么公司是傻逼中的战斗机。 目前国内玩 SRE 玩的比较好的都是大厂，比如百度、蚂蚁、腾讯等，他们的团队规模都很大，这么大团队，如果每个人都会上面的技能，那会是什么场面？ 有的人可能会认为会是技术爆表，业务稳定的一 B，而我认为那将是一场灾难：如果一个团队有一个厉害的人，他将是标准，如果一个团队有十个厉害的人，那将有 10 个标准，如果一个团队 100 个人都厉害，那将混乱不堪 ，所以我想那些大厂的 SRE，也不都是全才，但是至少都有一技之长。
41530编辑于 2022-12-06 - 来自专栏让技术和时代并行
SRE最佳实践
什么是站点可靠性工程(SRE)? 站点可靠性工程(SRE)的概念起源于谷歌。这个想法与DevOps的原则密切相关。它是It运营的一种方法。SRE团队使用软件来管理系统、解决问题和自动化操作任务。 SRE团队将IT团队完成的任务(通常是手工完成的)交给工程师或运维团队，后者使用工具和自动化来解决问题和管理生产系统。 在创建可伸缩和高度可靠的软件系统时，这是一种有价值的实践。 为什么SRE很重要?好的SRE团队需要具备哪些条件? SRE就像是软件工程和IT操作之间的桥梁，填补了它们之间的空白。在几乎所有地方，SRE都在为生产系统中的故障做准备时发挥作用。 SRE的主要目标是提高性能和运行效率。 所以，SRE不仅仅是负责编码的行动人员。另外，SRE是开发团队中拥有不同技能集的成员，特别是在部署、配置管理、监视、度量等方面。 总结 这篇博文试图涵盖建立成功的SRE团队所需的基本概念和实践。如果您计划在您的项目/组织中采用SRE文化，请培训您的团队，遵循最佳实践，并信任该过程。你不可能做到100%的完美。这是一个神话。
1.9K20编辑于 2023-03-18 - 来自专栏SRE运维进阶之路
SRE 学习路线
SRE 工作职责 要制定学习路线，首先我们要搞情况 SRE 的工作职责。 SRE/稳定性保障具体措施包括但不限于： 高可用性： 确保系统能够在大部分时间内持续提供服务，即使在出现故障或意外情况下也能够快速恢复。常见的高可用性措施包括冗余设计、故障转移、负载均衡和容错机制。 当指标超出预定的阈值时，自动触发警报通知相关团队，以便及时采取措施。 文档和知识共享：记录系统的配置、架构和故障处理经验，以便团队成员之间进行知识共享和技能传承。 SRE 稳定性保障体系 SRE 主要工作是保障稳定性，稳定性就是不出故障，围绕着故障周期，整理出 SRE 稳定性保障体系。 SRE RoadMap 根据工作职责和稳定性保障体系，整理出学习路线。
78521编辑于 2024-04-23 - 来自专栏锅总
锅总浅析SRE
这些工具帮助SRE团队实现自动化运维、提高系统可靠性、降低人为错误，并使系统具有更好的可观察性和可维护性。 沟通与协作 团队协作：与开发团队、运维团队和其他相关团队紧密合作，确保系统的稳定运行。 文档编写：编写和维护相关文档，确保知识的共享和传承。 11. 顶级SRE或团队主管：年薪可以超过 $200,000，有些大型科技公司可能提供更高的薪酬和股票期权。 中国 在中国，一线城市（如北京、上海、深圳）的SRE薪资相对较高。 初级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 - 来自专栏SRE转型
SRE转型：银行 SRE 转型与 SLO 管理的深度融合
2）制定服务级别目标（SLO）服务级别目标（SLO）是SRE管理服务质量的核心，通过为每个关键服务设定明确的可靠性目标，SLO帮助团队量化和控制系统性能。 2）挑战二：多样化的业务需求与客户期望银行的业务场景极为复杂，不同业务领域、不同客户群体对系统的可用性、性能等方面的要求不同。在这种情况下，设定统一的SLO目标显得尤为困难。 应对策略：与合规团队协作：SRE团队在制定SLO时，必须与合规团队紧密合作，确保SLO目标符合金融行业的法规要求。 SRE团队需要定期与开发、业务、合规等团队沟通，确保目标的一致性，并及时调整应对策略。 业务对接专员能够帮助SRE团队准确理解业务需求，同时也能帮助业务团队理解SLO目标的重要性。
39210编辑于 2025-02-13 - 来自专栏云计算与大数据
SRE的能力建设
sre关注点与能力建设
1.2K10发布于 2019-12-03 - 来自专栏AI科技大本营的专栏
干货：NIST评测（SRE19）获胜团队声纹识别技术分析 | CSDN博文精选
作者 | xjdier 来源 | CSDN博文精选 (*点击阅读原文，查看作者更多精彩文章） 近日，NIST说话人识别技术评测 (Speaker Recognition Evaluation，SRE） NIST SRE是由美国国家标准与技术研究院主办的国际上最权威、规模最大的声纹识别技术评测和多媒体评测，为全球的研究机构提供了一个统一的测试平台。 从1996年举办至今，参加NIST SRE评测的研究机构逐年增加，今年有包括MIT，JHU，NEC等各国顶尖学术科研机构和公司参加。 除了传统的LDA，PLDA进行信道补偿并给出似然比分数，团队在中心化、白化、自适应策略上也进行启发式搜索。本文将团队在此次声纹识别竞赛中的关键技术点整理如下。 于是，团队还需要通过信道补偿算法来减少这种影响。
1.6K20发布于 2020-02-12 - 来自专栏乌龟哥哥默认学习专栏
SRE 运维解密
SRE团队。 2）从技术到业务从监控、事故响应、事后回顾、测试与发布、容量规划、开发到用户体验这七层的递进，可以看出SRE运维不只是单纯的技术栈（主机、存储、基础软件设施等）的设备运维，SRE还逐步延伸业务运维领域， 2）日志采集能力，除了传统的指标数据采集外，针对于目前显得越来越重要的日志数据，监控工具也需要支持常见日志采集、切割、结构化以及入库分析能力。 个人不应该害怕事故，而是确信如果事故发生，团队将会响应和改进系统。我认为SRE的一个关键共识正是承认了系统的不完美性，追求永不停机的系统是不现实的。 与开发团队来共同承担。除了测试外，应用发布也是一项运维团队通常要承担的责任。SRE的一个原则是将一切可以重复性劳动代码化和工具化；此外，应用发布的复杂程度往往与系统的复杂程度成正比。
88600编辑于 2023-09-29 - 来自专栏嘉为动态
《Google SRE》读后感
SRE是个全能手，DevOps的实践者 SRE全称：Site Reliability Engineering，翻译过来就是：站点可靠性工程师。 之前参加的“软件工程的精益化管理”课程实验中，实践证明了自动化工具的威力很大，能够明显提升整个团队的生产力。 反思 and 总结 这两个优点对于SRE很是重要，反思使得SRE从失败中学习教训，总结使SRE从时间中获得经验，个人和团队需要学习和践行这种精神，但是对事不对人。 如果开发团队牛逼，代码质量高或者运气好，你可以迭代快，反之你需要慢点来，间接地，大家都对线上系统负责了。 10. 反直觉的真理 1、不要承诺你的系统100%可靠。 2、有意识地破坏你的系统 不同于演练，而是真实生产系统，在可控范围内，人为制造故障，然后在有人值守的情况下，找到系统的短板和问题。这样等到真正的故障来临时，可以有章可循，快速解决问题。
3.1K40发布于 2018-12-21
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号