读书笔记(SRE:Google运维解密):第7章 Google 的自动化系统的演进

SRE:Google运维解密(心得) SRE:Google运维解密(心得)风险与可用性错误预算总结: 风险与可用性 在一个运行的系统中,出现风险是不可能避免的,而运维工程师的存着便是控制并解决风险。 书中提到构建百分百可靠的服务是不可取的,因为一个服务面向用户的不止是可靠,还有创新。当可靠性达到一定的数量级后,再花费大量的成本在可靠性上而忽略服务的创新,这种方式得不偿失。 书中还提到可用性为多少个‘9’这个概念 上面提到额外一个‘9... 阅读详情
  • 自动化是一种力量倍增器,但不是万能药。当然,对力量的倍增并不能改变力量用在哪的准确性:草率地进行自动化可能在解决问题的同时产生出其他问题。
     
  • 自动化的价值究竟是什么?
    (a)一致性:一致性地执行范围明确、步骤已知的程序—是自动化的首要价值。
    (b)平台性:一个平台可以暴露自身的性能指标,也可以帮助你发现流程中以前所不知道的细节,这些细节在平台范围内更容易衡量。
    (c)修复速度更快:在产品生命周期中一个问题越晚被发现,修复代价越高;
    (d)行动速度更快:
    (e)节省时间:节省时间是一个经常被引用的使用自动化的理由
     
  • “如果我们持续产生不可自动化的流程和解决方案,我们就继续需要人来进行系统维护。如果我们要雇佣人来做这项工作,就像是在用人类的鲜血、汗水和眼泪养活机器。这就像是一个没有特效但是充满了愤怒的系统管理员的Matrix世界。”
     
  • 自动化的演进遵循以下路径:
    1)没有自动化:手动将数据库主进程在多个位置之间转移。
    2)外部维护的系统特定的自动化系统:SRE在他或她的主目录中保存了一份故障转移脚本。
    3)外部维护的通用的自动化系统:SRE将数据库支持添加到了每个人都在使用的“通用故障转移”脚本中。
    4)内部维护的系统特定的自动化:数据库自己发布故障转移脚本。
    5)不需要任何自动化的系统:数据库注意到问题发生,在无须人工干预的情况下进行故障转移。
     
  • 自动化程序的不同体现在三个方面:
    (a)能力,即准确性。
    (b)延迟,开始执行后,执行所有步骤需要多久。
    (c)相关性,自动化所涵盖的实际流程比例。
     
  • 许多分布式自动化都依赖于SSH。从安全的角度来看,这是很笨拙的,因为人们必须拥有机器的root权限才能运行大多数的命令。越来越多的人意识到,先进、持续的安全威胁迫使我们将SRE的特权降到最低,仅仅满足完成其工作所需的最低的特权:
    用一个支持认证、ACL驱动,以及基于RPC的本地管理进程来取代sshd,这被称为Admin服务器,它拥有本地执行更改权限。这样一来,没有人可以绕过审计跟踪来安装或是修改服务器。对Admin服务器代码和Package仓库的修改通过代码评审来把关,这使得越权操作非常困难;赋予别人安装软件包的权限不会允许他们查看日志。Admin服务器会记录RPC请求者、全部参数,以及所有的RPC的结果,以提高调试和安全审计功能。
     
- 集群上线自动化进化遵循这样一个路径:
(a)操作人员触发手动操作(无自动化)。
(b)操作人员编写,系统特定的自动化。
(c)外部维护的通用自动化。
(d)内部维护,系统特定的自动化。
(e)不需要人为干预的自治系统。
Python地理空间数据库之geopandas使用详解 地理空间数据分析在许多领域中都有着广泛的应用,包括地理信息系统(GIS)、城市规划、环境科学、地质勘探等。Python GeoPandas是一个强大的库,旨在简化地理空间数据的处理和分析。本文将深入介绍GeoPandas库,包括其基本概念、功能特性、示例代码以及在实际应用中的应用场景。 阅读详情

相关推荐

统信UOS V20 安装mysql5.7.42详细教程

