SRE:Google运维解密(笔记)1 SRE的出现

最新推荐文章于 2025-10-08 14:35:39 发布
原创 最新推荐文章于 2025-10-08 14:35:39 发布 · 699 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#SRE

本书深入探讨了研发团队与运维团队之间的常见冲突及其原因，提出了采用SRE（Site Reliability Engineering，站点可靠性工程）作为解决方案。SRE不仅有助于缓解双方矛盾，还能提升系统稳定性与效率，书中详细阐述了SRE的实践方法与当前业界广泛应用的场景。

SRE:Google运维解密（笔记）1 SRE的出现

研发团队和运维团队的冲突引出SRE

开篇就看到书中很细致的描述了目前行业团队内部出现的问题，研发团队和运维团队出现冲突的原因，并且常常以很不友好的解决方法来处理问题，导致矛盾慢慢累积。

在这里插入图片描述

紧接着就提出用SRE来解决这种问题

在这里插入图片描述

书中还提到一个目前被广泛接受的一个场景

根据我的了解，目前行业内所有部署都遵循以下三点

在这里插入图片描述

googleSRE运维解密
weixin_44246168的博客
03-20 1459
SRE读书沉淀
《Sre google运维解密》笔记
不才的专栏
06-03 1347
Sre是什么
Sre google 运维解密
04-12
这是一本好书 ，大神作品，值得学习，上传给大家分享混点积分
网站可靠性运维，零基础入门到精通，收藏这篇就够了
最新发布
Javachichi的博客
10-08 1087
第十三章：网站可靠性运维与系统运维相比，网站可靠性运维更贴近业务，可以说是业务的大管家，每天面对各类业务事务，例如服务上线、报警处理、配合网络调整、服务监控梳理、服务例行排查、预案制定、数据备份等。网站可靠性工程师起源于Google，在其内部简称为SRE（Site Reliability Engineering，SRE需要掌握很多知识：数据算法、代码编程、大规模分布式架构、网络架构、操作系统和数据库等各个方面，还需要具备较强的故障排查和解决能力。在Google，SRE大多是资深研发工程师转岗，每位SRE都是
《SRE：Google运维解密》
weixin_33727510的博客
01-19 675
2019独角兽企业重金招聘Python工程师标准>>> ...
SRE_Google运维解密_笔记
m0_70751647的博客
10-18 1347
1.70%的事故由变更引起 2.谷歌的SRE倾向于DEVOPS，兼顾效率（快速上线更新）与质量（降低事故率） 3.SRE大致发展历程：手动（凭经验容易误操作）→自动→智能 4.缓慢的不断重启的实例优于永不重启泄露资源的实例 5.SLA（service level agreement）：请求延迟；错误率；系统吞吐量（QPS）；可用性；持久性 SLO（object）：SLI的目标范围 SLI（indicator）：从目标反推指标 6.多创新，少做琐事（DRY），但合理的琐事有助于放松 7.监控系
【读书笔记】SRE：Google运维解密 第Ⅰ部分 概览
睡觉的咖啡
08-19 586
研发团队和系统运维团队分属两个部门所带来的间接成本就没那么容易度量了，但是这些间接成本往往大得多。
《SRE：Google运维解密》读后有感
学无止境
07-22 990
当我们进行体系化的思考的后，我们就会有新的收获，并且在解决方案上更加的完善。框架和SRE平台这种模式，提供了很多的益处，比如说显著的降低运维开销，因为它支持代码结构、依赖关系、测试、编码样式指南等的强合规性测试，内置服务部署、监控和自动化，设计中自带的通用性支持，这种在框架中把基于生产最佳实践的代码模式进行标准化封装，让SRE在管理时降低了认知的负担，同时仍然可以保持服务的质量，每一个标准框架都为问题所在的领域或者问题相关的基础设市以来提供了一个完整的解决方案。，其次SRE的关注焦点在于。...
读书笔记（SRE：Google运维解密）：第22章 处理连锁故障
lo_ong的博客
11-09 516
连锁故障是由于正反馈循环（positivefeedback）导致的不断扩大规模的故障。 连锁故障可能由于整个系统的一小部分出现故障而引发，进而导致系统其他部分也出现故障。例如，某个服务的一个实例由于过载出现故障，导致其他实例负载升高，从而导致这些实例像多米诺骨牌一样一个一个全部出现故障。   连锁故障产生的原因 （a）服务器过载：直接由于服务器过载导致，或间接由于服务器过载引发的其他问题导致 例如，某个集群内部的过载可能会导致该服务实例崩溃；这时负载均衡器会将请求发送给其他集群，使那.
读书笔记（SRE：Google运维解密）：第6章 分布式系统的监控
lo_ong的博客
10-04 449
绝大部分通用的术语： （a）监控（monitoring）：收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和类型，错误的数量和类型，以及处理用时，应用服务器的存活时间等 （b）白盒监控（white-box monitoring）：依靠系统内部暴露的一些性能指标进行监控。包括日志分析、Java虚拟机提供的监控接口，或者一个列出内部统计数据的HTTP接口进行监控。 （c）黑盒监控（black-box monitoring）：通过测试某种外部用户可见的系统行为进行监控。 （d）监控台页面（d.
SRE:Google运维解密(笔记)2 监控与告警
python_bobo的博客
03-11 2199
SSRE:Google运维解密（笔记）2 监控与告警1、什么是监控？2、为什么要监控？3、4个黄金指标4、长尾问题5、设计监控需要简化6、告警误报 1、什么是监控？ 2、为什么要监控？ 最初我对监控的目的想的比较简单，以为只是监控有没有问题，有问题就发告警。 3、4个黄金指标 后来我了解的稍微多点，就知道，“有没有问题”这个几个字说的太轻飘飘了。 怎么才算有问题，服务挂掉，或者机器挂掉？还是...
SRE：Google运维解密
YAYA776的博客
02-27 963
SRE团队要承担以下几类职责： 可用性改进 延迟优化 性能优化 效率优化 变更管理 监控 紧急事务处理 容量规划与管理 所有的产品事故都应该有对应的事后总结，无论有没有触发警报（若没有触发警报，事后总结的意义更大，将揭示监控系统中的漏洞）。事后总结包括的内容： 事故发生、发现、解决的全过程 事故的根本原因 预防或者优化的解决方案 在企业中，最主要的矛盾是迭代创新的速度与产品稳定程度之间的矛盾。使用...
《SRE Google 运维解密》笔记
phantom_111的博客
03-14 2377
文章目录1. 主旨2. 概览2.1 提出 SRE 的动力？2.2 SRE 聚焦问题点2.3 庖丁解牛2.3.1 你看到了什么？2.3.2 如何管理你看到的？2.3.3 能否站在全局视角上看问题？3. 指导思想3.1 学会拥抱风险3.1.1 如何度量服务的风险？3.1.2 判断服务风险的容忍度？3.1.2 设计合适的「错误预算」3.2 服务质量目标3.2.1 指标在实践中的应用3.2.2 目标在实...
SRE-Google运维解密随记-1
砚墨
12-31 584
增加现有容量经常需要启动新的实例甚至是整个集群，这通常需要大幅度修改现有的集群配置(配置文件、负载均衡、网络等),同时还要执行一系列测试，确保新上线的容量可以正确地服务用户。虽然不论多么完备的“运维手册”也无法替代人的创新思维，但 是在巨大的时间压力和产品压力下，运维手册中记录的清晰调试步骤和分析方法对处理 问题的人是不可或缺的。、一个业务的容量规划，不仅仅要包括自然增长(随着用户 使用量上升，资源用量也上升),也需要包括一些非自然增长的因素(新功能的发布、商业推广，以及其他商业因素在内)。
SRE Google 运维解密--管理
watermelonbig的专栏
06-15 7270
一、迅速培养SRE加入on-call 在SRE团队的职责中，主动性任务和被动性任务兼有，每个SRE团队都坚守的一个重要目标是：利用积极主动的办法，去减少和限制被动性工作的产生。 SRE培训课程 推荐的培训方式 错误的培训方式 设计一个具体的、有延续性的学习体验，以便学员跟进 通过给学员安排一些烦琐的工作（处理警报/工单）来培训
SRE Google运维解密_读书笔记1
snlying的专栏
07-15 898
监控的4个黄金指标：错误、延迟、流量、饱和度（容量）。 SLO服务水平目标，健康度检测使用 运维平台： 关于应急管理时，有没有考虑过通过一键触发的方式，将当前紧急情况通过内部通讯工具、邮件、短信等渠道触达到系统相关人。这样可以实时看到当前系统处理情况，调配各种资源协助，根据故障情况决定是否升级保障，记录整个应急处理各时间点的过程，也便于编写事后总结报告。当前应急处理时大家忙于处理问题，内部通讯...
SRE Google运维解密-第一章
intheafk的博客
03-06 876
研发（Dev）与运维（Ops）分离导致的问题 直接成本： 随着产品及项目增多，相应人员线性增加。 间接成本： 研发与运维团队背景各异，技术能力与工具使用习惯存在差距，工作目标不同； 研发与运维团队对产品可靠程度要求不同，具体执行某项操作的危险程度评估与技术防范措施不同。 以上逐渐演变成目标与方向上的分歧及形成沟通问题，容易出现信任、尊重等问题 如何减少更新故障—以下两点均不是最优 运维：给研发制定严格上线流程； 研发：不再大规模更新，而是转为功能开关调整、增量更新、补丁等方式..
SRE:Google运维解密(心得)
python_bobo的博客
03-06 2967
SRE:Google运维解密（心得）风险与可用性错误预算总结： 风险与可用性 在一个运行的系统中，出现风险是不可能避免的，而运维工程师的存着便是控制并解决风险。 书中提到构建百分百可靠的服务是不可取的，因为一个服务面向用户的不止是可靠，还有创新。当可靠性达到一定的数量级后，再花费大量的成本在可靠性上而忽略服务的创新，这种方式得不偿失。 书中还提到可用性为多少个‘9’这个概念 上面提到额外一个‘9...
1.SRE：Google运维解密 --- 介绍
enlyhua的专栏
06-03 1441
1.系统管理员模式 负责将现成的软件组件部署到生产环境中，对外提供某种业务服务。系统管理员的主要工作在于应对系统中产生的各种需要人工干预的事件，以及来自业务部门 的变更需求。开发部(Dev)和运维部(Ops)。 Dev/Ops 分离的团队模型的存在的问题： 1.直接成本 2.间接成本 研发团队和运维团队背景各异，技术能力与工具使用习惯上差距巨大，工作目标也截然不...
从ITIL到SRE：唯品会运维自动化转型实践解析
这份资料以唯品会在2013年至2017年期间运维体系的演进为核心，展示了企业如何在面对大规模业务需求和技术挑战时，从基于ITIL的流程驱动模式逐步转向以SRE（站点可靠性工程）为导向的自动化运维模式。 首先，ITIL...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值