阅读：读书笔记

Book/计算机/SRE：Google运维解密.md

@@ -3,12 +3,12 @@ doc_type: weread-highlights-reviews
 bookId: "26271721"
 author: 仲平
 cover: https://wfqqreader-1252317822.image.myqcloud.com/cover/721/26271721/t7_26271721.jpg
-reviewCount: 7
+reviewCount: 17
-noteCount: 57
+noteCount: 132
-readingStatus: 在读
+readingStatus: 读完
-progress: 18%
+progress: 98%
-totalReadDay: 5
+totalReadDay: 21
-readingTime: 1小时29分钟
+readingTime: 5小时53分钟
 readingDate: 2023-04-09
 title: SRE：Google运维解密
 description: 在本书中，不仅展示了 Google 是如何运用各种计算机工具软件、硬件以持续部署和监控一些世界上最大的软件系统的。还展示了在运维过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。本书适合各种水平的运维工程师参考使用。
@@ -17,7 +17,8 @@ keywords:
   - 贝特西·拜尔等
 tags:
   - 阅读/计算机-计算机综合
-date: 2024-02-26
+date: <% tp.date.now("YYYY-MM-DD") %>
+finishedDate: 2024-03-17
 
 ---
 
@@ -138,7 +139,137 @@ date: 2024-02-26
 
 > 在行业内普遍认同的是，在产品生命周期中一个问题越晚被发现，修复代价越高； 
 
