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

python_bobo python_bobo 博客等级 墨衍会员 · AI 创作全网分发 墨衍智能分发 本文由作者通过墨衍一键同步至各平台 1分发平台 700+累计阅读 753平均单平台 已同步平台 优快云 微信公众号 微博 知乎 掘金 百家号 博客园 抖音 小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 码龄9年
关注
原创 最新推荐文章于 2026-05-13 00:00:00 发布 753 阅读 AI 写同款· GEO 优化 ›
googleSRE运维解密 SRE读书沉淀 阅读详情

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

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

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

在这里插入图片描述

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

在这里插入图片描述

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

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

在这里插入图片描述

收录于
读书笔记

当前文章被收录于：

读书笔记
5 篇文章 0 人学习
订阅专栏 查看详情
标签
#SRE
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
从混沌到秩序的蜕变，SRE解码云计算运维奥秘 本文基于SRE 的核心原则，即在“事前”发现潜在问题，“事中”快速定位、处理问题，“事后”持续优化来规避问题。通过实时监控和分析数据，并采用自动化工具套件来减少手动操作，从而缩短故障处理时间，排除潜在故障点，并持续优化服务稳定性。 阅读详情

相关推荐

【Dify精讲】第2章：后端服务架构深度剖析

Dify后端采用Flask应用工厂模式实现模块化开发，通过蓝图架构将API分为控制台、Web应用和服务接口三大模块。其设计亮点包括：1) 应用工厂模式支持多环境配置和独立测试；2) 蓝图分层管理实现API模块化，各模块职责清晰；3) 严格遵循RESTful原则设计API接口；4) 使用Flask-RESTful扩展简化API开发。这种架构既保持了Flask的灵活性，又实现了企业级应用的可维护性，是Flask项目架构的优秀实践案例。

wiyi9891的专栏 2127

SRE_Google运维解密_笔记

1.70%的事故由变更引起 2.谷歌的SRE倾向于DEVOPS，兼顾效率（快速上线更新）与质量（降低事故率） 3.SRE大致发展历程：手动（凭经验容易误操作）→自动→智能 4.缓慢的不断重启的实例优于永不重启泄露资源的实例 5.SLA（service level agreement）：请求延迟；错误率；系统吞吐量（QPS）；可用性；持久性 SLO（object）：SLI的目标范围 SLI（indicator）：从目标反推指标 6.多创新，少做琐事（DRY），但合理的琐事有助于放松 7.监控系

m0_70751647的博客 1449

MATLAB实战：手把手教你用三频四步相移法搞定结构光三维重建（附完整代码）

本文详细介绍了如何使用MATLAB实现三频四步相移法进行高精度结构光三维重建。通过光栅图像预处理、相位计算、多频外差与相位解包裹等步骤，结合完整代码示例，帮助读者掌握从二维图像到三维点云的关键技术。该方法在工业检测和逆向工程中具有抗干扰能力强、高分辨率和鲁棒性等优势。

weixin_29201933的博客 340

【读书笔记】SRE：Google运维解密 第Ⅰ部分 概览

研发团队和系统运维团队分属两个部门所带来的间接成本就没那么容易度量了，但是这些间接成本往往大得多。

睡觉的咖啡 719

绕过限制？实测修改UA在PC端运行微信小程序的可行性及风险

本文探讨了通过修改User-Agent(UA)在PC端运行微信小程序的技术可行性及风险。分析了小程序设备限制的技术原理，包括`wx.getSystemInfo`API和UA检测机制，并提供了多种修改方案及其局限性。同时强调了潜在的安全和法律风险，推荐使用官方模拟器或安卓模拟器等更安全的替代方案。

weixin_30879169的博客 365

Win11 24H2共享访问被禁？深入聊聊SMB签名和‘不安全的来宾登录’那点事

本文深入解析Win11 24H2共享访问故障，探讨SMB签名的安全机制与‘不安全的来宾登录’问题。提供从注册表修改到组策略配置的多层次解决方案，特别针对家庭网络和打印机共享场景给出实用建议，帮助用户在安全与便利之间找到平衡。

weixin_42556197的博客 568

python知识点

Python是一种解释的、高级的、通用的编程语言。Python的设计理念是通过使用必要的空格与空行，增强代码的可读性。它之所以受欢迎，就是因为它具有简单易用的语法隐式递归” 是递归算法的一种形式，它在计算过程中并不直接使用函数的递归调用，而是通过简化问题规模、迭代或使用辅助数据结构来实现递归的效果。

m0_60732959的博客 245

TPAMI 2024 | 基于外观的深度学习凝视估计：综述与基准测试

