SRE Google运维解密——第9章 简单化

陌逸_逺 陌逸_逺 博客等级 墨衍会员 · AI 创作全网分发 墨衍智能分发 本文由作者通过墨衍一键同步至各平台 1分发平台 400+累计阅读 403平均单平台 已同步平台 优快云 微信公众号 微博 知乎 掘金 百家号 博客园 抖音 小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 码龄9年
关注
原创 最新推荐文章于 2026-09-07 14:24:10 发布 403 阅读 AI 写同款· GEO 优化 ›
SRE:Google运维解密(心得) SRE:Google运维解密（心得）风险与可用性错误预算总结： 风险与可用性 在一个运行的系统中，出现风险是不可能避免的，而运维工程师的存着便是控制并解决风险。 书中提到构建百分百可靠的服务是不可取的，因为一个服务面向用户的不止是可靠，还有创新。当可靠性达到一定的数量级后，再花费大量的成本在可靠性上而忽略服务的创新，这种方式得不偿失。 书中还提到可用性为多少个‘9’这个概念 上面提到额外一个‘9... 阅读详情

第9章 简单化

系统的稳定性与灵活性

  • 通过流程，实践以及工具，来提高软件的可靠性
  • SRE最小化路程对于开发人员的灵活性造成的影响
  • 可靠的流程会提高研发人员的灵活性

乏味是一种美德

  • 负责的系统不引入意外复杂度
  • 不断努力消除正在接手的和已经负责运维的系统的复杂度

我绝对不放弃我的代码

清除多余的代码

负代码行 作为一个指标

删除没有用的代码，保持代码整洁简单

最小api

提供API 消费者的方法和参数越少

模块化

  • 某一部分进行隔离式的变更的能力
  • 二进制文件之间或者二进制文件与配置之间推行松耦合

发布的简单化

  • 发布按最小的批次进行
  • 考虑每次改变对系统的改善和退化来寻找最佳方案
收录于
SRE Google运维解密

当前文章被收录于：

SRE Google运维解密
5 篇文章 0 人学习
订阅专栏 查看详情
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
S32K144之芯片锁死解锁——进入HardFault S32K144之芯片锁死解锁——进入HardFault 最近遇到因为软件代码问题导致进入HardFault，从而使芯片锁死，来简述具体现象以及最终的解锁方法。 导致原因：如下图，在进行Gpio的相关配置，case后面没有break语句，导致芯片进入HardFault。 现象1：reset引脚持续为低，reset指示灯常亮。如果掉电后重新上电，通过示波器抓取reset引脚的波形，会有510us左右或者29ms左右的低电平脉冲出现，一般会出现两三次左右并且没有规矩，持续几秒的高电平之后，reset脚再次被拉低 阅读详情

相关推荐

TAS5805MPWPR实战：数字音频功放从选型到量产全流程指南

数字音频功放将I2S数字信号直接转为PWM驱动扬声器，省去传统DAC与模拟运放链路，在高保真、低BOM与紧凑PCB之间找到平衡。其核心在于内置可编程DSP，支持多段PEQ、DRC等数字处理，通过I2C配置即可完成调音，而不占用主控算力。这类方案广泛应用于蓝牙音箱、Soundbar、智能音频模组等产品，但实际落地时常遇到I2C通信不稳定、EQ未生效、底噪超标、DC检测误触发等工程问题。从电源布局、LC滤波参数到PurePath Console工具链的使用，再到量产固件加载与故障排查，都需要系统化方法论支撑。本

weixin_29164843的博客 220

第七章 简单化

作者：John Lunney, Robert van Gent, Scott Ritchie，Diane Bates and Niall Richard Murphy 一个可正常工作的复杂的系统总是从以前可以正常工作的简单系统演变而来的。   ——Gall’s Law 简单化是SRE的重要目标，因为它与可靠性密切相关：简单的软件很少出现故障，在故障发生时更容易且迅速地修复。简单的系...

焦振清 565

opencv-meshgrid

使用opencv::repeat函数和std::iota函数完成meshgrid功能。 X Y Z 通俗的说就是根据Z的大小生成X矩阵,Y矩阵

yuegooxi的博客 1607

读书笔记（SRE：Google运维解密）：第9章 简单化

软件系统本质上是动态的和不稳定的。   有的时候为了灵活性而牺牲稳定性是有意义的   为了最小化意外复杂度，SRE团队应该： （a）在他们所负责的系统中引入意外复杂度时，及时提出抗议。 （b）不断地努力消除正在接手的和已经负责运维的系统的复杂度。   所有的代码都有必须存在的目的的实践："代码膨胀"检测   软件的简单性是可靠性的前提条件。当我们考虑如何简化一个给定的任务的每一步时，我们并不是在偷懒。相反，我们是在明确实际上要完成的任务是什么，以及如何更容易地做到。.

