读书笔记(SRE:Google运维解密):第2章 Google 生产环境:SRE视角

保姆级教程:在Jetson Nano上从零移植OV5647 CSI摄像头驱动(附完整调试记录) 本文提供了一份详细的Jetson Nano OV5647 CSI摄像头驱动移植教程,涵盖硬件准备、驱动框架分析、设备树配置、驱动移植核心修改点及调试技巧。通过V4L2框架和Tegra平台适配,开发者可快速实现摄像头驱动的移植与优化,适用于边缘计算和嵌入式视觉应用。 阅读详情
  • 物理服务器(machine)
    代表具体的硬件(有时候也代表一个VM 虚拟机)。
     

  • 软件服务器(server)
    代表一个对外提供服务的软件系统。
     

  • 典型的Google数据中心的拓扑结构:
    (a)约10台物理服务器组成了一个机柜(Rack)
    (b)数台机柜组成一个机柜排(Row)
    (c)一排或多排机柜组成了一个集群(Cluster)
    (d)一般来说,一个数据中心(Datacenter)包含多个集群
    (e)多个相邻的数据中心组成了一个园区(Campus)
    在这里插入图片描述
     

  • 支持大规模部署的系统管理软件
    (a)管理物理服务器
    (b)存储
    (c)网络
    (d)分布式锁服务
    (e)监控与警报系统

 

  • grpc
  • thrift

 

  • 任务和数据的组织方式

(a)假设压力测试的结果显示,服务器可以每秒处理大概100个请求(100 QPS)。通过对用户进行的调查显示,预计峰值流量会达到3470 QPS,为了处理这些流量,至少需要 35个任务实例。但是,由于以下几点考量,最终决定至少采用37个实例,也就是 N+2模式:

  1. 在更新过程中,有一个任务实例将会短暂不可用,只有36个实例可提供服务。
  2. 如果另外一个物理服务器同时也出现问题,那么另外一个任务实例也受到影响,只剩35个实例可以对外服务,刚好可以满足峰值要求。

(b)假设,对用户流量的进一步观察显示峰值流量其实是来自全球的。北美洲1430 QPS,南美洲 290 QPS,欧洲和非洲 1400 QPS,亚洲及澳大利亚共350 QPS。为了更好地服务用户,需要将服务分别部署在美国、南美洲、欧洲和亚洲。在南美洲,选择使用只部署4个实例(而不是5个),将冗余度降低为N+1。这样做的原因是,选择在极端情况下牺牲一些用户体验以降低成本。因为当容量不足时,GSLB会将南美洲的用户流量导向其他可用的数据中心,可以节省大概20%的硬件资源。在有条件的地方,还会将任务实例分散在不同的集群中,以便更好地提升可靠性。

整车 EOL下线 测试系统介绍 整车下线(EOL)测试专门针对整车进行设计开发,是车企将组装好的整车交付客户前的 最后一道检测工序。EOL 测试针对的是整车下线测试,不同于零部件下线,是整车级别的下线 测试,测试过程关系整车的每个零部件,其测试质量直接影响到整车的质量好坏。因此,整车EOL测试是整车下线必不可少的测试过程. 阅读详情

相关推荐

ArcGIS通过已知坐标点转面(通过excel文件,有工具可批量生成面要素)

通过使用ArcGIS中的工具,将坐标点XY数据转换成可视化的点线面矢量数据,更加方便快捷有效的获取对应信息

qq_41046162的博客 3万+

从SRE视角透视DevOps的构建精髓

SRE 侧重系统稳定性,DevOps 强调开发运维协作。SRE 实践助力DevOps,提升系统稳定性与团队协作效率。 SRE 运用软件工程的原理,将系统管理员的手工任务自动化,负责运维由系统组件构成的服务,确保服务稳定运行。SRE职责涵盖监控开发、资源规划、紧急事件处理及事故根源追踪等,致力于消除重复性、手工性操作。 DevOps强调开发与运维的协同合作,通过工具链和流水线实现高效衔接,持续反馈以优化研发到运维的流程。 两者虽各有侧重,但SRE的实践正是DevOps建设思路的体现,通过自动化和智

m0_67544708的博客 1195

【对比学习+分割】CRIS:CLIP驱动RIS图像分割(CVPR 2022)

CRIS: CLIP-Driven Referring Image Segmentation

这个博客太懒了什么都没说 3325