-> 自动化是“元软件”，也就是操作其他软件的软件。
+> 自动化是“元软件”，也就是操作其他软件的软件。 
+
+> 广泛使用的工具有Puppet、Chef、cfengine，甚至 Perl都提供了自动化完成特定任务的方法，主要区别在于对帮助进行自动化的组件的抽象层次不同。 
+
+> 如何管理包的版本？应该采用持续构建和部署的模型，还是应该定期构建？发布的频率应该怎样？应该使用什么策略管理配置文件？哪些发布过程的指标比较有用？ 
+
+> 可靠性只有靠对最大程度的简化不断追求而得到。 
+
+> 我们的工作最终是在系统的灵活性和稳定性上维持平衡 
+
+> 有的时候为了灵活性而牺牲稳定性是有意义的。我在面临一个不熟悉的问题域时，经常进行“探索性编码”—给我写的任何代码设置一个明确的保质期，我清楚地知道自己需要先探索以及失败才能真正理解需要完成的任务。这种带保质期的可以在测试覆盖和发行管理上更宽松，因为它永远不会被发布到生产环境或被用户使用。 
+
+> 某种程度上，这与面向对象编程中的类设计类似：正如普遍认同的，编写一个其中包含无关功能的“大杂烩”类是一个糟糕的实践。构建和发布“util”或“misc”二进制文件同样也是个糟糕的实践。一个设计良好的分布式系统是由一系列合作者组成的，每一个合作者都具有明确的、良好定义的范围。 
+
+> 我们可以将一个服务的健康程度指标分为低级需求：能够正常对外提供服务，和高级需求：SRE能够主动控制服务状态，而不是被动救火。 
+
+> [插图] 
+
+> on-call轮值是很多运维和研发团队的重要职责，这项任务的目标是保障服务的可靠性和可用性。 
+
+> SRE团队和纯运维团队十分不一样的地方在于，SRE团队非常强调用工程化手段来应对运维问题。而这些运维问题，当达到一定规模时，也确实只有采用软件工程化手段才能解决。 
+
+> 我们强调至少将SRE团队50%的时间花在软件工程上。在其余时间中，不超过25%的时间用来on-call，另外25%的时间用来处理其他运维工作。 
+
+> 1.对通用的故障排查过程的理解（不依靠任何特定系统）。2.对发生故障的系统的足够了解。 
+
+> 当所有的可能都存在的时候，我们应该优先考虑最简单的解释 
+
+> 更糟的是，随着系统部署规模的不断增加，复杂性也在不断增加，监控指标越来越多。不可避免的，纯属巧合，一些现象会和另外一些现象几乎同时发生。 
+
+> 在大型问题中，你的第一反应可能是立即开始故障排查过程，试图尽快找到问题根源。这是错误的！不要这样做 
+
+> 正确的做法应该是：尽最大可能让系统恢复服务。 
+
+> 在大型系统中，逐个检查可能太慢了，可以采用对分法（bisection）将系统分为两部分，确认问题所在再重复进行。 
+
+> 将你的想法明确地记录下来，包括你执行了哪些测试，以及结果是什么。[35]尤其是当你处理更加复杂的问题时，良好的文档可以让你记住曾经发生过什么，可避免重复执行。[36]如果你修改了线上系统，例如给某个进程增加了可用资源。系统化和文档化这些改变有助于将系统还原到测试前的状态，而不是一直运行在这种未知状态下。 
+
+> 东西早晚要坏的，这就是生活。 
+
+> 时间和经验一再证明，系统不但一定会出问题，而且会以没有人能够想到的方式出问题。 
+
+> 事故总控负责人最重要的职责就是要维护一个实时事故文档。该文档可以以wiki的形式存在，但是最好能够被多人同时编辑。大部分Google团队使用Google Docs，但是Google Docs 团队使用Google Sites做这件事：利用你正要修复的服务来修复该服务恐怕不是什么好主意。 
+
+> Google团队依靠下面几个宽松的标准——如果下面任何一条满足条件，这次事故应该被及时宣布。● 是否需要引入第二个团队来帮助处理问题？● 这次事故是否正在影响最终用户？● 在集中分析一小时后，这个问题是否依然没有得到解决？ 
+
+> 划分优先级：控制影响范围，恢复服务，同时为根源调查保存现场。事前准备：事先和所有事故处理参与者一起准备一套流程。信任：充分相信每个事故处理参与者，分配职责后让他们自主行动。反思：在事故处理过程中注意自己的情绪和精神状态。如果发现自己开始惊慌失措或者感到压力难以承受，应该寻求更多的帮助 
+
+> 考虑替代方案：周期性地重新审视目前的情况，重新评估目前的工作是否应该继续执行，还是需要执行其他更重要或者更紧急的事情。练习：平时不断地使用这项流程，直到习惯成自然。换位思考：上次你是事故总控负责人吗？下次可以换一个职责试试。鼓励每个团队成员熟悉流程中的其他角色。 
+
+> 最佳实践：公开奖励做正确事的人 
+
+> Google使用Outalator—一个故障跟踪工具来做这件事。Outalator系统被动收集监控系统发出的所有报警信息，同时提供标记、分组和数据分析功能。 
+
+> 如果你还没有亲自试过某件东西，那么就假设它是坏的。 
+
+> 合并通用型人才（generalist）和领域专家组成一个种子团队，通用型人才可以很快地开始工作，而资深领域专家可以提供更广阔的知识和经验。这样一个多样化的团队可以避免设计盲点。 
+
+> 每个项目都有正确的时间点来引入领域专家。 
+
+> 按照QPS来规划服务容量，或者是按照某种静态属性（认为其能指代处理所消耗的资源：例如某个请求所需要读取的键值数量）一般是错误的选择。 
+
+> 如何给新手带上喷气背包，同时保证老手的速度不受影响 
+
+> [插图]图28-1：培养SRE加入on-call的计划图 
+
+> 这个团体活动，每个季度会进行一次，有助于在生产环境中发现亟待解决的新Bug—系统并不会像我们想象的那样优雅降级。 
+
+> 紧急警报主要是通过设置专门的主on-call工程师来处理的。也就是说，让一个工程师独立接收和响应紧急警报，处理发生的事故或者故障。 
+
+> 从某种意义上讲，人类可以被称为不完美的机器。人会感觉无聊，人的处理器（指思维方式）工作原理不清楚，用户界面（指沟通方式）也不太友好，效率也不高。 
+
+> 极化时间意味着当每个人来上班时，他们应该清晰地知道自己今天是否只是做项目工作，还是只是做中断性工作 
+
+> 工单处理应该由全职人员负责，同时保证占用合理的时间。如果团队目前的工单主oncall和副on-call都处理不完，那么需要重新架构整个工单的处理流程，保障任何时间都有两个全职员工处理工单。不要将复杂分散到整个团队中去。人不是机器，这样做只会干扰员工，降低他们的工作效率 
+
+> 如果团队中需要很多人同时进行中断性任务，那么可能这种负载是不能持久的。有一系列方式可以降低整体的工单负载。 
+
+> 第一阶段：了解服务，了解上下文 
+
+> 日益增加的工单不应需要更多的SRE来处理。SRE模型的目标是仅仅在系统复杂度上升的时候才增加新人。你应该尝试引导团队建立健康的工作习惯，这样能够减少花费在工单上的时间。这与指出该服务目前还可以自动化或者进一步简化同样重要。 
+
+> 对“未来的一件大事”的过度依赖 
+
+> 第二阶段：分享背景知识 
+
+> 书写一个好的事后总结作为示范 
+
+> 第三阶段：主导改变保持团队健康是一个持续的过程。正因为此，这不是你可以通过个人英雄主义来解决的问题。为了确保团队在未来可以进行自我调节，我们需要帮助他们建立一个良好的SRE心理模型。 
+
+> ● 从技术角度，最好是量化的角度指出团队需要改变的原因。● 提供一个详细、具体的“改变”作为例子。● 解释SRE经常采用的“常识”背后的逻辑推理过程。● 提供以可伸缩的方式来解决崭新情况所必需的核心理念。你的最后一个任务是书写一份报告。报告中应该重申你的观点、例子和逻辑推理过程。同时，该报告应该向团队提供一些待办事项，来保证他们会实践你所传授的东西。你应该将报告组织成一份检查报告[12]，解释成功路上的每一个重要的决策。 
+
+> 就像数据必须围绕生产流动那样，数据也要围绕SRE团队流动—关于项目的数据，关于服务状态、生产环境状态以及个人状态的数据。团队的最佳运行状态是，数据可靠地从一个感兴趣的团队流动到另一个团队。思考这种流动的一个方法是思考SRE团队与其他团队建立的接口API。和设计一个API一样，好的设计对于有效性是至关重要的。如果API的设计是错误的，后续改正它将是非常痛苦的。 
+
+> 。生产会议是一种特殊的会议。在这个会议中，SRE团队向自己—以及邀请的嘉宾—描述服务的目前状态。这样那些关心服务的人对服务状态的了解程度得到了提高，同时也能提高服务自身的运维质量。 
+
+> 一般来说，单人项目最终肯定会失败，除非此人个人能力超强或者待解决的问题是非常简单直接的。做成任何高价值的事情都需要很多人共同协作 
+
+> 因为人与人之间的沟通方式差异很大，第一次见面时书面表达习惯和口语表达习惯中隐含的微妙暗示很容易被误解。在项目开始之初，那些不在总部工作的团队成员经常会错过会议开始之前和结束之后立刻进行的即兴讨论（现在的沟通渠道已经大大改善了）。 
+
+> 其次，也许是最好的方式，与其创造很多各异的个体系统交给SRE运维，不如直接让研发团队在一个通过SRE验证的基础设施平台上进行产品开发。 
+
+> 最佳实践代码化将生产环境中运行良好的最佳实践代码化，这样服务可以通过简单地使用这些代码，自然而然地成为“生产就绪”。可重复使用的解决方案常见并易于共享的技术实现，用于改善可扩展性和可靠性的问题。带有通用控制界面的通用生产操作平台生产设施的统一接口，统一的运维控制机制，以及统一的监控、日志以及服务配置。更简易的自动化和更智能的系统通用的控制接口使自动化和智能化达到一个以前不可能达到的水平。例如，SRE可以用一个统一的视图查看关于一次故障的全部相关信息，不用收集和分析来自不同数据源的原始数据（日志、监控数据，等等）。 
+
+> 建立了一系列SRE支持的平台和服务框架 
+
+> 服务框架以一个标准化的方式实现了基础设施部分的代码并且预先解决了常见的各种生产问题 
+
+> SRE通过构建框架模块来实现这些关注重点的标准解决方案。其结果是，因为该框架已经考虑了正确的基础设施的使用，所以研发团队可以更专注于业务逻辑的开发 
+
+> ● 究竟发生了什么● 响应的有效程度● 下次是否可以采用其他方案解决问题● 如何确保这次故障不会再次发生 
+
+> 纠结于“谁”造成了这个故障是没有意义的。事后总结在每次事故发生之后都会进行，同时会在整个SRE团队内部传阅，以便让所有人都能从中受益。 
+
+> 采用的标准是如果整个发电站需要在少于30分钟的时间内响应某种情况，那么这种响应必须要自动化进行。 
+
+> 某项决策的基本方向是事先决定的，而不是事后得出的。● 决策时考虑的信息源是清楚的。● 任何假设都应该明确说明。● 数据驱动决策要优于情感驱动的决策、直觉驱动的决策，以及资深人士的意见。 
+
+> 飞机上布满了非常可靠的、冗余度非常高的系统。这就是不断重视安全与可靠性的后果 
+
+> 高可用性、性能极度优化、变更管理、监控与报警、容量规划，以及应急处理。 
+
+> 越精简越好，他们所操作的东西应该更抽象而非更具体 
+
+> [插图] 
+
+> 紧急警报某个人必须执行某项操作。工单某个人必须在几天之内执行某种操作。日志没有人会马上看这些日志，但是以后需要的时候可以用来分析。 
+
+> 每次on-call轮值应该处理不超过两起事故（平均每12小时1个）： 
+
+> 泄洪集群，
 
 ## 笔记
 