人类目光提供了关于人类焦点和意图的有价值信息，使其成为研究的关键领域。最近，深度学习彻底改变了基于外观的眼神估计。然而，由于眼神估计研究的独特特征，如2D眼神位置和3D眼神向量之间的不公平比较以及不同的预处理和后处理方法，缺乏开发基于深度学习的眼神估计算法的明确指导方针。在本文中，我们系统回顾了使用深度学习的眼神估计方法。首先，我们沿着典型的眼神估计流程调查现有的算法：深度特征提取、深度学习模型设计、个人校准和平台。

小白学视觉 344

《SRE：Google 运维解密》读书笔记38: 完结篇补充1 - 如何在实际工作中落地这些SRE理念

目的：用数据替代“感觉”，建立共同目标。怎么做选择一个核心用户场景（如“用户登录”或“API 查询”）；定义SLI（服务质量指标），例如：成功率 = 成功请求数 / 总请求数延迟 P95 < 500ms设定SLO（建议从宽松开始）：“过去 28 天，登录成功率 ≥ 99%”计算错误预算允许失败比例 = 1% → 每月约 7 小时可“不可用”工具建议使用 Prometheus + Grafana 监控 SLI；用简单脚本计算是否违反 SLO。SLO 不是 SLA（对外承诺）

2733

支付域——“清算、结算、清结算”

本文深入探讨了支付系统中的清算和结算流程，包括核心流程、模块设计及特殊场景处理。文章详细阐述了交易收单、资金冻结、清分规则、清算批处理、结算出账等关键步骤，并讨论了交易失败、数据不一致、退款、汇率波动等异常情况的处理方法。

庄小焱 2564

NTC热敏电阻选型快速指南

NTC（Negative Temperature Coefficient Thermistor）负温度系数热敏电阻器，是由锰Mn，镍Ni，铜Cu，一氧化碳Co等烧结而成的氧化物。其电阻值随温度的升高而减小，即具有复温度系数，故被称为负温度系数热敏电阻。本文对热敏电阻的应用场景，结构特点和选型参数进行总结。

fydar的博客 1297

读书笔记（SRE：Google运维解密）：第1章 概览

SRE究竟是如何在Google起源的？ SRE就是让软件工程师来设计一个新型运维团队的结果   SRE团队成员具有如下特点： （a）对重复性、手工性的操作有天然的排斥感。 （b）有足够的技术能力快速开发出软件系统以替代手工操作。   Google的经验法则 SRE团队必须将50%的精力花在真实的开发工作上   DevOps 核心思想是尽早将IT相关技术与产品设计和开发过程结合起来，着重强调自动化而不是人工操作，以及利用软件工程手段执行运维任务等   ..

lo_ong的博客 528

【Unity】【2D】用连续图片生成动画Animation的简明步骤

本文介绍了Unity中使用2D连续图片制作2D动画Animation的简明步骤。

O青草O的博客 Unity和游戏制作知识分享 719

《SRE Google 运维解密》笔记

文章目录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 目标在实...

phantom_111的博客 2523

SIMATIC S7-1200, S7-1500 PID 控制[手册]

SIMATIC S7-1200, S7-1500 PID 控制[手册]

WINCC7.3破解文件

WINCC7.3硬件够破解文件，有需要的下载！WINCC7.3硬件够破解文件，有需要的下载！

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

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

1560

C# WinForm 基于DirectShow.dll编写的程序，可边预览边保存视频，音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择（默认选中第一个）2.可录制wmv和avi两种格式的视频并且都带有音频，avi可以录制的分辨率和帧数进行选择，wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照，也可边录制视频边拍照4.添加了视频和音频的压缩功能（酌情使用）这次二次开发发现C#对DirectShow的相关信息太少，这次做完也不敢藏私共享出来，还望大家指正

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

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

2139

精雕软件(JDpaint) 5.5 绿色版

精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版

《SRE：Google 运维解密》读书笔记19: SRE中的软件工程 - 当SRE从“运维”走向“开发”

SRE中的软件工程 = 将生产运维的知识和经验固化为可复用的内部产品，以团队规模的线性增长支撑服务规模的指数级增长，同时为SRE工程师提供职业发展的工程通道。关键点一句话概括隐形软件工程Google有大量消费者看不见的软件工程，很多在SRE内部完成三大开发优势生产知识深度 + 直接使用者 + 高质量反馈产品化思维SRE工具不是一次性脚本，而是有路线图的成熟项目核心原则团队规模不应随服务增长而线性扩展Auxon案例将容量规划从“预测驱动”升级为“意图驱动”职业发展双通道。

