你好居住者！ 《现场可靠性工程》一书引发了激烈的讨论。今天的运营情况是什么，为什么可靠性问题如此重要？现在，这本畅销书背后的Google工程师建议从理论过渡到实践-网站可靠性工作手册展示了SRE原理和实践如何转化为您的产品Google的专业知识可以通过Google Cloud Platform用户案例得到补充。 Evernote，家得宝，《纽约时报》和其他公司的代表描述了他们的战斗经验，告诉他们采用了哪些实践以及没有采用哪种实践。本书将帮助您使SRE适应您自己实践的现实，无论公司规模如何。您将学习：
- 确保不受您完全控制的云和环境中服务的可靠性；
- 应用各种创建，启动和监视服务的方法，重点放在SLO；
- 将管理团队转变为SRE工程师；
- 实现基于现有系统从头开始SRE的方法。Betsy Beyer，Neil Richard Murphy，David Renzin，Kent Kawahara和Stephen Thorne都参与了确保Google系统可靠性的工作。
监控系统管理
您的监视系统与您使用的任何其他服务一样重要。因此，应谨慎对待监测。
将您的配置视为代码将您的
系统配置视为代码，并将其存储在版本控制系统中是一种常见的做法，其功能包括存储更改历史记录，将特定更改链接到任务管理系统，简化的回滚，针对错误的静态代码分析以及强制代码检查程序。
我们还强烈建议将监视配置视为代码（有关配置的更多信息，请参阅第14章）。一个监视系统，该监视系统使用格式正确的目的和功能描述支持自定义，而不是仅提供Web界面或CRUD样式的API（http://bit.ly/1G4WdV1）的系统。对于许多仅读取配置文件的开源二进制文件，此配置方法是标准的。某些第三方解决方案，例如grafanalib（http://bit.ly/2so5Wrx），对于传统上可以使用UI进行自定义的组件都支持这种方法。
鼓励一致性
拥有多个使用监视的项目团队的大型公司需要在微妙的平衡之间：一方面，集中化的方法可以确保一致性，另一方面，各个团队可能希望完全控制其配置的工作方式。
正确的决定取决于您的组织类型。随着时间的流逝，Google的方法已经演变为将所有最佳实践整合到一个可作为集中服务的平台上。这对我们来说是一个很好的决定，并且有很多原因。通用的基础结构使工程师可以更快，更轻松地从一个团队迁移到另一个团队，并使得调试时的协作更加轻松。此外，还有一个集中式仪表板服务，每个团队的仪表板都可以打开并访问。如果您了解其他团队提供的信息，则可以快速解决自己的问题以及其他团队的问题。
尽可能使基本监视范围尽可能简单。如果所有服务均导出一致的基准集，则可以自动收集整个组织的那些指标并提供一致的仪表板集。这种方法意味着对您自动启动的任何新组件都有基本的监视。这样，公司中的许多团队，甚至不是工程团队，都将能够使用监视数据。
优先考虑弱关系
业务需求的变化和您的生产系统在一年中会看起来有所不同。就像您控制的服务一样，您的监视系统必须随着时间的流逝而发展和演进，并遇到各种典型的问题。
我们建议控制系统组件之间的耦合不是很牢固。您必须具有可靠的接口才能配置每个组件并传输监视数据。不同的组件应负责收集，存储，警告和可视化监视数据。稳定的接口使您可以轻松地用最合适的替代品替换任何特定组件。
在开源世界中，将功能分解为单独的组件变得很流行。十年前，诸如Zabbix（https://www.zabbix.com/）的监视系统将所有功能组合为一个组件。现代设计通常涉及分离规则的收集和执行（使用诸如Prometheus服务器（https://prometheus.io/）之类的解决方案），存储长期时间序列（InfluxDB，www.influxdata.com），汇总警报（ Alertmanager，bit.ly/2soB22b）并创建仪表板（Grafana，grafana.com）。
在撰写本文时，至少有两个流行的开放标准，可让您为软件配备必要的工具并提供指标：
- statsd — , Etsy, ;
- Prometheus — , . Prometheus OpenMetrics (https://openmetrics.io/).
使用多个数据源的单独的仪表板系统提供了服务的集中式和统一视图。 Google最近在实践中获得了这一优势：我们的旧版监控系统（Borgmon1）将仪表板与警报规则绑定在一起。当切换到新系统（Monarch，youtu.be / LlvJdK1xsl4）时，我们决定将仪表板移至单独的服务（Viceroy，bit.ly / 2sqRwad）。 Viceroy不是Borgmon或Monarch组件，因此Monarch的功能需求较少。由于用户可以使用Viceroy基于来自两个监视系统的数据显示图形，因此他们能够逐渐从Borgmon迁移到Monarch。
有意义的指标
第5章向您展示了如何使用服务质量（SLI）指标来跟踪和报告预算威胁。 SLI指标是根据服务质量（SLO）目标检查何时触发警报的第一个指标。这些指标应显示在服务的仪表板上，最好显示在首页上。
在调查违反SLO的根本原因时，您很可能不会从SLO面板中获得足够的信息。这些面板显示存在违规情况，但是您不太可能知道导致违规的原因。仪表板上应显示哪些其他数据？
我们认为，以下准则在实施指标时会有所帮助：这些指标应提供有意义的监视，使您可以调查操作问题并提供有关服务的广泛信息。
有意更改
在诊断与SLO相关的警报时，您需要能够从通知您有关影响用户的问题的警报指标转移到向您发出这些问题的根本原因的指标。这些原因可能是您最近对服务进行的有意更改。添加监视，以通知您生产中的任何更改。要检测已进行更改的事实，我们建议以下操作：
- 监视二进制文件的版本；
- , ;
- , .
如果未对这些组件中的任何一个进行版本控制，则需要跟踪组件的最后组装或打包时间。
当尝试将新兴服务问题与部署相关联时，查看警报中引用的图表或面板要比事后浏览CI / CD日志容易得多。
依赖关系
即使您的服务没有更改，其任何依赖关系也可以更改。因此，您还需要跟踪来自直接依赖项的响应。
明智的是，导出每个依赖项的请求和响应大小（以字节为单位），响应时间和响应代码。为图表选择指标时，请牢记这四个黄金信号（请参阅“站点可靠性工程的第6章，“四个黄金信号”）。
您可以在指标中使用其他标签，以按响应代码，RPC（远程过程调用）方法名称和被调用服务的名称将它们分开。
理想情况下，您无需为此要求每个RPC客户端库导出此类标签，而是可以使用一次较低级别的RPC客户端库。这提供了更大的一致性，并允许您轻松监视新的依赖性。
有一些依赖项提供了非常有限的API，其中所有功能都可以通过一个称为Get，Query的RPC方法获得，或者也可以作为非信息性，并且将实际命令指定为该方法的参数。客户端库中的工具的单点方法不适用于这种类型的依赖关系：您会看到延迟方面的很多可变性以及一定百分比的错误，这些错误可能表示也可能不表示此“泥泞”部分该API已完全失效。如果此依赖性很重要，则可以通过以下方式对其进行良好的监视。
- 导出专门为此依赖性设计的单独度量标准，在该度量标准中，将对请求进行解包以获得有效信号。
- 要求依赖关系的所有者重写它，以导出扩展的API，该API支持单独的RPC服务和方法之间的功能分离。
工作负载的级别
希望控制和跟踪与服务一起使用的所有资源的使用。一些资源具有您不能超过的硬限制。例如，RAM的大小，分配给您的应用程序的硬盘或CPU配额。其他资源，例如打开文件描述符，任何线程池中的活动线程，队列超时或写入的日志量，可能没有明确的硬上限，但仍需要进行管理。
根据您使用的编程语言，您需要跟踪一些其他资源：
- 在Java中，堆和元空间（http://bit.ly/2J9g3Ha），以及更具体的指标取决于所使用的垃圾回收的类型；
- 在Go中，goroutine的数量。
编程语言本身为跟踪这些资源提供了各种支持。
如第5章所述，除了提醒您发生重大事件外，您还可能希望设置在某些资源接近严重耗竭时触发的警报。例如，在以下情况下，这很有用：
- 当资源有硬限制时；
- 超过使用率阈值时，性能会下降。
监视对于所有资源都是必不可少的，即使是那些由服务很好管理的资源也是如此。在计划资源和功能时，这些指标至关重要。
发出的流量状态
建议在仪表板上添加指标或指标标签，这些指标或指标标签将允许您按状态代码中断发出的流量（如果您的服务用于SLI的指标不包含此信息）。这是一些准则。
- 跟踪所有HTTP流量的响应代码，即使那些由于可能的不正确的客户端行为而并非发出警报的原因的响应代码。
- 如果您要对用户应用时间限制或配额限制，请跟踪由于配额不足而被拒绝的请求数。
此数据图可帮助您确定生产变更期间错误率何时显着变化。
实施目标指标
每个指标都应达到目的。不要仅仅因为易于生成多个指标就被引诱。相反，请考虑如何使用它们。度量体系结构（或缺乏度量体系结构）具有影响。理想情况下，仅当系统中出现问题时，用于警报的度量值才会突然更改，并且在正常操作期间它们保持不变。另一方面，这些要求不是对调试指标施加的-它们应该给出警报触发时会发生什么的想法。良好的调试指标将表明系统中潜在的问题部分。撰写事后评估时，请考虑哪些其他指标可以使您更快地诊断问题。
测试警报逻辑
在理想情况下，监视和警报代码应遵循与开发代码相同的测试标准。当前没有允许您实现这种概念的被广泛接受的系统。最早的标志之一是为Prometheus新添加的规则单元测试功能。
在Google，我们使用特定于域的语言来测试我们的监视和警报系统，该语言允许我们创建综合时间序列。然后我们要么检查派生的时间序列中的值，要么我们弄清楚是否已触发特定警报并具有所需标签。
监视和发出警报通常是一个多步骤的过程，因此需要多个系列的单元测试。
尽管该领域仍在很大程度上落后，但是如果您希望在某个时候实施监视测试，我们建议采用三层方法，如图1所示。4.1。
- 二进制文件。确保在某些情况下导出的度量变量会按预期更改值。
- 监控基础架构。确保遵守规则，并且特定条件是预期的警报。
- 警报管理员。验证是否基于标签值将生成的警报路由到预定义的目的地。
如果无法使用综合工具测试监视系统，或者某个步骤根本无法测试，请考虑创建一个生产系统，该系统可以导出请求和错误等已知指标。您可以使用此系统检查时间序列和警报。警报规则设置好几个月或几年后可能不会触发，并且您需要确保当指标超过特定阈值时，警报仍然有意义并传递给预期的工程师。
章节总结
由于SR工程师必须对生产系统的可靠性负责，因此经常需要这些专家来深入了解监视系统及其功能，并与之密切交互。没有这些数据，SRE可能不知道在紧急情况下应该去哪里看以及如何识别异常的系统行为或如何找到所需的信息。
我们希望通过从我们的角度指出监视系统的有用功能并证明我们的选择合理性，可以帮助您评估监视系统如何满足您的需求。此外，我们将帮助您探索一些可以使用的其他功能，并查看可能要进行的更改。您很可能会发现将度量标准来源和日志合并到监视策略中很有用。指标和日志的正确组合在很大程度上取决于上下文。
确保收集用于特定目的的指标。这些目标包括改善带宽调度，调试或报告出现的问题。
进行监视时，它应该是直观且有用的。为此，我们建议测试其设置。一个好的监控系统可以带来好处。全面规划哪些解决方案可以最好地满足您的特定需求，以及对监视系统进行不断的迭代改进，这将是一项回报。
»可以在上找到关于这本书的更多细节出版社的网站
»目录表
»摘录
对于居住者对优惠券的优惠25％ -谷歌
在支付书的纸质版本，电子书发送到电子邮件。