【SRE】读Google运维解密的总结思维导图

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

#SRE #网站可靠性工程师 #运维 #运维解密 #google运维解密

最近研究了一下sre，阅读了一本好书《google运维解密》，知识脉络总结如下：在这里插入图片描述

运维职场精英必须熟悉的武器库，yyds
互联网老辛
03-31 2147
运维职场精英必须熟悉的武器库
googleSRE运维解密
weixin_44246168的博客
03-20 1478
SRE读书沉淀
《Sre google运维解密》笔记
不才的专栏
06-03 1370
Sre是什么
网站可靠性运维，零基础入门到精通，收藏这篇就够了
最新发布
Javachichi的博客
10-08 1121
第十三章：网站可靠性运维与系统运维相比，网站可靠性运维更贴近业务，可以说是业务的大管家，每天面对各类业务事务，例如服务上线、报警处理、配合网络调整、服务监控梳理、服务例行排查、预案制定、数据备份等。网站可靠性工程师起源于Google，在其内部简称为SRE（Site Reliability Engineering，SRE需要掌握很多知识：数据算法、代码编程、大规模分布式架构、网络架构、操作系统和数据库等各个方面，还需要具备较强的故障排查和解决能力。在Google，SRE大多是资深研发工程师转岗，每位SRE都是
SRE:Google运维解密(心得)
python_bobo的博客
03-06 2984
SRE:Google运维解密（心得）风险与可用性错误预算总结： 风险与可用性 在一个运行的系统中，出现风险是不可能避免的，而运维工程师的存着便是控制并解决风险。 书中提到构建百分百可靠的服务是不可取的，因为一个服务面向用户的不止是可靠，还有创新。当可靠性达到一定的数量级后，再花费大量的成本在可靠性上而忽略服务的创新，这种方式得不偿失。 书中还提到可用性为多少个‘9’这个概念 上面提到额外一个‘9...
SRE Google 运维解密--管理
watermelonbig的专栏
06-15 7308
一、迅速培养SRE加入on-call 在SRE团队的职责中，主动性任务和被动性任务兼有，每个SRE团队都坚守的一个重要目标是：利用积极主动的办法，去减少和限制被动性工作的产生。 SRE培训课程 推荐的培训方式 错误的培训方式 设计一个具体的、有延续性的学习体验，以便学员跟进 通过给学员安排一些烦琐的工作（处理警报/工单）来培训
SRE-Google运维解密随记-1
砚墨
12-31 601
增加现有容量经常需要启动新的实例甚至是整个集群，这通常需要大幅度修改现有的集群配置(配置文件、负载均衡、网络等),同时还要执行一系列测试，确保新上线的容量可以正确地服务用户。虽然不论多么完备的“运维手册”也无法替代人的创新思维，但 是在巨大的时间压力和产品压力下，运维手册中记录的清晰调试步骤和分析方法对处理 问题的人是不可或缺的。、一个业务的容量规划，不仅仅要包括自然增长(随着用户 使用量上升，资源用量也上升),也需要包括一些非自然增长的因素(新功能的发布、商业推广，以及其他商业因素在内)。
google 运维解密-终极最全标签版！
06-25
SRE：Google运维解密解释了如何对软件进行生命周期的整体性关注的，以及为什么这样做能够帮助Google成功地构建、部署、监控和运维世界上现存最大的软件系统。 DevOps突出重视软件开发人员和运维人员的沟通合作，通过...
SRE_Google运维解密_笔记
m0_70751647的博客
10-18 1359
1.70%的事故由变更引起 2.谷歌的SRE倾向于DEVOPS，兼顾效率（快速上线更新）与质量（降低事故率） 3.SRE大致发展历程：手动（凭经验容易误操作）→自动→智能 4.缓慢的不断重启的实例优于永不重启泄露资源的实例 5.SLA（service level agreement）：请求延迟；错误率；系统吞吐量（QPS）；可用性；持久性 SLO（object）：SLI的目标范围 SLI（indicator）：从目标反推指标 6.多创新，少做琐事（DRY），但合理的琐事有助于放松 7.监控系
1.SRE：Google运维解密 --- 介绍
enlyhua的专栏
06-03 1450
1.系统管理员模式 负责将现成的软件组件部署到生产环境中，对外提供某种业务服务。系统管理员的主要工作在于应对系统中产生的各种需要人工干预的事件，以及来自业务部门 的变更需求。开发部(Dev)和运维部(Ops)。 Dev/Ops 分离的团队模型的存在的问题： 1.直接成本 2.间接成本 研发团队和运维团队背景各异，技术能力与工具使用习惯上差距巨大，工作目标也截然不...
SRE：Google运维解密
YAYA776的博客
02-27 992
SRE团队要承担以下几类职责： 可用性改进 延迟优化 性能优化 效率优化 变更管理 监控 紧急事务处理 容量规划与管理 所有的产品事故都应该有对应的事后总结，无论有没有触发警报（若没有触发警报，事后总结的意义更大，将揭示监控系统中的漏洞）。事后总结包括的内容： 事故发生、发现、解决的全过程 事故的根本原因 预防或者优化的解决方案 在企业中，最主要的矛盾是迭代创新的速度与产品稳定程度之间的矛盾。使用...
Sre google 运维解密
04-12
这是一本好书 ，大神作品，值得学习，上传给大家分享混点积分
《SRE：Google运维解密》
weixin_33727510的博客
01-19 686
2019独角兽企业重金招聘Python工程师标准>>> ...
SRE Google 运维解密 具体实践一
watermelonbig的专栏
05-24 7061
一、基于时间序列数据进行有效报警 Borgmon是google使用的时间序列监控系统，在开源软件中Prometheus是非常类似的一款工具。这个软件将收集时间序列信息作为监控系统的首要任务，同时发展了一种丰富的时间序列信息操作语言，通过使用该语言将数据转化为图表和报警。 因为总是会有大批量的服务器在上线、下线，建立和维护一个有效的服务注册、发现系统是很有必要的。上线的主机需要能主动让B
SRE-Google运维解密随记-4
砚墨
01-04 552
我们发现，最安全的方式是在服务收到新数据之后，仍然维持之前的。的容量百分比，以及每个阶段之间等待的时间应该由服务的规模、发布的规模，以及服。在处理数据之前，应该检查数据的语法，甚至在可能的情况下，检查数据语义的正。非紧急的发布过程应该是按阶段进行的。HTTP流量与带宽预估，发布时的峰值，流量的组成，6个月的预测。配置运行，直到某个人来批准采用新数据这些数据可能是无效的。接收到不合理的配置文件或者输入数据时，应该继续保持之前的。安全设计评审，安全代码评审，垃圾邮件风险，验证，SSL。
3.SRE：Google运维解密 --- 拥抱风险
enlyhua的专栏
06-29 393
1.
SRE Google 运维解密 具体实践二
watermelonbig的专栏
06-08 3270
十四、管理关键状态：利用分布式共识来提高可靠性 跨物理区域分布式运行系统可以解决很多的系统灾备问题，以保障在灾难来临时系统仍然能正常运行。但是却带来维护系统一致状态视图的需求，而这个问题的解决常常是复杂且难以实现的。 一组服务进程可能想要可靠地对以下问题产生共识： 哪个进程目前是该组织进行的leader？本组中都包含哪些进程？是否已经将某个消息成功地插入了某个分布式队列？某个进程目前是否
SRE Google运维解密pdf
weixin_30945039的博客
02-09 1884
下载地址：网盘下载自动化对Google SRE 的价值 62自动化的应用案例 63Google SRE 的自动化使用案例 63自动化分类的层次结构 64让自己脱离工作：自动化所有的东西 66舒缓疼痛：将自动化应用到集群上线中 67使用Prodtest 检测不一致情况 68幂等地解决不一致情况 69专业化倾向 71以服务为导向的集群上线流程 72Borg ：...
读SRE Google运维解密有感(一)
weixin_30622107的博客
01-31 453
第一章读后感 SRE之道的理解：创建软件系统来运行和替换传统的人工操作。 在实际工作中： 1.我们执行重复性的工作，流程话，新建项目需要那些资源，那些账号，那些权限，制作成流程，一个项目来了相关同事按照流程操作，不会遗漏细节，提高速度。 eg: 新项目流程：xmind，（一图胜万语言） 2.系统节点出现故障，自...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值