lo_ong的博客 262

别再只会用Excel了！Minitab 21手把手教你搞定SPC控制图（从数据导入到结果解读）

本文详细介绍了如何使用Minitab 21高效制作SPC控制图，从数据导入到结果解读的全流程。通过对比Excel的局限性，展示Minitab在自动化计算、图表标准化和特殊原因检验等方面的优势，帮助质量管理人员提升工作效率和数据分析专业性。

weixin_30878501的博客 386

基于近场动力学的二维疲劳裂纹扩展模型_近场动力学数值模拟的程序实现（1）——引言...

参考书目W. H. Gerstle. 2015. Introduction to Practical Peridynamic: Computational Solid Mechanics Without Stress and Strain.E.Madenci, A.Barut, M.Dorduncu. Peridynamic Differential Operator for Numerical ...

weixin_39764603的博客 1204

《SRE：Google运维解密》

2019独角兽企业重金招聘Python工程师标准>>> ...

weixin_33727510的博客 726

利用python-docx提取word的高亮部分

利用python-docx提取word的高亮部分 没有找到分享的文档，于是就自己研究了一下。 可以通过python里的python-docx去提取word内的高亮文本。 file=docx.Document(filepath) for para in file.paragraphs: for i in para.runs: #i.font.highlight_color设置了高亮颜色 if i.font.highlight_color is not None:

double_0221的博客 1810

系统可用性：SRE口中的3个9，4个9...到底是个什么东西？

作为服务端开发的同学，最常听到的一句话是你的接口有几个9？2个9？3个9？到底几个9才算是稳定呢？

董哥的黑板报 5868

从Delta Delay到Timing Window：详解数字芯片后端时序差异的那些坑

本文深入剖析了数字芯片后端设计中，模块级与系统级时序分析结果不一致的核心原因。重点解释了Delta Delay如何导致模块级分析的乐观假设，以及Timing Window（时序窗口）差异如何通过影响串扰噪声计算，在顶层集成时引发新的时序违例，尤其是保持时间问题。文章为工程师提供了从约束建模到签核策略的系统性应对方案。

beer8的博客 500

基于知识图谱的时空事件关联推理能力培养

随着信息技术的飞速发展，大量的时空事件数据被产生和收集，如交通流量数据、气象观测数据、社交媒体上的地理定位信息等。这些数据蕴含着丰富的知识和规律，但要从中提取有价值的信息并非易事。基于知识图谱的时空事件关联推理旨在通过构建知识图谱，将时空事件数据进行整合和关联，从而实现对事件之间潜在关系的挖掘和推理。本文的目的是系统地介绍基于知识图谱的时空事件关联推理能力的培养方法，包括核心概念、算法原理、数学模型、实际应用等方面。

操作系统内核探秘的博客 751

《SRE:Google运维解密》读书笔记（一）

1.SRE是目前最火的devops模型在google具体实践；2.Google SRE都有的共同特点是对重复性工作有排斥感以及喜欢用技术来代替手工操作；3.SRE核心的工作职责是变更管理、监控、故障处理、可用性改进以及优化；4.SRE将运维工作限制在50%，剩余时间花在研发上。5.SRE最终工作是在系统的稳定性和灵活性保持平衡；6.一个需要人工阅读邮件和分析警报来决定目前是否需要采取某种行动的系统...

weixin_33699914的博客 537

数据分享｜2000-2021年全国各城市风速数据（逐日、逐月、逐年）

而后，将每日的csv文件进行展点，再投影，采用反距离权重法对每日的数据进行插值。：美国国家海洋和大气管理局（NOAA）下设的国家环境信息中心(NCEI)，网址为：https://www.ncei.noaa.gov/data/global-summary-of-the-day/archive/该数据是通过风速平均值插值得来，由于插值的方式与各种处理参数的不同，会导致该数据与其它风速数据不同，数据仅供个人学习使用哦。如果在论文中使用该数据，数据来源请写上面的原始数据来源，处理方法请写上面的处理方式！

J_Giser的博客 1781

《SRE：Google 运维解密》读书笔记10: 简单化 - 如何通过简化系统架构来提升可靠性

