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

宁波整形美容医院http://www.lyxcl.org/