SRE|当Google的核心准则遇到Xero的最佳实践

关于SRE，数人云之前给大家分享很多相关的文章，想必大家已经有了一定的了解，今天给大家带来的这篇文章，分别从Xero和Google的角度讨论一些工具和框架，以及SRE的一些准则。

Xero的SRE之路

作为一个SRE，作者主要关心的是如何保持应用平台的稳定，减少崩溃，然而这也是不能避免的，本文会通过Xero的SRE经验去讨论一些工具和框架。

任何故障的开始都是至关重要的，因此需要在发现故障的第一时间就提醒能解决问题的人。

大多数的生产问题，都是通过监控基础设施进行检测的，用于告警的通道工具已经随着时间的推移而发生了变化，但是基本的流程仍然大同小异，如下图所示：

自动告警Pipeline

自动化Pipeline可以确保工程师快速、正确、一致和可靠的进行工作，理想的情况下， 所有的告警都应该是自动化的，但有时我们会接触到一些没有被发现的问题，所以希望有一种方法可以允许其他团队报告保留自动告警Pipeline，因此决定将这些请求转换为自动告警，如下所示：

手动报警Pipeline

使用这种方法，自动和手动告警都以同样的方式送达工程师，但是每个告警都有什么呢？

剖析一个告警

• 出现了什么错误？问题的性质和严重性？
• 故障出现后，都有哪些地方收到了影响？
• 它怎么能固定下来呢？链接到Runbooks或者How-to文档。

尝试编写自动告警模板以满足这些需求，对于手工报告的问题，依赖于通过在线表单提供这些信息，希望填写表格的过程是速度且无痛的，所以只有第一个问题是强制性的：

• 能否概括一下这个问题，比如，到底出了什么问题？
• 哪个站点/URL有问题？可以帮助识别受影响的地方。
• 问题是否仅限于特定的地点，帮助我们隔离网络/CDN问题。
• 问题是什么时候开始的？帮助设置日志/度量搜索的时间尺度。
• 谁在关注这些问题？这样可以将它们包含在事件的Pipeline中

虽然这些信息不可能如监控系统所提供的那样具体明确，但它仍然可以减少SRE工程师所需要的调查工作。

On-call as code

我们使用第三方的呼叫管理系统，允许我们建立多个On-call团队，定义每个团队的轮换，并将每个团队连接到监控基础设施，告警是针对拥有受影响系统的团队的，但是SRE为每个团队提供了额外的层，如下所示：

告警升级

在20多个产品和服务的呼叫团队中，On-call管理配置已经演化为相当复杂的设置，随着越来越多的团队加入其中，我们的支持模式也在不断地发展，要手动设置所有的东西将是一项艰巨的任务，处于这个原因，我们创建了一个“On-call as code”系统，类似于Chef这样的基础设施代码框架。

On-call configuration pipeline

延伸阅读：

Chef 是一款自动化服务器配置管理工具，可以对所管理的对象实行自动化配置，如系统管理，安装软件等。Chef 由三大组件组成：Chef Server、Chef Workstation 和 Chef Node。

Chef Server 是核心服务器，维护了一套配置脚本（Cookbook），与每个被管节点（Chef Node）交互并给出配置指令。

Chef Workstation 提供了我们与 Chef Server 交互的接口：我们在 Workstation 上创建定义 Cookbook，并将 Cookbook 上传到 Chef Server 上以保证被管机器能从 Chef Server 上取得最新的配置指令。

Chef Node 是安装了 chef-client 并注册了的被管理节点，可以是物理机或者虚拟机或者其他对象。Chef Node 每次运行 chef-client 时都会从 Chef Server 端取得最新的配置指令（Cookbook）并按照指令配置自己。
一套 Chef 环境包含一个 Chef Server，至少一个 Chef Workstation，以及一到多个 Chef Node。

团队可以通过将更改合并到Git存储库来更新他们的调用配置，然后，CI/CD系统运行一个Rake任务，它通过调用管理系统来同步存储库，这种方法为我们提供了一系列的好处：