负代码行指标衡量的是删除的代码行数。核心逻辑如下：代码行（LOC）的增加不等于价值的增加。代码本身不带来价值，它提供的功能才带来价值每一行代码都是负债——需要被阅读、被测试、被审计，是潜在缺陷的源头因此，删除代码本身就是一种胜利法国诗人安托万·德·圣埃克苏佩里曾说：“完美最终不是在没有更多东西可以添加时达到的，而是在没有任何东西可以拿走时达到的。删除代码的实际价值维度说明减少维护成本更少的代码 = 更少的阅读、测试和调试负担降低缺陷概率每行代码都可能引入新的缺陷，减少代码 = 减少潜在缺陷。

1677

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android：LinePhone3.2.7(最新版本)，官网地址：http://www.linphone.org/

android 蓝牙通讯demo

android 下蓝牙通讯demo，实现了发现蓝牙，使能蓝牙，通过蓝牙发送消息。

《SRE：Google 运维解密》读书笔记35: 结论 - 从Google的实践到行业的启示

SRE不是一套工具，而是一场文化变革——它通过拥抱风险、消除琐事、从失败中学习、数据驱动决策，将软件工程思维注入运维，让可靠性成为可量化的、可持续的核心竞争力。关键点一句话概括SRE的本质用软件工程方法解决运维问题，是文化变革而非工具集五大核心理念拥抱风险、消除琐事、简单化、从失败中学习、数据驱动决策50%规则SRE必须将至少一半时间投入开发工作，防止退化为纯运维错误预算用“1-SLO”定义可接受的故障额度，平衡创新与稳定无指责文化事故后分析系统缺陷而非追究个人，是坦诚复盘的基础。

2361

锂电池充电器电路设计 里面有电路

锂电池充电器电路设计 里面有电路 3.7V升压到5V电路设计。

《SRE：Google 运维解密》读书笔记31: 通过嵌入SRE的方式帮助团队从运维过载中恢复 - 当SRE团队陷入“运维漩涡”

嵌入SRE = 一名临时顾问，不是替团队清空票单，而是帮助团队建立SLO、区分琐事、识别“火种”，让团队从内部打破“50%规则失效”的恶性循环。关键点一句话概括问题背景票单量持续增长导致50%规则被长期打破，团队精疲力竭嵌入SRE的定位临时顾问，职责是改进团队的实践，而非直接处理票单一人原则一个嵌入SRE比两个更有效，两个可能触发团队防御性反应第一阶段了解服务与背景，区分“核心但很小”与“快速增长”的服务第二阶段找出最大压力源，关注中断数量而非处理速度第三阶段。

2139

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

SRE Google运维解密pdf

下载地址：网盘下载自动化对Google SRE 的价值 62自动化的应用案例 63Google SRE 的自动化使用案例 63自动化分类的层次结构 64让自己脱离工作：自动化所有的东西 66舒缓疼痛：将自动化应用到集群上线中 67使用Prodtest 检测不一致情况 68幂等地解决不一致情况 69专业化倾向 71以服务为导向的集群上线流程 72Borg ：...

weixin_30945039的博客 2017

《SRE：Google 运维解密》读书笔记01: 为什么要学习Google SRE & Google SRE 可以带给我们什么？

SRE：Google 运维解密》是一本教你如何在高速迭代中保持系统稳定的工程圣经。掌握现代高可用系统的构建方法论；具备用工程思维解决运维问题的能力；成为团队中推动可靠性和效率提升的关键人物；在职业发展中拥有 DevOps/SRE/平台工程等热门方向的核心竞争力。建议搭配实践：读完一章后，尝试在你的项目中落地一个概念（比如定义一个 API 的 SLO，或写一个自动化脚本减少重复操作）。PS: 如果你正在构建或维护线上系统，这本书值得反复精读！！！

1560

SRE是什么？

SRE是什么？ SRE(Site Reliability Engineering),站点可靠性工程,起源于2003年。在系统管理员模式下，通常是通过人工操作完成任务，而SRE倾向通过设计、构建自动化工具来取代人工操作。SRE的本质是用软件工程的思维和方法解决复杂的运维问题。 DevOps是在2008年年末流行起来，强调自动化替代人工操作，以及利用软件工程手段执行运维任务。DevOps的核心是"全栈交付"， SRE的出发点是“保障和提升系统稳定性”，两者要做的事情其实本质上差别不大，但是角度不同。可以认为De

John的博客 1万+

《SRE：Google 运维解密》读书笔记11: 基于时间序列数据进行有效报警 - 新型的监控