到bin/下,执行下面的命令,初始化mysql服务信息,得到数据库的初始密码,实际如果目录不一样记得换成自己的目录。下载后通过远程将安装包上传至服务器,我这里将安装包上传至/usr/local/mysql 下。ps:这时候如果还是不能远程访问的话,可能是防火墙的原因,命令行执行以下命令即可。再次登录,发现缺少 libtinfo.so.5文件,再次建立软连接。登录,发现报错,提示缺少libncurses.so.5文件,使用。创建 /var/lib/ 下mysql目录。登录成功,修改密码,设置远程访问。

为谁伫立在风中 1万+

SRE Google运维解密——第8章 发布工程

第8章 发布工程 发布工程与产品研发部门的软件工程师,以及SRE一起定义发布软件的过程的全部步骤——包括软件是如何存储于源代码仓库中,构建时如何进行测试,打包,最终部署的 发布工程师角色 开发软件,为Google 提供各种数据(代码修改提交部署到生产环境一共需要多长时间)。定义最佳实践保障软件项目可以一致的,可重复的进行发布。 发布工程哲学 自服务模型 每个团队可以决定多久或者什...

Hcode4的博客 718

HRNet 【demo 复现过程】

Deep High-Resolution Representation Learning for Human Pose Estimation

qq_45257495的博客 5558

SRE Google运维解密——第7章 Google的自动化系统的演进

第7章 Google的自动化系统的演进 ================================================================== 自动化 与GoogleSRE 联系 自动化价值 一致性 可以准确执行重复可能出错的命令或者行为 平台性 可以搭建一个可扩展的平台,解放运维 修复速度更快 对于出错的处理更好的指定修复 行动速度更快 ...

Hcode4的博客 727

博途S7-1200与昆仑通态MCGS纯仿真联调实战指南

本文详细介绍了博途S7-1200与昆仑通态MCGS纯仿真联调的实战指南,包括环境搭建、配置步骤、通信桥接及故障排除。通过TIA Portal和MCGS Pro搭建的仿真环境,可实现80%以上的基础功能验证,适用于工业自动化学习和开发,大幅降低硬件投入成本。

weixin_26834815的博客 440

交货单冲销发货过账的正确姿势:用 VL09 与 ABAP 批量反冲 Goods Issue

摘要 本文详细解析了SAP系统中VL09事务码的技术实现与业务应用。VL09用于反冲发货的货物移动,通过标准冲销路径(移动类型602冲销601)确保单据链路一致、状态机正确回退和业务规则生效。文章对比了经典VL09与Fiori应用在不同SAP产品形态中的位置,并针对STO场景提供了ME23N验证方法。核心内容包括WS_REVERSE_GOODS_ISSUE函数模块的调用要点、必须COMMIT的原因(SAP LUW机制),以及处理Handling Unit等限制条件的注意事项。最后给出了将VL09工程化的项目

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 594

实录问答 | SRE 是如何炼成的

2017 年 2 月 7 日晚上 8 点 30 分,数人云CTO 肖德时为大家带来了主题为“运维达尔文: SRE 的自动化演进”的交流。 本文转自 GitChat 的交流实录,由主持人 Jacty 整理。 SRE 方法论 问: SRE 和 DevOps 有什么区别? 答: 这个问题其实出现过很多次,之所有此一问,必然是两者之间有很多共同点...

weixin_34116110的博客 306

9.23华为OD机试真题 新系统 - 小菊的寻宝之旅 (Java/Py/C/C++/Js/Go)

9.23华为OD机试真题 新系统 - 小菊的寻宝之旅 (Java/Py/C/C++/Js/Go)

算法大师! 1011

SRE Google 运维解密 具体实践一

一、基于时间序列数据进行有效报警 Borgmon是google使用的时间序列监控系统,在开源软件中Prometheus是非常类似的一款工具。这个软件将收集时间序列信息作为监控系统的首要任务,同时发展了一种丰富的时间序列信息操作语言,通过使用该语言将数据转化为图表和报警。 因为总是会有大批量的服务器在上线、下线,建立和维护一个有效的服务注册、发现系统是很有必要的。上线的主机需要能主动让B