• 所有的配置更改都可以通过标准的Git工作流进行同行评审。

• CI服务器可以“Lint”每个配置更改，以验证它满足一些基本需求（例如，每个团队需要一个管理员）。

允许团队手动设置他们的调用轮换，因为On-call系统的Web界面提供了一种简单的方法，然而，团队调用设置的所有其他组件都由同步任务执行。

• 新团队不需要担心设置他们的告警端点或将他们的团队与SRE的时间表联系起来，同步任务从一个最小的配置文件自动地构建每个团队的调用配置，如果团队需要一个不寻常的调用设置，那他们就可以置顶额外的配置文件来这样做。

• 未来，可以很容易地改变所有团队的标准调用配置，例如更改每次升级之间的时间限制。

在这些倡议中，我们为管理良好的时间奠定了基础：

• 告警以相同的方式发出，无论它们是自动检测还是手动报告。

• 每个告警的内容都包含了足够的信息，让工程师开始计划响应。

• On-Call作为代码系统，确保所有的团队都能以一致的方式接受告警。

• 虽然工作流程、优先级和日常操作从SRE团队到另一个SRE团队之间都有细微的差别，但都与他们支持的服务有着基本的信任，并坚持相同的核心原则。

一般来说，SRE团队负责可用性、延迟性、性能、效率、变更管理、监控、紧急响应以及服务的容量规划。

我们已经为SRE团队与其环境交互（不仅仅是生产环境，还包括开发团队、测试团队、用户等等）制定了相关的规则和原则，这些规则和工作实践帮助我们保持对工程工作的关注，而不是运维工作。

Google SRE准则

确保持久专注于工程

Google在50%的时间内为SREs的运维工作设置上限，他们的剩余时间应该用在项目工作的编程技能上，在实践当中，这是通过监控SRE们所做的运维工作数量来完成的，并将多余的运维工作重新定向到产品开发团队：重新分配Bug将开发人员集成到On-Call pager roUNK中等等。

当运维负载下降到50%或更低时，重新向结束，这也提供了一个有效的反馈机制，引导开发人员构建不需要人工干预的系统，当整个组织——SRE和开发人员理解为什么这个机制存在时，这种方法很有效，并且支持没有溢出事件的目标，因为产品没有产生足够的运维负载来要求她。

当他们专注于运维工作时，在平均每8-12小时中，SRE应该最多接受两个事件，这个目标量给呼叫工程师足够的时间准确快速地处理事件，清理和恢复正常服务，然后进行事后剖析，如果有两个以上的事件经常发生在呼叫转移上，问题就无法彻底调查，工程师们也无法从这些事件中吸取教训，一种寻呼机疲劳的情况下也不会随着规模而提高，相反，如果每次转换时，调用的SRE始终接受不到一个事件，那么这就无异于在浪费时间。

对于所有重大事件，无论是否寻呼，都应该写死后的纪录，没有触发界面的后期纪录甚至更有价值，因为它们可能指出了明显的监控漏洞，这个调查应该确定发生的细节，找出事件的所有根源，并分配行动来纠正问题化或改进下次处理的方法，Google在一个免费的分析文化下运行，目标是揭露出错误并应用工程来修复这些错误，而不是去避免或尽量最小化它们。

追求最大的变化速度而不违反服务的SLO

产品开发和SRE团队可以通过消除各自目标中的结构性冲突来享受高效的工作关系，结构冲突是在创新和产品稳定性之间，正如前面所述，这种冲突往往是间接表达的，在SRE中，我们将这个冲突引入到前面，然后通过引入错误预算来解决它。

预算错误源于这样一种观察， 即100%是所有东的错误可靠性目标，一般来说，对于任何软件服务或系统100%可用和99.999%可用，有许多其他系统用户和服务之间的路径（他们的笔记本电脑，家里的WIFI，ISP，电网……），这些系统集体远远低于99.999%，因此，99.999……和100%的差异在于其他不可用性的丢失，而且用户无法从需要添加走货0.001%的可用性中获益。

