作者：（美）Nat Welch（纳特·韦尔奇）
出版社：电子工业出版社有限公司
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
SRE生存指南：系统中断响应与正常运行时间最大化试读：
前言
总会在某个时候，软件开发人员所开发的站点会遭遇噩梦般的无法访问的故障——客户说他们已经连续几个小时无法访问你的网站了；当你在睡觉时，没有顾客能够购买网站上正在销售的T恤；或者在一年中最重要的销售日里，所有服务器都因承受不了高负载而崩溃了。
这本书适合谁
本书面向希望提高公司软件可靠性的软件开发人员和运维人员。本书将向你介绍一个致力于提高软件可靠性的基本框架，并使你深入了解站点可靠性工程这个领域。对于已经经历过重大系统服务中断的工程师和开发人员来说，这是你希望拥有的书。对于那些幸运地没有经历过服务中断噩梦的工程师和开发人员，现在就买这本书吧！
这本书涵盖了哪些内容
第1章 简介，探讨了SRE领域相对较新的发展状况，并概述了用于本书的可供上手实践的框架。
第2章 监控，讨论了在监控时使用的工具和方法。在本章之后，一个很好的实验就是设置对服务的监控，即使它们只是为测试而编写的虚假服务，你也应该去监控它们随着时间是否有所变化。
第3章 事故响应，解释了该如何应对中断，并让团队为最坏的情况做好准备。本章还专注于围绕团队协作建立即时响应与轮换的最佳实践系统，以及构建流程以尽量减轻由生产事故造成的压力。
第4章 事后回顾，让你能为自己、你的团队和你的组织撰写事后回顾报告，以促进事后回顾。本章还讨论了要收集的数据，以及如何借助通信跟踪未来的工作。
第5章 测试和发布，回顾了有关测试和发布的常见实践方案。
第6章 容量规划，介绍了一些有关预算的基础知识，并讨论了如何为基础架构的扩容制订计划。
第7章 构建工具，讨论了如何从提高响应力的角度来编写软件，还探讨了如何发现新项目，如何定义这些项目及如何规划它们。然后，讨论了如何实施这些项目并进行软件的长期维护，以及如何反思自己所做的工作。
第8章 用户体验，概述了有关用户体验和用户测试的基础知识，并讨论了安全性和性能预算问题。
第9章 网络基础，帮助你深入了解网络基础知识。
第10章 Linux和云基础，介绍了Linux和常见云服务的基础知识。
本书配套资源
● 本书中所有用Go语言编写的代码都基于Go 1.10版本。读者可以到其官网获取最新的版本。
● 本书中所有用Ruby语言编写的代码都基于Ruby 2.5版本。读者可以到其官网获取最新的版本。
本书使用的约定
本书中使用了一些文本约定。
代码块示例如下。
当希望读者注意代码块中的特定部分时，相关的行或项目将以粗体显示，示例如下。
粗体：表示第一次出现的新术语、重要单词。例如，会出现如下所示的文本。
服务水平指标 Service Level Indicator（SLI）可能是业务最重要的指标。这种图标表示警告或重要说明。这种图标表示提示和技巧。1 简介
随着互联网的发展，人们已经习惯于从各种设备中随时获取内容。这意味着产品品牌的声誉已经慢慢地与产品的响应性和可靠性联系起来。人们选择谷歌进行搜索，因为它总是快速返回有用的结果；人们在Twitter上分享内容，因为他们的消息会被粉丝实时看到；如果无法在不同的网络速度下提供一致的体验，Netflix的精彩内容将毫无吸引力。这种可靠性对企业来说越来越重要，并逐渐形成了一个专注于软件可靠性的研究方向：站点可靠性工程。本章将介绍该领域，并告诉你将从本书中学到什么，以帮助你编写软件来驾驭不断变化的互联网环境。
在介绍SRE领域和它的作用之前，先来做一个思想实验。想象一下，一大清早，你就从朋友的短信铃声中醒来，信息中包含一个空白网页的屏幕截图，信息的标题是：“我无法加载你的网站。”
如果你的个人网站确实宕机了，也许你会回复他“我吃完早餐再看看”，或者“哦，是的，我正在检查原因”。但如果它是你公司的网站，或者是刚刚发送给15个可能的雇主的简历页面，那么一连串的咒骂和难以理解的表情符号可能会从你的口中和短信息中爆发出来。这是因为，对于许多企业来说，网站已经成为潜在商机的主要来源：对于一些公司来说，如Facebook、Amazon或iFixIT，整个业务都是基于一个网站的；对于其他企业来说，如饭店、广告代理商等，网站可以让对该企业感兴趣的人了解更多信息。网站往往是营销流程的一部分，可以帮助公司发展。
如果你负责修复网站，那么可能无法完全避免在发现网站瘫痪时肾上腺素飙升的情况。但是，我们可以设法建立一个框架来降低这一类事情的发生频率。例如，可以建立一个能从容应对宕机的机制，并从“天啊，一切都‘着火’了，我该怎么办？！”过渡到“哦，嘿，有一个页面没有加载，让我们看看这一天究竟可以有多艰难。”
本章将对全书的内容和SRE领域进行介绍，因此接下来将介绍以下几个主题。
● SRE简史。
● SRE是什么。
● 描述全书大致内容，为SRE提供一个粗略的框架。SRE简史
SRE是一个相对较新的领域，它来源于很多现有的概念，但又稍微与之不同。1958年，术语IT（Information Technology，信息技术）首次出现在《哈佛商业评论》中，并最终被定义为一项用于收集、存储和分发数据和信息的技术。那时，计算机正在向集成电路发展，但其尺寸仍然有一个房间那么大，并且需要一群人进行维护和编程。随着计算机尺寸越来越小，这些团队开始维护多台计算机。随着时间的推移，一些人开始专注于对计算机进行编程，而其他人则专注于让它们保持正常运行。有专门的团队负责计算机的维护工作，而程序员和用户则通过“哑终端”连接到计算机对其进行使用。最终，这些维护人员既要维护个人使用的计算机，又要维护提供服务的计算机集群。用户在本地计算机上使用文字处理程序，然后将文件上传到远程计算机。那些维护远程机器的人被称为系统工程师、系统管理员或系统操作员。
随着计算机的体积变得越来越小，并且越来越商品化，程序员开始花更多的时间与基础设施进行交互，并将软件和基础设施配置得很好。另一方面，系统管理员正在编写越来越复杂的代码来维护基础架构。这些团队所做的工作越接近，就越有可能一起合作。在较小的团队中，人们开始同时关注基础设施代码和业务代码。而在大型组织中，往往会组建专注于开发或维护一些工具的团队来可靠地管理基础设施，以便产品团队可以快速、轻松地管理所需的基础设施。这些联合团队通常被描述为SRE或DevOps（Developer and Operations，开发人员和运营团队）。
谷歌的Benjamin Treynor Sloss（通常被称为Treynor）曾说“当要求软件工程师规划一个运维团队时，SRE就诞生了。”（引用自《SRE：Google 运维解密》）他经常被提及的观点是，运维工作现在只是软件工程的一个方面。鉴于谷歌在可靠性方面取得的成功，这个观点已经在许多公司中流行起来。
SRE仍然是一个新兴的领域，与DevOps一样，它经常被用来描述包含多种工作的角色。有些公司将SRE的头衔赋予某个职位，但它更接近于传统的系统管理员角色。在申请一份类似的工作之前，你可以使用这本书的框架来评估它。不过，这本书的目的是向你介绍SRE的思维模式，并帮助你把它推广到一个组织中，而不用考虑你过去的技术背景。SRE是什么
SRE是一个令人兴奋的领域。如前所述，它从一系列角色演变而来，且因为它是一个相对较新的领域，其定义正在逐步演进。SRE是许多过去概念的扩展和演变，因此，与SRE相关的概念也适用于许多角色，这包括但不限于后端工程师、DevOps工程师、系统工程师、系统管理员、运维人员等。根据公司的不同，这些角色可能涉及非常相似或非常不同的职责。关键是，无论你的职位是什么，都可以将SRE原则应用于你的角色。
为了定义这个领域，我们可以从它的全称“Site Reliability Engineering”中学到很多东西。
● Site：一个网站。
● Reliability：被定义为“值得信赖的质量或一贯可靠的质量”（来自《牛津生活词典》）。
● Engineering：被定义为“熟练地运用技巧以达到某种目的的行动”（来自《牛津生活词典》）。
合并这3个定义，可以得到一个如下的定义：一个专注于熟练地维护一个网站以使其持续可靠的领域。虽然这个定义有进一步优化的空间，但目前它足以满足我们的需要了。如果你在网站开发和软件工程领域工作，或者认识从事这些工作的人，你去问他们什么是SRE，他们可能会问你，“这不就像某某吗？”对于有这种背景的人来说，某某可能是DevOps、运维、平台工程、基础设施工程、24/7工程、系统管理，等等。
这种答案的不确定性是本书遇到的第一个问题：每个组织都是不同的。SRE的主要目标是让网站按照之前的定义持续地运行，这很困难。因为它依赖于组织和该组织周围的业务，以及网站（或产品）的要求。本书的主要目标之一是提供一个可以应用的框架，即使你不属于具有上述任何一个角色的组织。如果你是自由职业者，这个框架应该是有效的，如果你受雇于一些大型的跨国公司，或者任何介于两者之间的机构，那么这个框架也应该是有效的。
作为一名SRE工程师，我在2016年效力于Hillary for America。它是一个致力于帮助希拉里·克林顿成为美国总统的主要组织（但肯定不是唯一的）。最终我们没有成功，虽然这个例子使这本书显得有些过时了，但我发现它是我所工作过的网站中对各部分关注点的分离做得最好的。该组织非常关注一个目标（选举希拉里·克林顿为总统），所以它列出了一系列非常明确的目标，这让我的工作轻松很多。
技术团队负责独立完成竞选活动的每个部分，包括移动应用程序、不同的网站、数据管道和大型数据库。但是，简单起见，并为了解释我所说的关注点分离的含义，下面就以我们所构建和维护的3个独立的网站作为示例。
● 希拉里·克林顿的竞选主页。
● 竞选活动的捐赠页面。
● 竞选活动的选民登记页面。图1：Hillary for America网站不同部分的截图注：上图由Hillary for America的设计团队提供。从左到右依次是主页标题、内华达州页面、希拉里政策页面、西班牙语主页、竞选博客和捐赠页面。
主页是一个普通的登录页面。在北美洲的人们（我们的目标受众主要居住在美国）入睡前，必须确保它可以被访问。然而很少有人主动访问，除非被动跳转到这里。
访问希拉里·克林顿的竞选主页的主要原因是被动跳转到这里，而不是因为它像Twitter或Reddit那样，是人们日常浏览的一部分。在集会、电台或支持希拉里·克林顿的电视上发言的代言人经常会说“现在，去希拉里·克林顿网站报名”或“希拉里·克林顿网站有更多关于这个话题的政策细节”。虽然由于这种可预测的访问高峰导致网站宕机5分钟并无大碍，但是像许多媒体组织一样，我们无法预知何时会出现访问高峰。
捐赠页面需要一直打开着。根据产品团队和高层领导的指示，捐赠页面的可用性是第一要务。如果人们不能捐钱，那么就可能无法支付竞选活动参与人员的工资或让候选人参加演讲。捐赠页面并不是整个竞选活动中唯一的赚钱途径，但它是一个重要的收入来源。
选民登记页面只需要在选举即将到来时完全可用即可。这是因为这一页面是为了指引打算投票给希拉里·克林顿的人找到最近的投票地点而设的。虽然在大部分竞选活动期间都需要提供捐赠页面（从2015年5月到2016年11月），但选民登记页面实际上只需要在初选之前（即2016年9月至11月）提供即可。如果我们可以更早地建好选民登记页面，那么这个页面在初选前几天也能派上用场，但这只适用于提前几天投票的州。初选是大选的前兆，从2月到6月举行，不同的州在不同的日子进行投票。
这里的关键点是，不同的站点和功能有不同的要求和对可靠性的不同定义。没有什么东西是完美的，在互联网上也没有网站能达到100%正常运行，因为不好的事情总会发生。因此，我们所能做的就是尽可能找出可能发生的故障，并以有用的方式优化产品使其具有抗灾性。SRE不仅仅是对系统的分析，它还关乎如何对系统展开架构设计与构建，从而满足产品的需求。互联网上的软件永远做不到完全可靠，这里有两个原因。第一个原因是，互联网是一个分布式系统，各部分经常出现故障，这会影响服务的可用性。第二个原因是软件是人编写的，所以Bug不可避免，而Bug会导致系统宕机。
通常，从事SRE工作的人会考虑软件及其基础设施的可靠性需求，然后制订方案使基础设施满足这些需求。实现这一目标的步骤通常有：弄清楚现有基础设施是否满足这些需求，与团队（或编写软件的人员）协作，评估外部工具，或者仅仅设计和编写自己需要的东西。
正如本章开头提到的，SRE角色可以是多样化的。一家世界500强公司与一家20人的电子游戏公司对SRE职位的要求会有很大不同。在美国的一家银行里，和在世界上另一个国家的银行里，SRE的角色也可能是不同的。这是因为组织方式是不同的。对于较小的组织，从事SRE工作的人可以处理组织中与基础设施和可靠性相关的所有事情。然而，较大的组织可能有多个SRE工程师团队和许多不同的开发团队合作。对于两家不同的银行来说，由于每家银行的需求不同，那么，SRE角色的职责也可能不同。一家本地银行可能只需要一个人来提高银行员工所使用的工具的可靠性即可，而伦敦一家大得多的银行可能需要一些人来确保银行系统能够以非常高的速度与伦敦证券交易所进行交易，或者能够支持数百万个独立的客户。
本书将为任何有兴趣成为SRE工程师的人提供一个SRE知识结构。目标是向你赋能，不管你的背景或现状如何。它不会是万灵药，但将提供一个知识库和框架，帮助你的网站更可靠，并推动你的职业生涯向前发展。关于这本书
作为一名SRE工程师，我在谷歌工作了4年，从此开始专注于SRE这个方向，而不再是原来的全栈工程师。谷歌有很多内部培训课程供我学习，当我离开谷歌时，感觉很难继续维持学习状态。我很快发现，与其他规模小得多的组织所需的SRE相比，谷歌的SRE简直就是一头巨兽。于是我决定为有兴趣开始SRE之旅或将其应用于比谷歌小得多的组织的人写这本书。
为此，本书分为两部分。前8章介绍了可靠性的层次结构。这种层次结构最初是由美国数字服务公司的Mikey Dickerson设计的，因此，也叫Mikey金字塔。层次结构是为了说明，当尝试提高系统可靠性时需要按部就班，在到达更高级别之前满足每个低级别的要求。
图2对Mikey Dickerson原始的金字塔的版本做了略微修改（本书后面仍将其简称为Mikey金字塔）。我已将其更新，目前它包含沟通的各个方面。图2：Mikey金字塔注：这个七层金字塔围绕着沟通设计。每一层都建立在前一层的基础之上。它被沟通所包围，因为每一层都需要沟通才能成功。
让我们预览一下后面的每一章将会涉及的Mikey金字塔的层次。
● 第2章 监控：第一层是监控，它确保你洞察系统，跟踪系统的健康状态、可用性，以及系统内部发生的事情。监控不仅仅是工具，因为它也需要沟通。监控是SRE和运维之间的一个非常有争议的部分，因为它可以是非常有用的或非常无意义的，而这取决于具体的实现方式。制定出要监控什么、如何监控、在哪里存储监控数据、谁可以访问历史监控数据，以及如何查看数据，这些通常都需要时间。团队中的许多人会根据过去的经验对这些方面提出意见。有些工程师有糟糕的经历，他们不会认为监控是值得投资的，而有些人则会对某些特定的工具抱有偏执的热情，另外一些人可能会忽视你的意见。本章将帮助你应对所有这些不同的观点，找到并创建最适合你的项目和团队的实施方案。
● 第3章 事故响应：第二层是事故响应。如果有什么东西出了故障，该如何提醒大家并做出回应？工具可以帮助解决这个问题，因为它可以定义提醒人类的规则。而大多数的事故响应都是关于定义处理策略和提供培训的，以便人们在收到警报时知道该怎么做。如果团队成员在Slack中看到自动推送的消息，他们应该怎么做？如果他们接到电话，需要多快回复？如果员工因处理服务中断而需要在星期六工作，他们是否会获得额外报酬？这些都是将会在什么是事故响应这一部分中提出的问题。除此之外，建立随叫随到的轮换机制与团队合作的最佳实践，以及建立必要的基础设施以尽可能地降低事故带来的压力等方面也将被涵盖。
● 第4章 事后回顾：第三层是事后回顾。一旦发生服务中断，那么如何确保问题不会再次发生？你有关于事故的回顾会议吗？是否需要文档记录？在本章中，将考虑如何讨论已发生的事故，并使这种讨论充满乐趣。事后记录是记录事故如何发生、团队如何修复，以及团队如何努力防止未来发生类似事故的行为。为了让大家团结协作，我们希望建立一种无指责、透明的事后文化。个人不应该害怕事故，而是要确信如果事故发生，团队将会响应和改进系统，而不是关注发生事故带来的耻辱和愤怒。事故是我们可以从中学习的东西，而不是让人害怕和羞耻的事情！
● 第5章 测试和发布：第四层是测试和发布软件。在本章中，将会讨论可用于测试和发布软件的工具和策略。这个层级是Mikey金字塔中第一个专注于预防而不是事后处理的层级。预防是指尝试限制发生的事故数量，并确保在发布新代码时基础架构和服务能够保持稳定。本章将讨论现有的不同类型的测试，并让你和你的团队学会如何使用它们。除此之外，本章还将探索如何发布软件、何时使用持续部署等方法，以及可以使用的一些工具。
● 第6章 容量规划：第五层是容量规划。第5章主要关注当前的事，而本章主要是关于预测未来和发现系统极限的。容量规划也是为了确保系统可以随着时间的推移得到完善和增强。一旦去监控系统并使它能够可靠运行，你就可以开始考虑如何随着时间的推移去扩展它，以及如何查找和预测性能瓶颈和资源限制了。在本章中，将会讨论如何规划长期扩展、制定预算、与外部团队就未来进行沟通，以及在服务缩减和增长时要记住的事项。
● 第7章 构建工具：第六层是开发新工具和服务。SRE不仅涉及运营，还涉及软件开发。我们希望SRE工程师将花费大约一半的时间来开发新的工具和服务。这些工具中的一部分将用于自动化一些手工任务，而其他工具将用于改进Mikey金字塔的其余部分，例如用于自动负载测试或用于提高性能的服务。在本章中，将会讨论如何发掘这些项目并定义它们，如何规划及构建它们。还将讨论如何向你的同事介绍这些实用的工具。
● 第8章 用户体验：最后一层是用户体验，即确保用户获得良好的体验。本章将讨论如何度量绩效，如何与用户研究人员合作，以及确保良好的用户体验对团队意味着什么。还将讨论工具和流程如何导致服务中断。我们的目标是确保无论什么样的工具，人们都喜欢使用它，了解如何使用它，并且不能轻易地让它产生不好的影响。
有多年工作经验的谷歌SRE Nori Heikkinen补充说，“层次结构不包括预防，一部分原因是100%的正常运行时间是不可能的，另一部分原因是层次结构中最低的3个需求必须在组织内解决，然后才能被预防与验证。”
本书的最后两章将介绍常见的有用的主题。
● 第9章 网络基础：包括一系列关于网络的工具和重要的概念。这里会讨论网络数据包、DNS（Domain Name System，域名系统）、UDP（User Datagram Protocol，用户数据协议）和TCP（Transmission Control Protocal，传输控制协议），以及许多其他网络的术语。在本章之后，你应该感觉自己了解了网络的基础知识，并具备研究更高级主题的能力。
● 第10章 Linux和云基础：这是关于Linux和云的工具和重要概念的部分。这里将介绍Linux内核、公有云的基本知识，以及其他主题。在本章之后，你应该能够了解Linux和大多数公有云产品的基础知识。之后，你也就不会对研究特定云和更高级的Linux主题感到力不从心了。以SRE作为新项目的框架
使用本书的一种方法是把本书所述作为新项目的一个框架。由于每个章节都是关于Mikey金字塔层次结构的不同级别的，因此你可以通过本书来确定项目在层次结构中的对应位置。如果它是一个新项目，那么通常将位于Mikey金字塔的底部，没有或很少实施监控。
在每个级别里，如果团队中有其他人，那么你应该开始展开访谈以找出团队已经有什么，以及它是否满足团队的需求。每一章都将为这样的讨论提供一个粗略的标题，但请记住，每个团队和项目都是独一无二的。如果你是唯一考虑可靠性和基础设施的人，那么你最终可能会花费大量时间提出解决方案并帮助项目朝那个方向推进。请记住，重点是提高服务的可靠性，帮助业务实现，并改善用户的服务体验。
你可能会发现每一件事情都需要花费精力。强烈建议你在开始之前把所有问题都先记下来。凡事多记录总会有好处的。冲劲满满是让人欣赏的，但它也可能导致你忽略一些需求或花费太多时间在一个不适合你的业务的解决方案上。例如，将系统与你无法承受的监控服务集成，或者当你刚刚使用一小部分开源软件时，就构建一个分布式作业调度程序。
因此，在加入新项目或评估新服务时，请遵循下面的一系列步骤。
● 弄清楚团队结构。团队里谁负责什么？谁说了算？
● 查找团队为其服务或项目编写的任何文档。
● 让某人绘制出系统架构图。让他们向你展示什么连接到哪个服务、什么依赖于这个项目、数据如何流经服务，以及项目如何部署。图3：系统架构图示例注：这是一个非常简单的图，有人可能会在白板上绘制。大多数公司将拥有比这更复杂或更详细的东西，但这是通常需要的详细程度。带有名称和箭头的方框显示了通信的双方。图4：系统架构图示例——经典的静态网站生成器模型注：管理服务创建或修改内容并将更新通知写入队列。工作人员从队列中读取数据，对数据进行处理，并将其上传到静态对象存储库（在本例中为供应商2）。然后，放入某种CDN（Content Distribution Network，内容分发网络）或服务系统，在这种情况下，供应商1在供应商2前面。表1：项目人员简介示例表注：有了这个表格，我们对团队结构就有了一个基本的参考。如果需要知道与谁谈论移动应用程序，可以查看这个表格，明确是应该与Kareem还是经理Melissa交谈。
现在已经知道了项目或服务的上下文，下面让我们开始研究本书的每一章并提出以下问题。
● 服务有监控机制吗？
● 团队有事故响应的计划吗？
● 团队有事后回顾报告吗？它们存放在哪里？
● 服务是怎么被测试的？项目有发布计划吗？
● 有人曾经做过扩展计划吗？
● 能使用什么工具来改进服务？
● 当前的可靠性水平是否提供了令人满意的用户体验？这里要注意的诀窍是，无论是运行了很多年的软件，还是刚刚开发出来的软件，这些问题都是适用的。
你正在研究的服务可能包含许多软件，例如面向服务的体系结构（Service-Oriented Architecture，简称SOA）或一个大型单体项目。如果你正在处理具有许多服务的项目，那么就一次研究一个服务。这样做的缺点是，如果想构建一个适合正在与之交互的所有服务的框架，那么只有在完成一系列的研究工作之后，你才能知道怎样才能最好地解决它们的问题并满足需要。好处是不需要一开始就并行地往不同的方向投入精力，并且能够专注于一个特定服务的问题。
时间和精力都是有限的资源，因此，你总是需要与更多的人共同协作，所以一定要慢慢来。走得慢点意味着事情不那么容易会被遗漏。你也不希望每个服务的基础还没来得及打好就崩塌了。小结
好了，到这里就介绍完了！本章在一个很高的层次上探讨了SRE是什么，讨论了不同的角色倾向于关注的不同问题。还讨论了本书的结构，以及如何将该结构与一个软件项目相对应。
在下一章中，我们将探索监控领域。监控是研究一个系统运作的基础。你可以通过监控来记录系统历史数据，以及通过分析收集到的数据来探索系统的行为。到第2章结束时，你将了解程序检测、数据聚合、数据存储及数据展现的基础知识。2 监控《牛津词典》对监控的定义是“观察和检查一段时间内（某事物）的进展或质量；持续进行系统审查。”该定义指出了两个关键点：首先，需要确定质量标准是什么，并确保系统持续逼近或保持在质量标准极限范围内。其次，需要系统地关注这项工作——而不应该只是随机地查看一下系统；相反，你的做法应该是前后一致的。举个例子，系统的度量意味着，当你去看牙医时，往往需要每6个月就去复诊一次；或者在购买保险时，保险公司往往要求你找一位专属的主治医生提供系统的体检或诊治报告。
在本章中，我们将重点介绍监控现代Web服务的工具和方法。本章将包括关于收集什么数据、如何收集这些数据、如何存储这些数据，以及如何为开发人员和其他深知这些数据的价值的人展现这些数据。还将讨论关于监控这种沟通方式——为什么监控是必不可少的、如何让公司中的每个人都乐于投入监控。为什么要监控
每个人都告诉你要定期去看医生，但为什么要这样做？有什么好处？父母会说你应该去看医生，这会让你重视所忽略的一些身体信号，如胆固醇水平、血压值和皮肤癌病变。我也喜欢利用与医生交谈的时间来思考和谈论我所注意到的身体变化，例如，我经常感到胃部不适。
这个例子可以很好地类比软件中通常需要的两种不同类型的监控。第一种是指标，第二种是日志。指标，在这个例子里面，是度量数字。在传统意义上，指标侧重于性能数字，例如，磁盘空间使用率、接收的数据包数量、CPU负载。现在，它们可以用来表示任何可以定义为数值的东西，可以是来自系统中的任何软件。日志用来记录事故，通常也包含一些数字与数据，但往往结构松散。有些日志是完整的JSON数据块，而有些只是人工格式的文本字符串，日志也可以是介于两者之间的东西。
回到刚才的例子，假设我去看医生，我的血压值为120/70mmHg，胆固醇值为190 mg/dL，我的背部还有一个新的痣，而胃部一直感到不适。在这种情况下，指标是我的血压值和胆固醇值。每次看病时我的医生都会收集它们，并且记录在案。这些指标一般具有针对成年人的建议安全范围值，但与本章主题关系不大。在讨论下一章内容时，这些范围值才会有用。而痣和胃的问题更接近于事故。
因此在这里稍微深入讨论一下，对痣的测量能拿到相关数据，医生根据其大小、位置和形成时间做出医院是否应该进行活组织检查的决定。我的医生没有常规参考数据，但他有一次性测量数据。对于胃的问题，医生有一些统计资料来自我的回忆，例如：我吃过什么东西，疼痛时间大约持续多长、有多强烈、有多频繁等。图1：带有监测标签的人像注：每个标签都是可能收集到的关于一个人身体的指标示例。
对于指标，医生会记录它们，如果它们不正常或超出了安全范围，医生可能会建议我改变生活方式。对于日志，医生可能会先收集更多数据，例如将痣的样本送到实验室，或要求我持续记录所吃的东西。
尽管我们希望应用程序能够自己恪守职责，但它们毕竟不是人类。因此，我们需要有针对性地度量应用程序。对于Web应用程序，最常见的指标是错误数、请求数和请求持续时间。最常见的日志是错误堆栈跟踪。如果想要记住这3个指标，可以将它们简称为ERD（Error Counts，Request Counts，Request Duration）或RED。有些人也称它们为REL——请求（Requests）、错误（Errors）、延迟（Latency）。
那么，为什么往往从这些指标开始呢？我们可以在每次发生错误时增加一个计数器，并将该错误写入带有时间戳的日志。计数器是最基本的监控形式之一。我们只计算事情发生的次数。某些服务允许你按计数器增量存储元数据，并将日志绑定到计数器上，但通常只需使用相同的时间戳写日志和计数器增量即可。此计数器很有用，因为你需要知道系统何时向用户发送了错误并查看日志以评估该错误的性质。你递增计数器，以便可以计算请求错误率，以及快速查看错误的长期增长趋势。
总请求数很有用，因为据此可以知道应用程序的使用频率。这里以基于HTTP 1.1 的Web应用程序为例，总请求数是对服务器正在执行的工作量的准确反映。如果服务器是流服务器，那么团队通常会计算字节数或数据包而不是请求数，这样他们可以查看使用情况，因为在这种情况下，一个请求可能涉及多个服务器。有关HTTP 1.1如何工作，以及它与其他HTTP版本的不同之处的更多信息，请参考第9章。
在这个Web应用程序中，请求持续时间只是单个HTTP请求的时长。而我们度量服务器处理请求的时间，是指从收到完整请求到发送完整响应的时间。请求持续时间有多方面的用途。首先，可以使用它来确定某些类型的请求是否比其他请求花费的时间更长。如果不仅需要记录每个请求的持续时间，而且还记录URL命中率、请求方法（GET、POST、HEAD等），以及返回的状态代码，那么你可以更深入地探究这些指标。可以看到，平均而言，返回代码为404的所有请求所花费的时间比返回代码为200的请求长1秒。其次，可以使用此方法查看类似请求随时间而变化的情况。例如，可以将11月份对https://example.com/的请求与12月份的请求情况进行对比。图2：11月份和12月份服务总请求数的图表注：图中的曲线显示，12月份大多数日子的请求量略高于11月份的请求量。但有两处例外，一是这两个月月初请求量的大幅度飙升时间不太一致，二是12月月底附近的请求量略有下滑。
这里我们主要讨论了监控的用处，以及它未必是很重要的。下面我来问你一些问题：怎么知道服务处于正常状态？怎么知道它不正常？你如何定义它是正常的？这是我们试图通过监控解决的问题。监控很重要，因为它提供了一个数据驱动的应用程序视图，并向我们证明它正在工作。我们不必坐在那里，不需要每一分钟都检查应用程序。考虑到这一点，我认为最好还是动手操作一番。下面让我们尝试创建一个简单的应用程序，并通过监控对其进行检测。检测应用程序
首先，需要注意的是——有很多编程语言和监控系统。我们将在本章后面讨论各种监控系统，并且有各种语言和系统的库。所以，这里提供了特定语言和库的示例，但并不意味着你不能用你选择的语言和监控系统实现类似的功能。
对于第一个示例，我们将使用Ruby语言和StatsD监控系统。Ruby是一种流行的脚本语言，当我想快速构建一些东西时，往往会第一时间想到它。此外，一些非常大的网站也使用Ruby语言，包括GitHub、Spotify和Hulu。StatsD是Etsy的监控系统。它是开源的，并被包括Kickstarter和Hillary for America在内的许多公司使用。
我尽可能多地给这个简单的应用程序添加了注释。但是，如果你需要更多的文档，请查看本章后面的参考资料部分。
Sinatra是一个简单的Web框架。它基于Ruby语言创建了一种特定于域的语言来响应Web请求，如下所示。
通过运行gem install statsd-ruby可以安装最流行的Ruby StatsD库。require是Ruby语言的导入功能。
Logger是Ruby语言标准库的一部分，下面让我们以预定义的格式在控制台输出。
下面来配置StatsD库，以便在尝试向StatsD服务器发送请求时，将调试消息写入标准输出。这很适合调试，也适用于我们的示例应用程序，以便查看发生了什么。
接下来创建一个StatsD类的实例，与在本地计算机的端口9125上运行的StatsD服务器进行通信。
StatsD传统上是通过UDP而不是TCP运行的。请注意，因为StatsD在UDP上运行，所以对于测试我们的代码来说，StatsD服务不是必需的。UDP如果失败就不会再重试了，那么网络请求将进入无人监控的状态。当然如果它能正常运行的话会更好，即使没有设置服务器来接收数据，我们仍然知道发生了什么，因为我们将所有请求都记录到了标准输出里。我们将在第9章深入讨论UDP和TCP。
下面是Sinatra定义的DSL的一部分。它表示，如果HTTP服务器收到对GET方法的请求（这只是一个正常的页面加载），我们应该在块内运行代码。块是在do和end这两个关键字之间定义的。
下面的StatsD函数对传递给它的块的运行时长进行记录，当块完成时，就将该时间发送到StatsD。
下面的函数会将请求计数器递增1。
请注意，StatsD本身不支持标记，也不以任何方式描述此指标。StatsD的其他实现可以支持标记，但在默认情况下不支持。因此，这不会获得前面提到的任何有用的额外数据，如路径、方法或状态代码。
在Ruby中，块的最后一行是返回值，示例代码如下。
在这种情况下，"hello world"从定时块返回，然后由Sinatra块返回，再发送给用户，因为Sinatra认为返回的字符串是返回HTTP响应体中用户的内容。
如下是另一个Sinatra DSL（Domain-Specific Language，领域特定语言）。只要Sinatra与用户正在查找的URL不匹配，就会触发它。因此，如果他们访问此服务器之外的任何URL，此块就会运行。想了解所有类型的请求，因此在此增加了request.count；也记录了request.time，同时还在这里新增了request.error。
如果发现除not found之外的任何其他错误，则下面的块将会运行。除返回消息之外，这看起来与not_found块没什么区别，因为它们执行相同的操作，只是返回一个稍有不同的错误。
虽然这个例子有点简单，但你可能还是会觉得为应用程序中的每个路径都编写这样的代码是很烦人的。另外需要指出的是，此示例实现过于底层化。通常，人们希望使用一个免费提供这些指标的库，或者在用户和应用程序之间使用Nginx等服务来记录一些请求指标。但是，此代码示例的主要内容是对两个监视函数的调用，如下所示。
● increment
● time
有了这两个函数，可以做很多事情。例如，随着时间的推移，可以度量与依赖系统通信所需的时间；通过计数器的递增，可以记录任何想记录的东西，从接收的请求数到用户执行操作的次数。StatsD还支持以特定时间间隔来获取系统快照，这类似于定时操作，但没有时间单位。稍后我们将讨论你可能想要监控的其他事项，以及如何与你的团队讨论监控的重要事项。
下一个示例使用Prometheus监控库与Go语言编写。Prometheus是一个相对较新且越来越受欢迎的监控系统，由SoundCloud的人员编写。它与谷歌的内部监控系统Borgmon非常相似。StatsD是一种基于推送的监控系统，而Prometheus是一种基于拉式的系统。至于选择Go语言来编写这个示例的原因，是Go语言拥有编写良好的范例和优秀的工具，这使开发流程更容易完成。
与前面的示例一样，有关详细信息，请查看本章后面的参考资料部分，其中包含官方文档的链接。
Go语言文件始终以包声明开头。main是用于创建可执行文件的包，示例代码如下。
import是Go语言导入包的方式。log是Go语言标准库的一部分，它允许我们写出带有时间戳的消息。net/http也是Go语言标准库的一部分，它包含了用于构建HTTP服务器的功能。最后，time也是Go语言标准库的一部分，它包括处理时间的函数，我们可以使用它来确定运行某些东西需要多长时间。
接下来的两个库不是标准库的一部分。github.com/prometheus/client_golang/prometheus是构建Prometheus指标的第三方库。尽管它看起来像一个URL，但不要指望那里会有一个网页。Go语言以URL的形式结构化导入外部资源链接，其中路径的开头是域和源库的路径，然后紧接着的/是源库的目录。执行go get github.com/prometheus/client_golang/prometheus来安装并使用这个包。某些域（如gopkg.in）会发布元数据重定向到另一个源库。在安装程序包时，将获取go get工具以下载代码。
与StatsD不同，Prometheus在其运行的服务器上发布指标。promhttp是此导入中的第二个第三方库，其作用是使我们能够轻松地运行Prometheus endpoint。它也是Prometheus Go库的一部分。
Prometheus要求在写入指标之前声明指标。首先，定义将要递增的请求数。所有Prometheus指标都需要名称和描述，以使其更具可读性。这里还提供了一个可选列表，用于描述每个请求增量所必需的属性。
试读结束[说明：试读内容隐藏了图片]