SRE视角下的DevOps:构建稳定高效的软件交付流程

SRE 和 DevOps 有什么区别和联系?本文对此进行了解读,并着重从 SRE 实践出发阐述了 DevOps 的建设思路。 SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的工作。SRE 的职责是运维一个服务,该服务由一些相关的系统组件组成,为最终用户(可以是内部用户也可以是外部用户)提供服务。SRE 的终极责任是确保该服务可以正常运转。为达成这一目标,SRE 需要完成开发监控系统、规划资源容量、处理紧急事件、跟踪修复事故根源等。SRE 对重复性、手工性的操作有天然的排斥感,并

Xiaohong0716的博客 1500

海康威视web控件开发+vue结合做网页开发

需求:vue的项目,需要在页面展示出海康的硬盘录像机连接的摄像头的实时监控画面以及回放功能. 准备:web开发包(包含插件以及demo,在海康官网即可下载32位64位的都有.那些需要积分下载的博主良心不疼么.) 点击这里下载:链接: https://pan.baidu.com/s/12FrbycWyWWyiRJH5Yd1tPA 提取码: gam5 开始开发: 1.安装demo目录下的WebComponentsKit.exe插件(根据自己的浏览器以及系统选择32位还是64位的插件) 2.打.

u013682258的博客 8485

运营商拼命封杀的PCDN到底是个啥?

最近一段时间,很多宽带用户发现自家的网速莫名其妙变慢了,甚至收到了运营商发来的“违规使用宽带”警告短信,严重的甚至直接被断网。很多人一头雾水:我交了钱办的宽带,自己买的插件或者京东云、网心云这些硬件赚点“电费”,怎么就成了运营商眼中的“过街老鼠”?今天,我们就把这层窗户纸捅破,深度剖析这个让互联网大厂省下几十亿、让运营商恨得牙痒痒、让用户夹在中间进退两难的技术黑话——。

网络技术联盟站 924

2.SRE:Google运维解密 --- Google 生产环境:SRE 视角

1.硬件 物理服务器:代表具体的硬件 软件服务器:代表一个对外提供服务的软件系统 1.10台物理机组成一个机柜 2.数台机柜组成一个机柜排 3.一排或者多排组成了一个集群 4.一个数据中心包含多个集群 5.多个相邻的数据中心组成了一个园区 物理服务器的系统管理软件: 1.管理物理服务器 google Borg (下一代,Kubernetes) Apache...

enlyhua的专栏 688

【ComfyUI】Flux 完整版文生图

本文介绍了一个基于Flux Dev的AI文生图全流程工作流,通过整合扩散模型、文本编码器和VAE解码器等核心组件,实现从文本到高清图像的端到端生成。工作流包含模型加载、条件构建、潜空间采样、图像解码和成果保存五个关键环节,支持高分辨率图像的细节还原和艺术风格塑造。应用场景涵盖艺术创作、内容生产、教学演示和科研数据准备等领域,适用于对画质和提示遵循性要求严格的场景。文章还提供了相关开发资源和学习教程链接,帮助用户深入理解AI绘图机制和实际应用。

Mr数据杨 1284

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

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

2139

RK3568平台开发系列:Android环境下CAN的使用

在RK3568平台上,我们可以利用Android环境中的API来实现CAN的使用。通过以上步骤,我们可以在Android应用中发送和接收CAN数据,并进行相应的处理。当接收到CAN数据时,将触发onMessageReceived回调方法,我们可以在这个方法中对接收到的数据进行处理。在上述代码中,我们指定了CAN的ID为0x123,数据为{0x01, 0x02, 0x03},并设置了标志位和周期。接收CAN数据需要注册一个监听器,并在监听器中处理接收到的数据。发送CAN数据需要指定CAN的ID和数据。

2301_79330513的博客 1913

【100%通过率】华为OD机试真题 C++ 实现【打印机队列】【2022.11 Q4 新题】

有5台打印机打印文件,每台打印机有自己的待打印队列。因为打印的文件内容有轻重缓急之分,所以队列中的文件有1~10不同的代先级,其中数字越大优先级越高。打印机会从自己的待打印队列中选择优先级最高的文件来打印。如果存在两个优先级一样的文件,则选择最早进入队列的那个文件。现在请你来模拟这5台打印机的打印过程。

MISAYAONE的博客 9947

《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的博客 2524