@@ -171,6 +302,51 @@ date: 2024-02-26
 
 💭 人肉运维哈哈哈
 
+> 如果事先没有针对可能发生的紧急事故进行过演习，那么当事故发生时，一切管理理念都起不了作用
+
+💭 演习，演习，还是演习。
+
+> 我们将之前的某篇事后总结的场景再现，一批工程师负责扮演这篇文档中提到的各种角色。经常，当时的事故总控负责人也参与其中，确保这次演习越真实越好。
+在引入事后总结机制
+
+💭 事后总结
+
+> SRE团队最需要的就是技能的多样性，成员多元化的背景和多样化的解决问题的方式可以避免在团队中出现盲点。
+
+💭 广度
+
+> 不要过于关注完美和解决方案的纯粹性，尤其是当待解决问题的边界不够清晰时。我们应该更快地发布和迭代。
+
+💭 更快的去做，更多的去尝试。知行合一！
+
+> Google SRE团队通过一个老传统—“故障处理分角色演习”来解决这些问题。这个活动同时也被称为“命运之轮”（wheel of misfortune）或者 “走木板”（walk the plank）等，这些名字对新加入的SRE来说不会那么吓人。
+
+💭 沙盘模拟经营很重要！
+
+> 为了限制干扰数量，我们应该减少上下文切换（指工作类型、环境等的改变）。某些中断性任务是无法避免的。然而，将工程师当成是可以随时中断、上下文切换没有成本是不正确的。给每次上下文切换加上成本的考虑。在项目工作中，一次20分钟的中断性任务需要进行两次上下文切换，而这种切换会造成数个小时的生产力的丧失。为了避免这种经常性的生产力丧失，我们应该延长每种工作模式的时间，一天甚至半天都可以。这种策略与“挤时间”（参见文献[Gra09]）策略工作得很好。
+
+💭 上下文切换
+
+> SRE则恰恰相反。他们通过编写软件系统或者消除系统瓶颈的方法来解决这个问题。
+
+💭 熵减
+
+> SRE团队陷入Ops模式的原因是过分关注如何快速解决紧急事件而不是如何减少紧急事件的数量。
+
+💭 治标也要治本！
+
+> SRE团队成员拥有系统工程或架构能力（见文献[Hix15b]）、软件工程技术、项目管理能力、领导才能，各种行业背景的人都有（参见第33章）
+
+💭 扫地僧
+
+> 在本章中，我们会讨论到许多SRE的核心指导思想。为了简化与其他行业最佳实践的比较，我们将这些理念分为4大类：
+● 灾难预案与演习
+● 书写事后总结的文化
+● 自动化与降低日常运维负载
+● 结构化的、理智的决策
+
+💭 标准化，流程化，自动化
+
 ## 书评