178 lines
12 KiB
Markdown
178 lines
12 KiB
Markdown
---
|
||
doc_type: weread-highlights-reviews
|
||
bookId: "26271721"
|
||
author: 仲平
|
||
cover: https://wfqqreader-1252317822.image.myqcloud.com/cover/721/26271721/t7_26271721.jpg
|
||
reviewCount: 7
|
||
noteCount: 57
|
||
readingStatus: 在读
|
||
progress: 18%
|
||
totalReadDay: 5
|
||
readingTime: 1小时29分钟
|
||
readingDate: 2023-04-09
|
||
title: SRE：Google运维解密
|
||
description: 在本书中，不仅展示了 Google 是如何运用各种计算机工具软件、硬件以持续部署和监控一些世界上最大的软件系统的。还展示了在运维过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。本书适合各种水平的运维工程师参考使用。
|
||
keywords:
|
||
- SRE：Google运维解密
|
||
- 贝特西·拜尔等
|
||
tags:
|
||
- 阅读/计算机-计算机综合
|
||
date: 2024-02-26
|
||
|
||
---
|
||
|
||
## 简介
|
||
|
||
- **书名**：《SRE：Google运维解密》
|
||
- **作者**： 贝特西·拜尔等
|
||
- **分类**： 计算机-计算机综合
|
||
- **ISBN**：9787121297267
|
||
- **出版社**：电子工业出版社
|
||
|
||
## 概述
|
||
|
||
在本书中，不仅展示了 Google 是如何运用各种计算机工具软件、硬件以持续部署和监控一些世界上最大的软件系统的。还展示了在运维过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。本书适合各种水平的运维工程师参考使用。
|
||
|
||
## 划线
|
||
|
||
|
||
> 大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。
|
||
|
||
> SRE就是运行和管理这百万台服务器和众多分布式系统的关键。
|
||
|
||
> SRE强调的是对问题和故障的自动处理，而非人工干预；再者，按照SRE的约定，开发人员自行负责程序上线部署更新，毕竟开发人员对自己开发的程序更熟悉，易于处理程序上线过程中遇到的问题。
|
||
|
||
> 100%的可用性是不现实的，需要达到这个目标的成本通常远超于所能获得的价值，所以Google会针对每种产品设定一个错误预算（容错率），既能保证用户体验又不影响创新和部署的速度。
|
||
|
||
> SRE是一群天生的怀疑论者，我们怀疑一切宣传起来“高大上”的技术，以及任何“神奇”的产品——我们只想看具体的设计架构、实现细节，以及真实的监控图表。
|
||
|
||
> SRE其实是一群崇尚工匠主义的人，我们坚信只要不断地解决根源问题，服务质量就一定会得到提升。而SRE正是用这种“日拱一卒”的方法造就了Google这个世界级的奇迹。
|
||
|
||
> 本书体系化地覆盖了运维工作的方方面面，是一本运维行业的教科书。
|
||
|
||
> 更重要的是，我们展示了在建设过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。IT 行业大多自我封闭，交流过少，很多从业人员都或多或少地受教条主义的限制。如果Google 工程师团队能克服这个惯性，保持开放的精神，那么我们也能够一起和他们面对 IT 行业内最尖端的挑战。
|
||
|
||
> 今天，我们能感受到整个行业都在鼓吹厚颜无耻的 “代码拿来主义”（just show me the code）。开源软件社区内部正在形成一种“不要问我问题”的风气，过于强调平等却忽略领域专家的意见。Google 是行业内为数不多的，愿意投入精英力量钻研本质问题的公司，而且这些公司精英很多都有工学博士学位。工具永远只是解决方案中的一个小小组件，用来链接日益庞杂的软件、人和海量的数据。
|
||
|
||
> 一个公司的成长，意味着整个公司商业模式和工作模式的扩展，而不是简单的资源扩张
|
||
|
||
> 有统计显示，一个软件系统的40%～90% 的花销其实是花在开发建设完成之后不断维护过程中的。[1]
|
||
|
||
> 从这个视角出发，我们认为如果软件工程职业主要专注于设计和构建软件系统，那么应该有另外一种职业专注于整个软件系统的生命周期管理。从其设计一直到部署，历经不断改进，最后顺利退役。
|
||
|
||
> 有的时候，SRE 和产品研发团队共同工作，其他时候我们需要开发这些系统的额外组件：例如备份系统和负载均衡系统等。理想情况下，同时推进这些组件在多个项目中复用。还有的时候，我们的任务是想出各种各样的办法用现有组件解决新的问题。
|
||
|
||
> 这与盖房子有些类似，如果一开始将整个地基打好并保持继续修缮，要比盖好房子之后再重新修改设计要容易得多
|
||
|
||
> 团队文化就是从一切经历中不断学习，包括来自那些我们最意想不到的地方的经历。
|
||
|
||
> 只有靠着对细节的不懈关注，做好充足的灾难预案和准备工作，时刻警惕着，不放过一切机会去避免灾难发生。这就是SRE 最重要的理念！欢迎加入SRE的大家庭！
|
||
|
||
> 不能将碰运气当成战略。
|
||
|
||
> 极端来说，研发部门想要：“随时随地发布新功能，没有任何阻拦”，而运维部门则想要：“一旦一个东西在生产环境中正常工作了，就不要再进行任何改动。”
|
||
|
||
> 由于两个部门使用的语境不同，对风险的定义也不一致。
|
||
|
||
> 开发团队宣称他们不再进行大规模的程序更新，而是逐渐转为功能开关调整、增量更新，以及补丁化。采用这些名词的唯一目的，就是为了绕过运维部门设立的各种流程，从而能更快地上线新功能。
|
||
|
||
> 目前来看，UNIX 系统内部细节和1～3层网络知识是Google最看重的两类额外的技术能力。
|
||
|
||
> 所有的SRE团队成员都必须非常愿意、也非常相信用软件工程方法可以解决复杂的运维问题。
|
||
|
||
> （a）对重复性、手工性的操作有天然的排斥感。（b）有足够的技术能力快速开发出软件系统以替代手工操作。
|
||
|
||
> SRE团队应该倾向于将基本的运维工作全部消除，全力投入在研发任务上
|
||
|
||
> 我们可以认为DevOps是SRE核心理念的普适版，可以用于更广范围内的组织结构、管理结构和人员安排。同时，SRE是DevOps模型在Google的具体实践，带有一些特别的扩展。
|
||
|
||
> “错误预算”起源于这样一个理念：任何产品都不是，也不应该做到100% 可靠（显然这并不适用于心脏起搏器和防抱死刹车系统等）。一般来说，任何软件系统都不应该一味地追求100% 可靠。因为对最终用户来说，99.999% 和 100% 的可用性是没有实质区别的（详见附录A）
|
||
|
||
> 一个需要人工阅读邮件和分析警报来决定目前是否需要采取某种行动的系统从本质上就是错误的。监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。
|
||
|
||
> 但是长久看来一个手持“运维宝典”经过多次演习的on-call工程师才是正确之路
|
||
|
||
> 由一个简单的想法“我是一名软件工程师，这是我如何来应付重复劳动的办法”而生
|
||
|
||
> Google的大部分计算资源都存放在自主设计的数据中心中。这些数据中心拥有自己设计的供电系统、制冷系统、网络系统以及计算机硬件（参见文献[Bar13]）。
|
||
|
||
> 一个典型的Google数据中心的拓扑结构：● 约10台物理服务器组成了一个机柜（Rack）● 数台机柜组成一个机柜排（Row）● 一排或多排机柜组成了一个集群（Cluster）● 一般来说，一个数据中心（Datacenter）包含多个集群● 多个相邻的数据中心组成了一个园区（Campus）
|
||
|
||
> 因为一个集群中包括很多硬件设备，每天硬件设备的损坏量很高。在一年内，一个单独集群中平均会发生几千起物理服务器损坏事件，会损失几千块硬盘。
|
||
|
||
> 如果一个工程师遇到了他工作的项目之外的一个基础组件的问题，他可以直接修改这个问题，向管理者提交一份改动申请（changelist,CL），等待代码评审，最后直接提交。
|
||
|
||
> 任何对自己项目代码的改动也需要代码评审。
|
||
|
||
> 有些项目组甚至在实践自动部署机制：提交一个新版本，测试通过后，将直接部署于生产环境。
|
||
|
||
> 监控系统都是运维生产环境必不可少的组件。如果没有针对服务的监控，就无从得知目前服务的状态，如果不知道服务的状态，就无从谈起维护服务的可靠性。
|
||
|
||
> 极端的可靠性会带来成本的大幅提升：过分追求稳定性限制了新功能的开发速度和将产品交付给用户的速度，并且很大程度地增加了成本，这反过来又减少了一个团队可以提供的新功能的数量。
|
||
|
||
> 尽管当时YouTube已经有了一个很出色的产品，但它仍然在不断变化和快速发展着。因此，我们为YouTube设定了一个相比我们企业的产品更低的可用性目标，因为快速发展更加重要。
|
||
|
||
> 一种在符合成本效益条件下满足这些竞争性约束的方式就是将基础设施分割成多个服务，在多个独立的服务水平上提供该服务。
|
||
|
||
> 对意外事件的容忍程度有多高？做得太少，我们就只能设计出一个脆弱无用的产品。做得太多，我们的产品可能没有人会使用（但运行非常稳定
|
||
|
||
> SLI是指服务质量指标（indicator）—该服务的某项服务质量的一个具体量化指标。
|
||
|
||
> 如果系统正常运转中需要人工干预，应该将此视为一种Bug。
|
||
|
||
> SRE的一个公开目标是保持每个SRE的工作时间中运维工作（即琐事）的比例低于50%。SRE至少花50%的时间在工程项目上，以减少未来的琐事或增加服务功能。
|
||
|
||
> 让我们多创新，少干琐事吧！
|
||
|
||
> 监控系统应该解决两个问题：什么东西出故障了，以及为什么出故障。
|
||
|
||
> “现象”和“原因”的区分是构建信噪比高的监控系统时最重要的概念。
|
||
|
||
> 监控系统的4个黄金指标分别是延迟、流量、错误和饱和度（saturation）。
|
||
|
||
> ● 每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。● 每个紧急警报都应该是可以具体操作的。● 每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要一个固定的机械动作，那么它就不应该成为紧急警报。● 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。
|
||
|
||
> -mail警报的价值通常极为有限，很容易变成噪声。我们应该倾向于构建一个良好的监控台页面，直接显示所有的非紧急的异常情况。
|
||
|
||
> 一致性地执行范围明确、步骤已知的程序—是自动化的首要价值。
|
||
|
||
> 在行业内普遍认同的是，在产品生命周期中一个问题越晚被发现，修复代价越高；
|
||
|
||
> 自动化是“元软件”，也就是操作其他软件的软件。
|
||
|
||
## 笔记
|
||
|
||
|
||
> 系统运维长久以来都依赖实践积累之上的口口相传，经验通常是领域从业者手里掌握的秘诀。
|
||
|
||
💭 人肉运维哈哈哈
|
||
|
||
> 我们无法按照传统方式运维Google系统，必须要思考一种新的模式，但是同时我们也没有时间等待其他人验证和支持我们的理论。
|
||
|
||
💭 适合自己的才是最好的
|
||
|
||
> 有统计显示，一个软件系统的40%～90% 的花销其实是花在开发建设完成之后不断维护过程中的。[1]
|
||
|
||
💭 就像生孩子一样，十月怀胎一朝分娩，一辈子成人。
|
||
|
||
> 从本质上来说，SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。这些SRE倾向于通过设计、构建自动化工具来取代人工操作。
|
||
|
||
💭 yaml 工程师哈哈哈
|
||
|
||
> 从本质上来说，SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。这些SRE倾向于通过设计、构建自动化工具来取代人工操作。
|
||
|
||
💭 标准化，流程化，自动化
|
||
|
||
> 如果100% 不是一个正确的可靠性目标，那么多少才是呢？这其实并不是一个技术问题，而是一个产品问题。
|
||
|
||
💭 技术服务于客户
|
||
|
||
> 到底什么是琐事？琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。
|
||
|
||
💭 人肉运维哈哈哈
|
||
|
||
## 书评
|
||
|
||
|
||
## 点评
|