金融行业大数据可视化:实时监控与风险预警系统构建

随着金融业务数字化转型,日均产生的交易数据、市场数据、客户行为数据呈指数级增长(单家银行日交易数据量可达TB级)。数据实时性不足(分钟级延迟难以应对高频交易风险)风险特征挖掘浅层(仅基于规则引擎,漏报率高达30%+)可视化分析能力薄弱(静态报表无法支持动态决策)本文聚焦构建具备毫秒级数据响应智能风险建模交互式可视化决策能力的新一代系统,覆盖数据采集、实时处理、多维可视化、智能预警四大核心模块,适用于银行、证券、保险等金融细分领域。章节核心内容技术亮点核心概念可视化系统架构/数据流模型。

AI天才研究院 1523

《SRE:Google运维解密》读后有感

当我们进行体系化的思考的后,我们就会有新的收获,并且在解决方案上更加的完善。框架和SRE平台这种模式,提供了很多的益处,比如说显著的降低运维开销,因为它支持代码结构、依赖关系、测试、编码样式指南等的强合规性测试,内置服务部署、监控和自动化,设计中自带的通用性支持,这种在框架中把基于生产最佳实践的代码模式进行标准化封装,让SRE在管理时降低了认知的负担,同时仍然可以保持服务的质量,每一个标准框架都为问题所在的领域或者问题相关的基础设市以来提供了一个完整的解决方案。,其次SRE的关注焦点在于。...

学无止境 1073

霍尼韦尔SoftMaster使用说明

霍尼韦尔SoftMaster使用说明

SAP B1中文培訓教材_SDK

公司内部培训资料,对开发工具 ,DIAPI, UIAPI,Add-ON有详细解说

《SRE:Google 运维解密》读书笔记34: 从其他行业吸取的经验教训 - 跳出软件工程看可靠性

事后总结文化是SRE四大核心主题中的第二项。本章比较了不同行业如何从失败中学习。跨行业比较揭示了一个普世真理:高可靠性不是某个行业的专利,而是系统化准备、从失败中学习、自动化与结构化决策四大支柱共同支撑的结果——SRE不是孤立的学科,而是人类追求可靠性的共同智慧在软件领域的体现。关键点一句话概括四大核心主题备灾测试 + 事后总结 + 自动化 + 结构化决策——跨行业比较的简化框架备灾测试的共性航空模拟器、核海军演习、软件DiRT——都在“可控环境中暴露系统弱点”事后总结的共性。

2400

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

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

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

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

睡觉的咖啡 719

迈瑞BS系列全自动生化分析仪LIS协议接口手册(内含HL7和ASTM)

迈瑞BS系列全自动生化分析仪LIS协议接口手册,内含HL7和ASTM)

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

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

1678

《SRE:Google 运维解密》读书笔记18: 测试可靠性 - 从“预防故障”到“验证可靠性”

金丝雀测试(Canary Testing)的名字来源于“矿井中的金丝雀”——过去矿工会把金丝雀带入矿井,利用其对有毒气体的高敏感性来预警危险。在正式全面部署之前,先将新版本部署到一小部分机器上,让这些机器承接一小部分真实用户流量,观察一段时间后再决定是否全面推广。测试可靠性 = 通过传统测试验证代码正确性 + 通过金丝雀测试在真实流量中验证变更 + 通过DiRT主动破坏系统验证灾难恢复能力,最终实现“变更可信、事故可控、灾难可恢复”。关键点一句话概括测试的本质。

1589

《SRE:Google 运维解密》读书笔记33: SRE参与模式的演进历程 - 从“接管服务”到“赋能产品”

SRE参与模式的演进 = 从后置审查(PRR)到前置介入(Shift Left)再到平台化赋能,让SRE的经验从“一对一守护”升级为“一对多赋能”。关键点一句话概括SRE参与的定义SRE关注服务的系统架构、可观测性、应急响应、容量规划、变更管理和性能六大维度PRR的本质SRE参与的先决条件和“把关闸门”,在服务上线前系统审查其生产就绪程度PRR的局限交付周期长达数月,难以匹配微服务时代的迭代速度早期参与的核心Shift Left(左移)——在设计阶段就介入,让服务“一开始就可靠”

2368

《SRE:Google 运维解密》读书笔记28: 可靠地进行产品的大规模发布 - 当发布不再只是“发布”