如果100%是一个系统的错误可靠性目标，那么，系统的正确可靠性目标是什么？这实际上并不是一个技术问题——这是一个产品问题，应该考虑以下因素：

• 考虑到他们是如何使用产品的，用户满意的程度是多少?

• 对于那些对产品的可用性不满意的用户有什么选择?

• 用户在不同可用级别上使用该产品会发生什么情况?

业务或产品必须建立系统的可用性目标，一旦确定了目标，错误预算就是一个减去可用性的目标。一个99.99%可用服务是0.01的不可用，允许0.01的不可用性是服务的错误预算，我们可以把预算画在问么想要的任何东西上，只要不超支。

那么要如何花费这个错误预算呢？开发团队希望推出特性并吸引新用户，理想情况下，我们会把所有的错误预算都花在我们发布的新产品上，以快速启动它们，这个基本前提描述了整个错误预算模型，一旦SRE活动在这个框架中被概念化，通过注入阶段性的滚转和1%的实验等策略释放错误预算，可以优化更快的启动。

错误预算的使用解决了开发和SRE之间的结构冲突，SRE的目标实在是“0消耗”；相反，SRE和产品开发人员的目标是将错误预算花在获得最大特征速度上，这种改变造成了不同，宕机不再是“坏”的事情——它是创新过程中预期的一部分，而且发展和SRE团队都在管理，而不是一直忧心忡忡。

监控

监控是服务所有者跟踪系统的健康和可用性的主要手段之一，因此，应当深思熟虑地构建监控策略，一个典型的、常见的监控方法是观察特定的值或条件，然后在超过该值或条件时触发电子邮件告警，然而，这种类型的电子邮件告警并不是一个有效的解决方案；一个需要一个人阅读电子邮件并决定是否需要采取某种行动的系统从根本上是有缺陷的，监控不应该要求人对告警区域的任何部分进行解释，相反，应用应做口译，只有当它们需要采取行动时，才去通知SRE。

三种有效地监控输出：

• 告警：意味着SRE需要立即采取行动来应对正在发生或即将发生的事情，以改善这种情况。

• Tickets：表示SRE需要采取行动，但不是马上，系统不能自动处理这种情况，但如果一个人在几天内采取了动作，就不会造成事故。

• 日志记录：无需日日查看的信息，但它被记录为诊断错误或反刍的目的。

应急响应

可靠性是指故障时间（MTTF）和平均修复时间（MTTR）的函数，评估应急反应有效性地最相关的指标是反应小组能多快地将系统恢复到健康状态，即MTTR。
一个能够避免需要人工干预的紧急情况的系统比需要实际操作的系统有更高的可用性，当SRE有需求时，我们发现，在“剧本”中提前记录是最佳实践，在MTTR中产生大约3倍的改进，而不是“即兴发挥”的策略，谷歌SRE依赖于on -call playbooks，除了诸如“不幸之轮”这样的练习，还可以让工程师对on - call事件做出反应。

效率和性能

任何时候，有效利用资源都是非常重要的，由于SRE最终控制了供应，因此它也必须参与任何有关使用的工作，因为利用率是给定服务如何工作的一个函数，以及它是如何响应的。密切关注服务的供应策略，它的使用为服务的总成本提供了非常大的杠杆。

资源使用是需求（负载）、容量和应用效率的函数。SRE预测需求，提供能力，并可以修改软件，这三个因素是服务效率的很大一部分（尽管不是全部）。

随着负载的增加，应用系统会变得越来越慢，服务的减少等同于能力的丧失，在某一个时刻，当某个缓慢的系统停止服务，这相当于无限的慢。SRE提供以特性的响应速度满足容量目标，因此对服务的性能非常感兴趣，SRE和产品开发人员将（并且应该）监控和修改服务以提高其性能，从而增加容量和提高效率。

以上是小数今天给大家分享的文章，众所周知，SRE的理念最早出自Google，而数人云老王（王璞）曾供职于Google的广告部门，对于SRE有着深入的研究，在数人云的Meetup上就曾以SRE为题进行了多次分享，同时小数也给大家分享了多篇SRE相关的文章，有兴趣的可以点击查看：