1871

《SRE：Google 运维解密》读书笔记06: 少琐事 - SRE的隐形敌人

琐事就是运维服务中手动性的、重复性的、可以被自动化的、战术性的、没有持久价值的工作，而且，琐事与服务呈线性关系的增长。一个经典案例：运维人员收到"磁盘目录满"告警后，手动登录服务器清理日志文件。这件事手动、重复（下次磁盘还会满）、可以被自动化、没有持久价值（清理完服务状态没有任何改进），且随着服务器数量增长，这类工作的频次会线性增加。另一个琐事密集场景：周期性报表和周期性巡检。这类工作虽然看似"有必要"，但如果每次都需要人工执行，就完全符合琐事的定义——重复、可自动化、缺乏持久价值。

1578

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

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

2360

如何做监控？Google SRE 解密

监控值班室：@隔壁老王头 SQL执行耗时时间过长，达到了报警阈值【5000ms】隔壁老王头：@监控值班室 少量报警请忽略，批量关注即可。监控值班室：@隔壁老王头 ...

一猿小讲 1782

《SRE：Google 运维解密》读书笔记29: 迅速培养SRE加入on-call - 培训, 是对人最重要的投资

SRE培训 = 系统性蓝图导航 + 目标性项目赋能 + 反向工程锻造思维——让新手在信任和安全感中快速成长为值得信赖的on-call工程师。关键点一句话概括信任是基石培训的目标是让团队可以相互信任——相信每个人在关键时刻都能靠得住三大核心问题除了“教什么”，还要考虑如何评估、如何双赢、如何让大家都喜欢培训蓝图X轴（抽象→具体） + Y轴（时间），正式on-call是重要里程碑新手三大焦虑“我在做什么”“进度如何”“何时能on-call”——培训需要回答这些问题系统性原则。

2330

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

本文摘要：SRE（Site Reliability Engineering）是一种用软件工程方法解决运维问题的实践，核心是让软件工程师负责运维工作。与传统运维不同，SRE强调自动化、50%开发时间、拥抱风险（通过错误预算机制）和消除重复性工作。Google的SRE团队分为产品SRE、基础设施SRE和共享平台SRE三种形态，要求成员具备软件开发能力。SRE七大原则包括：拥抱风险、设定SLO目标、消除琐事、监控系统、自动化、发布工程和追求简单性。SRE与DevOps互为补充，前者提供具体方法论，后者提供文化框架

1650

1.SRE：Google运维解密 --- 介绍

1.系统管理员模式 负责将现成的软件组件部署到生产环境中，对外提供某种业务服务。系统管理员的主要工作在于应对系统中产生的各种需要人工干预的事件，以及来自业务部门 的变更需求。开发部(Dev)和运维部(Ops)。 Dev/Ops 分离的团队模型的存在的问题： 1.直接成本 2.间接成本 研发团队和运维团队背景各异，技术能力与工具使用习惯上差距巨大，工作目标也截然不...

enlyhua的专栏 1519

《Sre google运维解密》笔记

Sre是什么

不才的专栏 1462

《SRE Google运维解密》读书笔记

SRE团队职责：确保服务可以正常运转 可用性改进 延迟优化 性能优化 效率优化 变更管理 （渐进式发布） 监控 紧急事务处理 容量规则与管理 （N+2 模式，google--> 15倍） SRE核心处理思想： 灾难预演与演习 确保系统按照预想方式应对故障 寻找系统中未预料的弱点 寻找其他提高鲁棒性的方式避免事故发生 从组织架构层面关注 关注...

victorzzzz的专栏 1266

《SRE：Google 运维解密》读书笔记12: on-call轮值 - SRE的“生命线”

on-call 轮值是 SRE 保障服务可靠性的核心机制，通过主副值班制、多地团队、25%运维时间红线和12小时≤2事件的质量标准，让应急响应可持续。关键点一句话概括on-call 的核心目标服务可靠性（分钟级响应）+ 团队可持续性（避免疲劳战）主副值班制主 on-call 负责主要响应，副 on-call 作为备份和协助多地团队优势避免夜间值班损害健康 + 控制团队规模保障熟悉度数量平衡纯运维时间 ≤ 25%，至少 50% 投入研发质量平衡。

1742
上一篇： DHCP服务器的配置
下一篇： SRE:Google运维解密(心得)
点赞 0
评论 0
书签 书签 0
python_bobo
python_bobo
博客等级 码龄9年 15粉丝 45原创
+ 关注 专栏目录 订阅专栏
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值