在正式进入第10章之前，有必要对“具体实践”这一部分的整体结构有所了解。章节主题核心内容第10章基于时间序列数据进行有效报警Borgmon、时间序列数据库、报警规则设计第11章on-call 轮值多地团队、轮值频率与生产环境熟悉度第12章有效的故障排查手段假设-排除法、常见陷阱第13-14章应急事件管理降低影响范围、管理事故响应第15-16章事后总结与根源分析无指责文化、事故跟踪系统第17章测试避免已知类型问题重复发生第18-22章容量规划与负载均衡Auxon、GSLB、BwE、连锁故障。

1932

一个Google SRE工程师眼中的8点运维原则

我是 Google 一名 SRE （运维）工程师，在过去系列文章中对『SRE: Google 运维解密』一书提出了自己的见解。本文所有见解皆为个人观点，不代表 Google 公司立场。我们来看书中第一章的一些观点： Google 对运维的解决之道：网站可靠性工程（Site Reliability Engineering）[1]。虽然每个 SRE 团队都有自己的工作流程、优先级定义以及日常工作规范，...

weixin_34195546的博客 2644

Google SRE 读书笔记 扒一扒SRE用的那些工具

写在前面 最近花了一点时间阅读了《SRE Goolge运维解密》这本书，对于书的内容大家可以看看豆瓣上的介绍。总体而言，这本书是首次比较系统的披露Google内部SRE运作的一些指导思想、实践以及相关的问题，对于我们运维乃至开发人员都有一定的借鉴意义。 书中的一些思想也令我印象深刻，例如SRE工程师要保证投入50%的时间在项目上、错误预算、命运之轮、事故总结等等，对于从业者有很大的启发。...

aifeier1982的博客 1267

读书笔记（SRE：Google运维解密）：第3章 拥抱风险

极端的可靠性会带来成本的大幅提升： 过分追求稳定性限制了新功能的开发速度和将产品交付给用户的速度，并且很大程度地增加了成本，这反过来又减少了一个团队可以提供的新功能的数量   可靠性进一步提升的成本主要存在于以下两个维度 （a）冗余物理服务器/计算资源的成本 （b）机会成本 基于时间的可用性 可用性=系统正常运行时间/（系统正常运行时间+停机时间） 通过请求成功率来定义服务可用性 可用性=成功请求数/总的请求数 在一个正式的环境或安全关键的系统中，服务的风险容忍度通常是直接根据..

lo_ong的博客 447

读SRE Google运维解密有感(一)

前言 这几天打算利用碎片时间读了一下"SRE Google运维解密"这本书，目前读了前几章，感觉收获颇多，结合自己的工作经历和书中的要点，写一些感悟和思考 SRE 有关SRE我就不多介绍了，中文名字叫站点可靠性工程师，它的由来是google想通过软件工程师来解决复杂运维问题。 它里面有很多有意思的点，比如: 运维工作只能占比工作时间50% 另外50%要开发工具解决问题 SRE和开发工程师会轮岗 ...

weixin_34166847的博客 403

Google SRE读后感

Google SRE读后感 《SRE Google运维解密》一书由Google SRE团队各成员所写的短文组成，书中记载了SRE团队在支持Google业务规模不断扩大的过程中所总结的经验以及实际案例。即使在IT行业发生翻天覆地变化的今天，此书仍然弥足珍贵，它详细记录了Google迈过分水岭时期的全过程。很显然，这些经历没有办法完全复制，也许只能被模仿，但是却可以启发读者，指引未来。 本书分为以...

xianyuLuo的博客 787

《SRE：Google 运维解密》读书笔记04: 拥抱风险管理 - 从“零故障”到“理性风险”

关键点一句话概括拥抱风险完全消除风险不可能且不经济，要学会管理风险。风险容忍度根据业务价值、用户期望、成本收益确定合理的 SLO。错误预算将 SLO 转化为可操作的决策依据，平衡创新与稳定。ROI 分析用数据判断是否值得为更高的可靠性投资。行动建议为你的核心服务定义一个基于请求的 SLO（例如 99.9%）。计算错误预算，并与产品团队达成一致。建立监控和预警，当错误预算消耗过快时，自动限制变更。每月/每季度回顾错误预算使用情况，指导下一阶段的稳定性投入。

1660
上一篇： SRE Google运维解密——第8章 发布工程
下一篇： SRE Google运维解密——第10章 基于时间序列数据进行有效报警
点赞 0
评论 0
书签 书签 0
陌逸_逺
陌逸_逺
博客等级 码龄9年 13粉丝 49原创
+ 关注 专栏目录 订阅专栏
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值