annotation

need check

10_附录A-SLO文档示例.md

@@ -60,3 +60,9 @@ SLO使用四个星期的滚动窗口。
 - 我们仅将HTTP 5XX状态消息视为错误代码；其他一切都算成功。
 
 - 正确性探测器使用的测试数据包含大约200个测试，每1秒注入一次。我们的错误预算是每四周48个错误。
+
+
+<br/>
+<br/>
+
+[^115]: 即使SLO中的数字不是严格依据证据的，也有必要对此进行记录，以使将来的读者可以理解这一事实，并做出适当的决定。他们可能会决定值得收集更多证据的投资。

11_附录B-错误预算政策示例.md

@@ -77,3 +77,14 @@
 错误预算为1减去服务的SLO。99.9％的SLO服务的错误预算为0.1％。
 
 如果我们的服务在四个星期内收到1,000,000个请求，则99.9％的可用性SLO会为我们提供该期间1,000个错误的预算。
+
+
+<br/>
+<br/>
+
+
+[^116]: P0是错误的最高优先级: 所有人都在甲板上；放下其他所有东西，直到解决为止。
+
+
+
+[^117]: 在Google，季度计划是公开的，团队要对其计划负责。

5_第1章-SRE和DevOps的关系.md

@@ -189,3 +189,54 @@ DevOps和SRE都需要讨论，管理支持和实际工作人员的支持，以
 - [*云系统管理实践:Web* *服务的DevOps和SRE实践，第2卷*](https://amzn.to/2GZSY86)
 
 - [*加速:精益软件和DevOps科学*](https://amzn.to/2LGQ9fK)
+
+
+
+<br/>
+<br/>
+
+[^1]: 请注意，此讨论出现在有关SRE的书中，其中一些讨论特定于软件服务操作，而不是IT操作。
+
+[^2]: 玛丽·波彭迪克(Mary Poppendieck)在这方面有一篇出色的文章，名为"[成本中心陷阱](http://bit.ly/2LRFkHt)"。这种方法失败的另一种方式是，当一场非常大且不可能的灾难完全抵消了您采用低等级运营模式所节省的成本时(参见[2017年5月英国航空公司的停运](https: //ind.d pn/2LNQflE))。
+
+[^3]: 当然，还有许多其他潜在的反应。例如，ITIL®是另一种IT管理方法，倡导更好的标准化。
+
+[^4]: 还要注意，因为这是一个复杂的世界，所以也存在[正效应](http://bit.ly/2JaOddH)到[分区](http://bit.ly/2L9Mw0s)，孤岛等，但是在运营领域，不利因素似乎尤其严重。
+
+[^5]: 请参阅[*https: //en.wikipedia.org/wiki/Normal_Accidents*](https://en.wikipedia.org/wiki/Normal_Accidents)。
+
+[^6]: 较高风险的更改或无法通过自动方式确认的更改，显然应该由人类审核，即使不是由他们实施的。
+
+[^7]: Google的SRE历史来自前身的团队，该团队更注重运营，Ben从工程的角度提供了解决问题的动力。
+
+[^8]: 这在很多方面都是用词不当，也许最根本的原因是您不能仅仅雇用一些人，称他们为"DevOps工程师"，并立即期望收益。您必须接受改变工作方式以受益的全部理念。正如[Andrew Clay Shafer](http://bit.ly/2sy7UVI)所说一样，"人们出售DevOps，但您买不到。"而且，正如Seth Vargo在["DevOps的十大神话"](http://bit.ly/2HcHmP1)中指出的那样，您不能"雇用DevOp来修复您的组织"。
+
+[^9]: 服务水平目标是特定指标性能的目标(例如，有99.9％的时间可用)。
+
+
+[^10]: 当然，不是每个团队都做所有事情，但是这些是SRE工作的最常见标题。
+
+[^11]: 如果您将其视为分层堆栈，请执行分层冲突。
+
+[^12]: 实际上，有任何内容*的生产准备情况审查； SRE不仅会从一开始就提供车载服务。
+
+[^13]: 服务通常被定义为运行以执行某些业务需求的软件，通常具有可用性约束。
+
+
+[^14]: 在Google内部，这个问题已得到解决，服务始终会更改状态，配置，所有权，方向等。在一定程度上，Google的SRE曾是"抗争是必要的"论点的受益者，该论点过去曾被抗争并赢得过多次胜利。但是，正如威廉·吉布森(William Gibson)可能说的那样，并不是完全[均匀分布](http://bit.ly/2J1qnFf)。
+
+[^15]: 请参阅[*https://devops-research.com/research.html*](https://devops-research.com/research.html)上的相关研究。
+
+[^16]: 请参阅[*http: //en.wikipedia.org/wiki/Goodhart%27s_law*](http://en.wikipedia.org/wiki/Goodhart%27s_law)和[*https: //skybrary.aero/bookshelf/books/2336.pdf*](https://skybrary.aero/bookshelf/books/2336.pdf)。
+
+
+[^17]: 参见例如[*https: //codeascraft.com/2012/05/22/blameless-postmortems/*](https://codeascraft.com/2012/05/22/blameless-postmortems/)。
+
+[^18]: 在具有发达文化的组织中。早期公司可能没有建立奖励这些工作角色的方法。
+
+[^19]: 确实，可以说，除非您外包操作，否则这是您的*唯一*选择。
+
+[^20]: 有关如何在不同上下文中应用SRE原则的讨论，请参见第20章。
+
+
+[^21]: 换句话说，简单地淘汰一组DevOps或SRE，而无需改变他们的组织位置，导致在无法实现预期的改进时不可避免地使团队蒙羞。

6_第一部分-基础/6-1_第2章-实施SLO.md

@@ -606,3 +606,29 @@ SLO为服务的客户设置了目标可靠性级别。高于此阈值，几乎
 - 您应该立即开始使用SLO和错误预算。
 
 有关示例SLO文档和示例错误预算策略，请参阅附录A和B。
+
+
+
+<br/>
+<br/>
+
+
+[^22]: 关于术语的注释: 在本章中，我们始终使用"可靠性"一词来谈论服务在其所有SLI方面的性能。这可能表示许多情况，例如可用性或延迟。
+
+[^23]: 这不同于*服务水平协议*(SLA)，后者是一种商业合同，当您的用户非常不满意时，您必须以某种方式对其进行赔偿。
+
+[^24]: 有关将依赖项分解为服务可靠性的更多详细信息，请参阅Ben Treynor，Mike Dahlin，Vivek Rau和Betsy Beyer，"服务可用性的微积分"，* ACM队列* 15，否。 2(2017)，[*https: //**queue.acm.org/detail.cfm?id=3096459*](https://queue.acm.org/detail.cfm?id=3096459)。
+
+
+[^25]: 如果您在一个日历周期(例如一个季度)内衡量SLO，那么如果它基于流量等不可预测的指标，那么您可能不知道该季度末的预算将是多少。有关报告期间的更多讨论，请参见第29页"选择合适的时间窗口"。
+
+
+[^26]: 免责声明: 您将来可能会遇到更艰巨的任务。
+
+
+[^27]: *Recall*是SLI捕获的重大影响用户事件的比例。*Precision*是SLI捕获的严重影响用户的事件的比例。
+
+[^28]: 这里值得重申的是，错误预算是用户满意度的近似值。每30天四小时的中断可能会导致不满意的用户少于每30天四次单独的一小时中断，这反过来会导致不满意的用户少于0.5％的恒定错误率，但是我们的错误预算将相同。这些阈值因服务而异。
+
+
+[^29]: 如果依赖项不可用，则意味着依赖也很关键。

6_第一部分-基础/6-2_第3章-SLO工程案例研究.md

@@ -369,4 +369,16 @@ VALET仪表板使用户可以立即报告许多服务的SLO，并以多种方式
 
 SLO和错误预算是功能强大的概念，可帮助解决许多不同的问题集。Evernote和Home Depot的这些案例研究提供了非常真实的示例，说明了实施SLO文化如何使产品开发和运维更紧密地联系在一起。这样做可以促进沟通并更好地为开发决策提供依据。最终，它将为您的客户带来更好的体验-无论这些客户是内部，外部，人工还是其他服务。
 
-这两个案例研究突显了SLO文化是一个持续的过程，而不是一次性解决方案或解决方案。尽管它们具有相同的哲学基础，但THD和Evernote的度量方式，SLI，SLO和实现细节却截然不同。通过证明SLO实施不必特定于Google，这两个故事补充了Google对SLO的看法。正如这些公司为自己的独特环境定制SLO一样，其他公司和组织也可以。
+这两个案例研究突显了SLO文化是一个持续的过程，而不是一次性解决方案或解决方案。尽管它们具有相同的哲学基础，但THD和Evernote的度量方式，SLI，SLO和实现细节却截然不同。通过证明SLO实施不必特定于Google，这两个故事补充了Google对SLO的看法。正如这些公司为自己的独特环境定制SLO一样，其他公司和组织也可以。
+
+
+<br/>
+<br/>
+
+
+[^30]: 但这是另一本书的故事---在[*http: //bit.ly/2spqgcl*](http://bit.ly/2spqgcl)上查看更多详细信息。
+
+
+[^31]: 培训选择范围从一个小时的入门到半天的工作坊，再到与成熟的SRE团队进行为期四周的沉浸式学习，并附有毕业典礼和FiRE徽章。
+
+[^32]: 如在1999年的电影[*Office Space*](http://www.imdb.com/title/tt0151804/)中出名。

6_第一部分-基础/6-3_第4章-监控.md

@@ -282,4 +282,24 @@ AND the 'exception' field did not contain 'com.google.ads.PasswordException' THE
 我们希望通过指出我们发现有用的监控系统功能以及原因，可以帮助您评估监控策略满足您的需求的程度，探索您可能能够利用的其他功能以及考虑可能要进行的更改。您可能会发现将一些度量标准来源和日志记录结合到监控策略中很有用；您需要的确切组合在很大程度上取决于上下文。确保收集用于特定目的的指标。该目的可能是为了更好地进行容量规划，协助调试或直接将问题通知您。
 
 
-监控到位后，它必须可见且有用。为此，我们还建议您测试监控设置。一个好的监控系统可以带来好处。值得进行大量投资，以深入思考哪种解决方案最能满足您的需求，并进行迭代直到您找到正确的解决方案。
+监控到位后，它必须可见且有用。为此，我们还建议您测试监控设置。一个好的监控系统可以带来好处。值得进行大量投资，以深入思考哪种解决方案最能满足您的需求，并进行迭代直到您找到正确的解决方案。
+
+
+<br/>
+<br/>
+
+
+[^33]: 例如，使用promtool来验证您的Prometheus配置在语法上是正确的。
+
+
+
+
+[^34]: 您可以通过公共库导出基本指标: 诸如[OpenCensus](https://opencensus.io/)之类的检测框架，或[Istio](https://istio.io/)之类的服务网格。
+
+[^35]: 有关Borgmon的概念和结构，请参见*Site Reliability Engineering*的[Chapter 10](http://bit.ly/2svQKYN)。
+
+
+
+[^36]: 在这种情况下，通过日志进行监控很有吸引力，特别是因为生产更改相对很少。无论您使用日志还是指标，这些更改都应在仪表板上显示，以便调试生产问题时可以轻松访问。
+
+[^37]: 请参阅[*https: //opencensus.io/*](https://opencensus.io/)，以获取提供此功能的一组库。

6_第一部分-基础/6-4_第5章-基于SLO发出警报.md

@@ -461,3 +461,18 @@ NO_SLO
 如果您设置的SLO有意义，可以理解并以指标表示，则可以将警报配置为仅在错误预算有可操作的特定威胁时通知呼On-Call的人。
 
 在重大事件上发出警报的技术范围包括从错误率超过SLO阈值时发出警报到使用多个级别的消耗率和窗口大小。在大多数情况下，我们认为多窗口，多消耗率警报技术是捍卫应用程序SLO的最合适方法。希望我们为您提供了为您自己的应用程序和组织做出正确的配置决策所需的上下文和工具。
+
+
+<br/>
+<br/>
+
+
+[^38]: 当您在很短的持续时间内过滤掉短暂的噪声时，Duration子句有时会很有用。但是，您仍然需要注意本节中列出的缺点。
+
+[^39]: 如"站点可靠性工程"的[简介](http://bit.ly/2xCtP3S)中所述，页面和故障单是促使人们采取行动的唯一有效方法。
+
+[^40]: "测量内容: 第20页上的"使用SLI"建议一种SLI样式，该样式将根据对用户的影响进行缩放。
+
+[^41]: 请参阅《站点可靠性工程》中的["过载和故障"](http://bit.ly/2J2gqr0)。
+
+[^42]: 除临时更改警报参数外，这是解决持续中断的必要条件，并且在此期间不需要接收通知。

6_第一部分-基础/6-5_第6章-消除琐事工作.md

@@ -686,3 +686,34 @@ Moira团队在某些方面采用了"幕后工程师"方法，将自动化与工
 重要的是要注意，消除琐事并非总是最好的解决方案。如本章通篇所述，您应考虑与确定，设计和实施琐事相关的流程或自动化解决方案相关的可衡量成本。一旦确定了琐事工作，就必须使用指标，投资回报率(ROI)分析，风险评估和迭代开发来确定何时应减少琐事工作。
 
 琐事通常从小事开始，并且会迅速成长以消耗整个团队。SRE团队必须坚持不懈地消除琐事，因为即使任务看起来艰巨，收益通常也超过成本。我们描述的每个项目都需要各自团队的毅力和奉献精神，有时他们会与怀疑论或机构抵制作斗争，并且总是面临着相互竞争的高度优先事项。我们希望这些故事能够鼓励您识别自己的琐事，对其进行量化，然后努力消除它。即使您今天不能投资大型项目，也可以从一个小的概念证明入手，这可以帮助您的团队改变工作的意愿。
+
+
+<br/>
+<br/>
+
+
+
+[^43]: 这里列出的最主观的特征是是否可以自动化。通过自动完成工作来积累经验，您的观点将不断发展。一旦您习惯了"让机器人来完成工作"，那么一个看起来难以解决(或过于冒险)的问题空间将变得可行。
+
+[^44]: 一些工程师不介意长时间工作-并非每个人的劳动容忍阈值都相同。从长远来看，琐事会导致职业停滞，同时促进职业倦怠引起的离职。一定程度的琐事是不可避免的，但我们建议在可行的情况下减少辛勤工作，以维护团队，服务和个人的健康。
+
+
+[^45]: 换句话说，如果一项服务及其九个依赖项各自具有99.99％的可用性，则该服务的总可用性将为0.9999^10 = 99.9％。有关依赖关系如何影响服务可用性的更多信息，请参阅["服务可用性计算"](http://queue.acm.org/detail.cfm?id=3096459)。
+
+[^46]: 当然，您将无法通过自助服务来处理一些一次性的情况("您想让一个VM具有*多少*个RAM?")，但旨在涵盖大多数用例。将80--90％的请求转移到自助服务上仍然大大减少了工作量！
+
+[^47]: 简而言之，从单个专用设备向具有公共接口的设备群过渡。请参阅"案例研究1: 有关对此类比的详细说明，请参见第107页的"通过自动化减少数据中心中的工作量"。
+
+[^48]: 线卡是一个模块化组件，通常为网络提供多个接口。它与其他线卡和组件一起位于机箱的底板中。模块化网络交换机由一个机箱组成，该机箱包括一个背板，电源输入模块，控制卡模块以及一个或多个线卡。每个线卡都支持到计算机或其他线卡(在其他交换机中)的网络连接。与USB网络接口适配器一样，您可以在不关闭整个交换机电源的情况下更换任何线卡，前提是线卡已"排空"，这意味着已告知其他接口停止向其发送流量。
+
+[^49]: 误码率测试: 在恢复服务之前检查链路是否不正常。
+
+[^50]: 检查连接错误的端口。
+
+[^51]: Piper是Google的内部版本控制系统。有关更多信息，请参阅Rachel Potvin和Josh Levenberg, "Google为什么要在单个存储库中存储数十亿行代码"，*ACM通讯* 59，第1页。 7(2016): 78--87，[*http: //bit.ly/2J4jgMi*](http://bit.ly/2J4jgMi)。
+
+[^52]: Google还具有可扩展的自助式Git托管，用于托管Piper中不存在的代码。
+
+[^53]: [Beyond Corp](https://cloud.google.com/beyondcorp/)是一项计划，旨在从传统的基于边界的安全性模型转变为基于密码身份的模型。当Google笔记本电脑连接到内部Google服务时，该服务通过识别笔记本电脑的加密证书，用户拥有的第二个因素(例如USB安全密钥)，客户端设备的配置/状态和用户的凭证。
+
+[^54]: x20是一个内部全局共享的，高度可用的文件系统，具有类似POSIX的文件系统语义。

6_第一部分-基础/6-6_第7章-简单化.md

@@ -233,3 +233,20 @@ pDNS本身具有传递性依赖关系，在某个时候无意中引入了它，
 由于SRE对系统具有端到端的了解，因此它们非常适合识别，预防和修复复杂性源，无论它们是在软件设计，系统体系结构，配置，部署过程还是其他位置发现的。SRE应该尽早参与设计讨论，以提供其对替代方案的成本和收益的独特见解，并特别注重简单化。SRE还可主动制定标准以使生产同质化。
 
 作为SRE，追求简单是您工作描述的重要组成部分。我们强烈建议SRE领导授权SRE团队推动简单化，并明确奖励这些努力。系统在发展过程中不可避免地会趋于复杂，因此为简单起见，需要不断的关注和投入-但它非常值得追求。
+
+
+<br/>
+<br/>
+
+
+[^55]: 如果您有兴趣了解更多信息，请阅读此软件复杂性趋势的最新[review](https://arxiv.org/abs/1608.01533)，或阅读Horst Zuse，*软件复杂性: 措施和方法*(柏林: Walter de Gruyter，1991年)。
+
+[^56]: 尽管有一些示例，例如-["AWS系统的自动化形式推理"](http://bit.ly/2spRz6g)。
+
+[^57]: 结果，SRE对于希望攻击复杂性作为产品技术债务代理的产品开发主管来说可能是一项有用的投资，但发现很难在现有团队的范围内证明这项工作的合理性。
+
+
+
+[^58]: 正如[Dijkstra](http://bit.ly/2xwycxq)所说，"如果我们希望对代码行进行计数，则不应将它们视为"产生的行"，而应视为"花费的行"。"
+
+[^59]: 为简单性项目保留一部分时间(例如10％)并不意味着团队就允许其他90％的团队引入复杂性开了绿灯。这只是意味着您将精力放在简化的特定目标上。

7_第二部分-实践/7-1_第8章-值班.md

@@ -619,3 +619,18 @@ SRE值班与传统运维角色不同。SRE不仅完全专注于日常运维，
 值班是造成个人和集体紧张的根源。但是，如果您凝视怪物的眼睛足够长的时间，就会看到智慧的一面。本章说明了我们通过艰苦学习所学到的有关值班的一些教训。我们希望我们的经验可以帮助其他人避免或解决类似问题。
 
 如果您的值班团队淹没在无尽的警报中，我们建议您退后一步，从更高层次观察情况。与其他SRE和合作伙伴团队比较笔记。收集必要的信息后，请系统地解决问题。为值班工程师，值班团队和整个公司花费大量时间进行周到的组织。
+
+
+<br/>
+<br/>
+
+
+[^60]: 请注意，对于实际上没有实践DevOps的组织，此示例通常是一个危险信号，在这种情况下，更名不会解决更多的结构性问题。
+
+[^61]: 一个"事件"被定义为一个"问题"，无论针对同一"问题"发出了多少警报。一班是12个小时。
+
+[^62]: David Blank-Edelman(O'Reilly)的[*Seeking SRE*](https://oreil.ly/2kIawNe)中有关于此主题的更多信息。
+
+[^63]: Google的SRE团队在各个时区配对，以确保服务的连续性。
+
+[^64]: 在这种情况下，"错误"是指由软件或配置错误引起的任何不良系统行为。代码中的逻辑错误，二进制文件的错误配置，不正确的容量计划，错误配置的负载平衡器或新发现的漏洞都是造成值班负载的"生产错误"的有效示例。