2024-02-26 20:18:55 +08:00
---
doc_type: weread-highlights-reviews
bookId: "26271721"
author: 仲平
cover: https://wfqqreader-1252317822.image.myqcloud.com/cover/721/26271721/t7_26271721.jpg
2024-03-19 17:34:36 +08:00
reviewCount: 17
noteCount: 132
readingStatus: 读完
progress: 98%
totalReadDay: 21
readingTime: 5小时53分钟
2024-02-26 20:18:55 +08:00
readingDate: 2023-04-09
title: SRE：
description: 在本书中，不仅展示了 Google 是如何运用各种计算机工具软件、硬件以持续部署和监控一些世界上最大的软件系统的。还展示了在运维过程中，
keywords:
- SRE：
- 贝特西·拜尔等
tags:
- 阅读/计算机-计算机综合
2024-03-19 17:34:36 +08:00
date: < % tp.date.now("YYYY-MM-DD") %>
finishedDate: 2024-03-17
2024-02-26 20:18:55 +08:00
---
## 简介
- **书名**： ：
- **作者**：
- **分类**：
- **ISBN**：
- **出版社**：电子工业出版社
## 概述
在本书中，不仅展示了 Google 是如何运用各种计算机工具软件、硬件以持续部署和监控一些世界上最大的软件系统的。还展示了在运维过程中，
## 划线
> 大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。
> SRE就是运行和管理这百万台服务器和众多分布式系统的关键。
> SRE强调的是对问题和故障的自动处理， ； ， ， ， ，
> 100%的可用性是不现实的， ， （ ） ，
> SRE是一群天生的怀疑论者， ， ，
> SRE其实是一群崇尚工匠主义的人， ，
> 本书体系化地覆盖了运维工作的方方面面，是一本运维行业的教科书。
> 更重要的是， ， ， ， ，
> 今天，我们能感受到整个行业都在鼓吹厚颜无耻的 “代码拿来主义”（ ） ，
> 一个公司的成长，意味着整个公司商业模式和工作模式的扩展，而不是简单的资源扩张
> 有统计显示， ～
> 从这个视角出发，我们认为如果软件工程职业主要专注于设计和构建软件系统，那么应该有另外一种职业专注于整个软件系统的生命周期管理。从其设计一直到部署，历经不断改进，最后顺利退役。
> 有的时候，
> 这与盖房子有些类似，如果一开始将整个地基打好并保持继续修缮，要比盖好房子之后再重新修改设计要容易得多
> 团队文化就是从一切经历中不断学习，包括来自那些我们最意想不到的地方的经历。
> 只有靠着对细节的不懈关注， ， ， ！ ！
> 不能将碰运气当成战略。
> 极端来说，研发部门想要：“随时随地发布新功能，没有任何阻拦”，而运维部门则想要：“一旦一个东西在生产环境中正常工作了，就不要再进行任何改动。”
> 由于两个部门使用的语境不同，对风险的定义也不一致。
> 开发团队宣称他们不再进行大规模的程序更新，而是逐渐转为功能开关调整、增量更新，以及补丁化。采用这些名词的唯一目的，就是为了绕过运维部门设立的各种流程，从而能更快地上线新功能。
> 目前来看， ～
> 所有的SRE团队成员都必须非常愿意、也非常相信用软件工程方法可以解决复杂的运维问题。
> （ ） （ ）
> SRE团队应该倾向于将基本的运维工作全部消除，
> 我们可以认为DevOps是SRE核心理念的普适版， ， ，
> “错误预算”起源于这样一个理念： ， （ ） ， ， （ ）
> 一个需要人工阅读邮件和分析警报来决定目前是否需要采取某种行动的系统从本质上就是错误的。监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。
> 但是长久看来一个手持“运维宝典”经过多次演习的on-call工程师才是正确之路
> 由一个简单的想法“我是一名软件工程师，这是我如何来应付重复劳动的办法”而生
> Google的大部分计算资源都存放在自主设计的数据中心中。这些数据中心拥有自己设计的供电系统、制冷系统、网络系统以及计算机硬件（
> 一个典型的Google数据中心的拓扑结构： （ ） （ ） （ ） ， （ ） （ ）
> 因为一个集群中包括很多硬件设备，每天硬件设备的损坏量很高。在一年内，一个单独集群中平均会发生几千起物理服务器损坏事件，会损失几千块硬盘。
> 如果一个工程师遇到了他工作的项目之外的一个基础组件的问题， ， （ ） ， ，
> 任何对自己项目代码的改动也需要代码评审。
> 有些项目组甚至在实践自动部署机制：提交一个新版本，测试通过后，将直接部署于生产环境。
> 监控系统都是运维生产环境必不可少的组件。如果没有针对服务的监控，就无从得知目前服务的状态，如果不知道服务的状态，就无从谈起维护服务的可靠性。
> 极端的可靠性会带来成本的大幅提升：过分追求稳定性限制了新功能的开发速度和将产品交付给用户的速度，并且很大程度地增加了成本，这反过来又减少了一个团队可以提供的新功能的数量。
> 尽管当时YouTube已经有了一个很出色的产品， ， ，
> 一种在符合成本效益条件下满足这些竞争性约束的方式就是将基础设施分割成多个服务，在多个独立的服务水平上提供该服务。
> 对意外事件的容忍程度有多高？做得太少，我们就只能设计出一个脆弱无用的产品。做得太多，我们的产品可能没有人会使用（但运行非常稳定
> SLI是指服务质量指标（ ）
> 如果系统正常运转中需要人工干预，
> SRE的一个公开目标是保持每个SRE的工作时间中运维工作（ ）
> 让我们多创新，少干琐事吧！
> 监控系统应该解决两个问题：什么东西出故障了，以及为什么出故障。
> “现象”和“原因”的区分是构建信噪比高的监控系统时最重要的概念。
> 监控系统的4个黄金指标分别是延迟、流量、错误和饱和度（ ）
> ● 每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。● 每个紧急警报都应该是可以具体操作的。● 每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要一个固定的机械动作，那么它就不应该成为紧急警报。● 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。
> -mail警报的价值通常极为有限， ，
> 一致性地执行范围明确、步骤已知的程序—是自动化的首要价值。
> 在行业内普遍认同的是，在产品生命周期中一个问题越晚被发现，修复代价越高；
2024-03-19 17:34:36 +08:00
> 自动化是“元软件”，也就是操作其他软件的软件。
> 广泛使用的工具有Puppet、Chef、cfengine， ，
> 如何管理包的版本？应该采用持续构建和部署的模型，还是应该定期构建？发布的频率应该怎样？应该使用什么策略管理配置文件？哪些发布过程的指标比较有用？
> 可靠性只有靠对最大程度的简化不断追求而得到。
> 我们的工作最终是在系统的灵活性和稳定性上维持平衡
> 有的时候为了灵活性而牺牲稳定性是有意义的。我在面临一个不熟悉的问题域时，经常进行“探索性编码”—给我写的任何代码设置一个明确的保质期，我清楚地知道自己需要先探索以及失败才能真正理解需要完成的任务。这种带保质期的可以在测试覆盖和发行管理上更宽松，因为它永远不会被发布到生产环境或被用户使用。
> 某种程度上， ： ， ，
> 我们可以将一个服务的健康程度指标分为低级需求： ， ： ，
> [插图]
> on-call轮值是很多运维和研发团队的重要职责，
> SRE团队和纯运维团队十分不一样的地方在于， ， ，
> 我们强调至少将SRE团队50%的时间花在软件工程上。在其余时间中， ，
> 1.对通用的故障排查过程的理解（ ）
> 当所有的可能都存在的时候，我们应该优先考虑最简单的解释
> 更糟的是，随着系统部署规模的不断增加，复杂性也在不断增加，监控指标越来越多。不可避免的，纯属巧合，一些现象会和另外一些现象几乎同时发生。
> 在大型问题中，你的第一反应可能是立即开始故障排查过程，试图尽快找到问题根源。这是错误的！不要这样做
> 正确的做法应该是：尽最大可能让系统恢复服务。
> 在大型系统中， ， （ ） ，
> 将你的想法明确地记录下来，包括你执行了哪些测试，以及结果是什么。[35]尤其是当你处理更加复杂的问题时，良好的文档可以让你记住曾经发生过什么，可避免重复执行。[36]如果你修改了线上系统，例如给某个进程增加了可用资源。系统化和文档化这些改变有助于将系统还原到测试前的状态，而不是一直运行在这种未知状态下。
> 东西早晚要坏的，这就是生活。
> 时间和经验一再证明，系统不但一定会出问题，而且会以没有人能够想到的方式出问题。
> 事故总控负责人最重要的职责就是要维护一个实时事故文档。该文档可以以wiki的形式存在， ， ：
> Google团队依靠下面几个宽松的标准——如果下面任何一条满足条件，
> 划分优先级：控制影响范围，恢复服务，同时为根源调查保存现场。事前准备：事先和所有事故处理参与者一起准备一套流程。信任：充分相信每个事故处理参与者，分配职责后让他们自主行动。反思：在事故处理过程中注意自己的情绪和精神状态。如果发现自己开始惊慌失措或者感到压力难以承受，应该寻求更多的帮助
> 考虑替代方案：周期性地重新审视目前的情况，重新评估目前的工作是否应该继续执行，还是需要执行其他更重要或者更紧急的事情。练习：平时不断地使用这项流程，直到习惯成自然。换位思考：上次你是事故总控负责人吗？下次可以换一个职责试试。鼓励每个团队成员熟悉流程中的其他角色。
> 最佳实践：公开奖励做正确事的人
> Google使用Outalator—一个故障跟踪工具来做这件事。Outalator系统被动收集监控系统发出的所有报警信息，
> 如果你还没有亲自试过某件东西，那么就假设它是坏的。
> 合并通用型人才（ ） ， ，
> 每个项目都有正确的时间点来引入领域专家。
> 按照QPS来规划服务容量， （ ： ）
> 如何给新手带上喷气背包，同时保证老手的速度不受影响
> [插图]图28-1：
> 这个团体活动， ，
> 紧急警报主要是通过设置专门的主on-call工程师来处理的。也就是说， ，
> 从某种意义上讲，人类可以被称为不完美的机器。人会感觉无聊，人的处理器（指思维方式）工作原理不清楚，用户界面（指沟通方式）也不太友好，效率也不高。
> 极化时间意味着当每个人来上班时，他们应该清晰地知道自己今天是否只是做项目工作，还是只是做中断性工作
> 工单处理应该由全职人员负责， ， ， ， ，
> 如果团队中需要很多人同时进行中断性任务，那么可能这种负载是不能持久的。有一系列方式可以降低整体的工单负载。
> 第一阶段：了解服务，了解上下文
> 日益增加的工单不应需要更多的SRE来处理。SRE模型的目标是仅仅在系统复杂度上升的时候才增加新人。你应该尝试引导团队建立健康的工作习惯，
> 对“未来的一件大事”的过度依赖
> 第二阶段：分享背景知识
> 书写一个好的事后总结作为示范
> 第三阶段： ， ，
> ● 从技术角度，最好是量化的角度指出团队需要改变的原因。● 提供一个详细、具体的“改变”作为例子。● 解释SRE经常采用的“常识”背后的逻辑推理过程。● 提供以可伸缩的方式来解决崭新情况所必需的核心理念。你的最后一个任务是书写一份报告。报告中应该重申你的观点、例子和逻辑推理过程。同时，该报告应该向团队提供一些待办事项，来保证他们会实践你所传授的东西。你应该将报告组织成一份检查报告[12]，解释成功路上的每一个重要的决策。
> 就像数据必须围绕生产流动那样， ， ， ， ，
> 。生产会议是一种特殊的会议。在这个会议中， ，
> 一般来说，单人项目最终肯定会失败，除非此人个人能力超强或者待解决的问题是非常简单直接的。做成任何高价值的事情都需要很多人共同协作
> 因为人与人之间的沟通方式差异很大，第一次见面时书面表达习惯和口语表达习惯中隐含的微妙暗示很容易被误解。在项目开始之初，那些不在总部工作的团队成员经常会错过会议开始之前和结束之后立刻进行的即兴讨论（现在的沟通渠道已经大大改善了）。
> 其次， ， ，
> 最佳实践代码化将生产环境中运行良好的最佳实践代码化， ， ， ， ， ， ， （ ， ）
> 建立了一系列SRE支持的平台和服务框架
> 服务框架以一个标准化的方式实现了基础设施部分的代码并且预先解决了常见的各种生产问题
> SRE通过构建框架模块来实现这些关注重点的标准解决方案。其结果是， ，
> ● 究竟发生了什么● 响应的有效程度● 下次是否可以采用其他方案解决问题● 如何确保这次故障不会再次发生
> 纠结于“谁”造成了这个故障是没有意义的。事后总结在每次事故发生之后都会进行， ，
> 采用的标准是如果整个发电站需要在少于30分钟的时间内响应某种情况，
> 某项决策的基本方向是事先决定的，而不是事后得出的。● 决策时考虑的信息源是清楚的。● 任何假设都应该明确说明。● 数据驱动决策要优于情感驱动的决策、直觉驱动的决策，以及资深人士的意见。
> 飞机上布满了非常可靠的、冗余度非常高的系统。这就是不断重视安全与可靠性的后果
> 高可用性、性能极度优化、变更管理、监控与报警、容量规划，以及应急处理。
> 越精简越好，他们所操作的东西应该更抽象而非更具体
> [插图]
> 紧急警报某个人必须执行某项操作。工单某个人必须在几天之内执行某种操作。日志没有人会马上看这些日志，但是以后需要的时候可以用来分析。
> 每次on-call轮值应该处理不超过两起事故（ ） ：
> 泄洪集群，
2024-02-26 20:18:55 +08:00
## 笔记
> 系统运维长久以来都依赖实践积累之上的口口相传，经验通常是领域从业者手里掌握的秘诀。
💭 人肉运维哈哈哈
> 我们无法按照传统方式运维Google系统， ，
💭 适合自己的才是最好的
> 有统计显示， ～
💭 就像生孩子一样，十月怀胎一朝分娩，一辈子成人。
> 从本质上来说，
💭 yaml 工程师哈哈哈
> 从本质上来说，
💭 标准化，流程化，自动化
> 如果100% 不是一个正确的可靠性目标，那么多少才是呢？这其实并不是一个技术问题，而是一个产品问题。
💭 技术服务于客户
> 到底什么是琐事？琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。
💭 人肉运维哈哈哈
2024-03-19 17:34:36 +08:00
> 如果事先没有针对可能发生的紧急事故进行过演习，那么当事故发生时，一切管理理念都起不了作用
💭 演习，演习，还是演习。
> 我们将之前的某篇事后总结的场景再现，一批工程师负责扮演这篇文档中提到的各种角色。经常，当时的事故总控负责人也参与其中，确保这次演习越真实越好。
在引入事后总结机制
💭 事后总结
> SRE团队最需要的就是技能的多样性，
💭 广度
> 不要过于关注完美和解决方案的纯粹性，尤其是当待解决问题的边界不够清晰时。我们应该更快地发布和迭代。
💭 更快的去做，更多的去尝试。知行合一！
> Google SRE团队通过一个老传统—“故障处理分角色演习”来解决这些问题。这个活动同时也被称为“命运之轮”（ ） （ ） ，
💭 沙盘模拟经营很重要！
> 为了限制干扰数量， （ ） ， ， ， ， ， （
💭 上下文切换
> SRE则恰恰相反。他们通过编写软件系统或者消除系统瓶颈的方法来解决这个问题。
💭 熵减
> SRE团队陷入Ops模式的原因是过分关注如何快速解决紧急事件而不是如何减少紧急事件的数量。
💭 治标也要治本！
> SRE团队成员拥有系统工程或架构能力（ ） ， （ ）
💭 扫地僧
> 在本章中， ， ：
● 灾难预案与演习
● 书写事后总结的文化
● 自动化与降低日常运维负载
● 结构化的、理智的决策
💭 标准化，流程化，自动化
2024-02-26 20:18:55 +08:00
## 书评
## 点评