watermelonbig的专栏 7363

【Prometheus】prometheus结合cAdvisor监控docker容器运行状态,并且实现实时告警通知

Docker的监控,可以使用Docker自带的stats命令来获取当前主机上运行中的容器的资源使用情况。 例如:容器的CPU使用率、内存占用、网络IO以及磁盘IO等指标。

景天科技苑 6万+

2024年11月架构设计师案例分析真题回顾,附参考答案、解析及所涉知识点(二)

软考高级系统架构设计师考试包含三个科目:信息系统综合知识、案例分析和系统架构设计论文。考试形式为机考。本文主要回顾2024年下半年(2024-11-10)系统架构设计师考试上午第二科案例分析的题目,同时附带参考解答、解析和所涉知识点。

一几文的编程学习笔记。 1664

云端的SRE发展与实践

本文根据作者在美团点评第21期技术沙龙的分享记录整理而成。 背景 SRE(Site Reliability Engineering)是Google于2003年提出的概念,将软件研发引入运维工作。现在渐渐已经成为各大互联网公司技术团队的标配。 美团点评作为综合性多业务的互联网+生活服务平台,覆盖“吃住行游购娱”各个领域,SRE就会面临一些特殊的挑战。 业务量的飞速增长,机器数量剧增...

美团技术团队 2821

神州路由器DHCPv6配置

神州路由器DHCPv6配置.。

weixin_41687096的博客 462

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

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

2361

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

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

VC中sqlite的使用

在VC中对sqlite的使用,实现数据库大批数据的快速插入,读取数据库中的数据在ListCtrl中显示

《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

华为的C语言编程规范.pdf

华为技术有限公司内部技术规范。本规范制定了编写C语言程序的基本原则、规则和建议。从代码的清晰、简洁、可测试、安全、程序效率、可移植各个方面对C语言编程作出了具体指导。

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

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

2139

老版QQ原生表情gif动态

这是老版的QQ表情,不过全是动态的的,Windows照片查看器是不会动的,可以右击用浏览器打开查看,再说一遍是老版的,只是分享给宁愿用老版也要动态的人。

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

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

1578

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

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

2330

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

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

1871

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

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

学无止境 1073

《SRE:Google 运维解密》读书笔记08: Google 的自动化系统的演进 - 当“琐事”遇上“自动化”

本文摘要:Google SRE方法论强调自动化是减少琐事的核心解决方案,但其本质是"元软件"而非万能药。自动化演进路径分为五个阶段:从手工操作到系统自治,最终目标是实现无需人工干预的自治系统。自动化具有五大价值:一致性、平台性、快速修复、加速行动和节省时间。衡量自动化质量的三个维度是能力、延迟和相关性。实践中需警惕"专业化倾向",即自动化代码需要持续维护。安全方面,Google从SSH迁移到Admin服务器,实现了最小权限和完整审计。自动化是SRE的力量倍增器,需要在

1564

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

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

1560

读书笔记(SRE:Google运维解密):第17章 测试可靠性

对服务质量的自信可以用过去的系统可靠度和未来的系统可靠度来衡量。前者可以通过抓取和分析历史性监控信息来获得,后者可以用基于历史数据的预测来量化。为了让这些预测信息足够准确,必须满足下列条件中之一: (a)在这段时间内,该系统完全没有改变。包括没有任何软件更新以及服务器数量变化,这意味着未来的行为方式应该与过去的行为方式类似。 (b)可以充分描述整个系统的所有改变,这样可以针对每个系统变化引入的不确定性进行分析。   软件测试的类型:传统测试和生产测试 (a)传统测试: 1)单元测试:单元测试(.

lo_ong的博客 716

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

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

1742

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

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

2368

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

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

2733
上一篇: 读书笔记(SRE:Google运维解密):第6章 分布式系统的监控
下一篇: 读书笔记(SRE:Google运维解密):第8章 发布工程
github_37320188
博客等级 码龄10年 24粉丝 86原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值