可靠的大规模发布 = LCE(发布协调工程师)设计流程 + 发布检查列表系统把关 + 灰度发布降低风险 + 功能开关提供逃生舱,让正常发布变得“无聊”而安全。关键点一句话概括LCE的角色定位SRE内部的专门咨询团队,负责新功能/新产品发布的可靠性审查和多方协调LCE三项核心能力广泛的经验 + 跨职能的视角 + 客观性好流程五大特征轻量级、鲁棒性、完整性、可扩展性、适应性——存在内在冲突,需持续平衡流程冲突的解法简化(用“最糟糕的事”问题判断)、高度定制、保证通用路径快速完成发布检查列表。

1908

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

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

aifeier1982的博客 1267

SRE-Google运维解密随记-1

增加现有容量经常需要启动新的实例甚至是整个集群,这通常需要大幅度修改现有的集群配置(配置文件、负载均衡、网络等),同时还要执行一系列测试,确保新上线的容量可以正确地服务用户。虽然不论多么完备的“运维手册”也无法替代人的创新思维,但 是在巨大的时间压力和产品压力下,运维手册中记录的清晰调试步骤和分析方法对处理 问题的人是不可或缺的。、一个业务的容量规划,不仅仅要包括自然增长(随着用户 使用量上升,资源用量也上升),也需要包括一些非自然增长的因素(新功能的发布、商业推广,以及其他商业因素在内)。

砚墨 647

SRE神作之精华

读《SRE Google运维解密》是我首次比较系统地了解和学习Google内部SRE运作的指导思想、实践以及相关问题,最近又花了一些时间,仔细阅读了关于SRE的第二本书籍《SRE生存指南》。 《SREGoogle运维解密》与《SRE生存指南》 SRE首先是一套方法论,它从传统运维中与稳定性相关的工作内容提炼出来进行升华,构建了SRE的方法论体系。冗余和容灾、容量规划、系统自动保护、失败预案、监控能力、发布与变更管理、故障应急处理等构成了SRE领域的蓝图,并不断地快速迭代着。 方...

一个天秤座的架构师 2万+

《SRE:Google 运维解密》读书笔记17: 跟踪故障 - 当“学习”止步于“文档”

在Google SRE的体系中,事后总结是“从失败中学习”的核心工具。盲点说明后果只覆盖影响大的事故事后总结通常只为造成重大影响的事故书写那些单个影响小但频繁发生的问题被忽视难以发现横向机会可能错失在个别情况下影响较小,或成本效益比不高但横向影响较大的机会跨团队、跨系统的系统性改进机会被遗漏缺乏宏观视角单个事后总结难以回答团队级别的问题不知道“每个值班班次收到多少告警”“哪些服务最辛苦”💡关键洞察:事后总结回答的是“为什么”,而系统化跟踪回答的是“我们正在做什么”和“有没有变得更好”。

1557

《SRE:Google 运维解密》读书笔记07: 监控分布式系统 - SRE的“眼睛“

监控 = 用四个黄金指标(延迟/流量/错误/饱和度)度量服务健康,用白盒定位原因、用黑盒发现现象,只告警真正需要人介入的问题,其余交给自动化。关键点一句话概括监控的五大目的趋势分析、实验对比、告警、仪表板、事后调试四个黄金指标延迟、流量、错误、饱和度——从用户视角抽象服务健康度白盒 vs 黑盒白盒关注"原因",黑盒关注"现象";两者结合才是完整监控分布 > 平均值P99 延迟反映长尾问题,平均值会掩盖糟糕的用户体验现象 vs 原因紧急告警应关注用户可见的现象,而非系统内部的原因。

1631

SRE:Google运维解密 高清

网盘下载链接:https://u18945853.ctfile.com/fs/18945853-322930438 内容简介: 大型软件系统生命周期的绝大部分都处于“使用”阶段,而非“设计”或“实现”阶段。那么为什么我们却总是认为软件工程应该首要关注设计和实现呢?在《SRE:Google运维解密》中,Google SRE的关键成员解释了他们是如何对软件进行生命周期的整体性关注的,以及为什么这样做能...

咻咻ing的专栏 3269
上一篇: 读书笔记(SRE:Google运维解密):第1章 概览
下一篇: 读书笔记(SRE:Google运维解密):第3章 拥抱风险
github_37320188
博客等级 码龄10年 24粉丝 86原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值