| 2020-12-18
本文源自《SRE工作手册》英文版第三章，讲述的是家得宝（THD）公司在SRE转型中如何使用VALET。
VALET 是一个易记易用的模式语言，分别代表：
- Volume
- Availability
- Latency
- Error
- Ticket
内容简介：
一、家得宝运维工作的原始状态 二、SRE改进步骤
- 建立统一语言
- 自动数据收集
- 建设仪表盘
- 写入开发负责人的OKR
- 管理批处理任务的SLO
正文如下：
家得宝（THD）是世界上最大的家居装饰零售商，在北美拥有2200多家商店，每个商店都拥有 35,000 多种独特产品(并在线提供了超过 150 万种产品。在其基础架构中，托管着各种软件应用程序，这些软件应用程序支持近 40 万名员工，每年处理超过 15 亿笔客户交易。这些商店与全球供应链和一个电子商务网站紧密集成，每年访问量超过 20 亿。
在其软件服务架构向微服务的迁移的过程中，也完成了全栈所有权的“自由和责任文化”的增强。它让开发人员可以在其需要时按需推送代码上线，并让其共同负责服务的技术运营。
为了达成这种共有制的工作模式，运维团队和开发团队需要统一沟通语言，以促进责任制，并跨越复杂性。这种语言就是：服务水平目标(SLO)。相互依赖的服务之间需要了解以下信息（这里假设 A服务 依赖 B服务），负责A服务的团队会问：
- B服务有多可靠？它是为三个 9 ，三个半 9 或四个 9 而构建的？
- B服务有计划的停机时间吗？
- 对 B 服务的延迟上限，可以有什么样的预期？
- B 能处理 A 服务 发送的多少请求量吗？如何处理过载？B 服务是否已逐步达到其SLO？
如果每个服务都可以为这些问题提供透明且一致的答案，那么团队将对他们的依存关系有清晰的了解，从而可以更好地进行沟通，并提高团队之间的信任度和责任。
改进步骤如下：
一、原始的状态
家得宝原来的监控工具和仪表板数量很多，并且是分散在各处的。服务出现中断时，有时候根本找不到根源。通常，最开始会从用户接入服务处进行故障排除，然后进行反向跟踪，直到发现问题为止，这会浪费无数小时。如果某个服务做了计划内停机，其他相关服务很可能不知道，只会感到惊讶。如果团队的服务水平目标是99.9%，然而，他们并不知道他们所依赖的服务是否可以为他们提供更好的服务水平，比如（四个9）。
这些脱节导致了软件开发和运营团队之间的困惑、失望与对立。
二、建立通用语言
建立一个通用语言对于让各方意见统一至关重要。家得宝希望保持此框架尽可能简单，以帮助更快地统一传播。经过仔细研究，发现了一些模式。每个服务都可能监控它的"流量"，“等待时间”，“错误"和"利用率"这四个指标，但不幸的是，所有指标的整体监控都不一致，名称不同或数据不足。
另外，生产环境最接近面向客户的指标是“支持工单数”。家得宝衡量应用程序的可靠性的主要（也是唯一的）方法是跟踪内部支持部门收到的支持电话数量。
所以，将 SLO 总结为 VALET：
- Volume 容量（流量）
我的服务可以处理多少业务量？
- Availability 可用性
我需要时可以启动服务吗？
- Latency 延迟
使用该服务时，服务是否快速响应？
- Error 错误
使用该服务时是否抛出了错误？
- Ticket 故障单
服务是否需要人工干预才能完成我的请求？
三、自动VALET数据收集
家得宝将SLO正式纳入THD对开发经理的年度绩效评估中。虽然每周大约有50个服务定期按其SLO进行捕获和报告，但开始的管理方法太土，这些指标临时存储在电子表格中。
TPS报告
家得宝建立了一个框架来自动捕获已部署到云端环境的服务 VALET 数据，并称此框架为“TPS报告”，是家得宝用来进行容量和性能测试（每秒事务处理）的术语，很多管理者可能希望查看此数据。家得宝的网络服务前端生成的所有日志均被写入BigQuery中，以供TPS报告进行处理。最终，家得宝将其他各种监控系统的指标也纳入进来，例如 Stackdriver 的可用性探针。
TPS报告将这些数据转换为任何人都可以查询的每小时 VALET 指标。新创建的服务会自动注册到TPS报告中，因此可以立即查询。由于数据全部存储在BigQuery中，因此可以跨时间段有效地报告VALET指标。员工可以使用这些数据来构建各种自动报告和警报。最有趣的集成是一个聊天机器人，员工也可以直接在聊天平台中询问它，每个服务的VALET值是多少。例如，任何服务都可以显示最后一小时的VALET，VALET与前一周的对比，以及其它一些数据。
VALET服务
然后，家得宝又创建一个 VALET 应用程序，以存储和报告 SLO 数据。由于 SLO 可以最好地用作趋势工具，因此该服务每天、每周和每月对 SLO 进行跟踪。请注意，我 SLO 是一种趋势分析工具，可用于错误预算，但未直接连接到监控系统。相反，家得宝仍旧有各种不同的监控平台，每个监控平台都有自己的报警。这些监控系统每天汇总其 SLO ，并发布到 VALET 服务以进行趋势分析。这种设置的缺点是，监控系统中设置的警报阈值未与 SLO 集成在一起。但是，可以根据需要灵活地更改监控系统。
TPS 报告是第一个与 VALET 服务集成的系统，到目前为止，家得宝的 VALET 与其各种本地应用程序平台（在 VALET 中注册的服务的一半以上）集成。
VALET 仪表板
VALET 仪表板如上图所示，用于可视化和报告此数据，并且相对简单。它允许用户：
注册新服务。这通常意味着将服务分配给一个或多个URL，这些URL可能已经收集了VALET数据。
为五个 VALET 类别中的任何一个设定 SLO 目标。
在每个 VALET 类别下添加新的指标类型。例如，一项服务可以跟踪 P99 的延迟，而另一项服务可以跟踪 P90 （或两者）的延迟。后端处理系统可以跟踪每天的交易量（一天创建的购买订单），而客户服务前端可以跟踪每秒的高峰交易。
VALET 仪表板使用户可以立即报告许多服务的 SLO ，并以多种方式对数据进行切片和切块。例如，一个团队可以查看过去一周不满足 SLO 的所有服务的统计信息。寻求查看服务性能的团队可以查看所有服务及其所依赖服务的延迟。VALET 仪表板将数据存储在简单的Cloud SQL数据库中，开发人员使用流行的 BI 工具来构建报告。
这些报告成为开发人员采取新的最佳实践的基础：定期对其服务进行 SLO 审核(通常是每周或每月)。基于这些审查，开发人员可以创建操作项以将服务返回到其 SLO ，或者可以决定需要调整不切实际的 SLO。
四、将VALET应用于批处理应用
当围绕 SLO 开发可靠的报告时，家得宝还发现，只要对 VALET 稍作调整，就可以用在批处理应用程序上，如下所示:
**容量：**处理的记录量
**可用性：**在一定时间内完成工作的频率(以百分比为单位)
**延迟：**作业运行所需的时间
**错误：**无法处理的记录
**故障单：**操作员必须手动修复数据并重新处理作业的次数
五、下一个待解决的组织问题——如何与产品经理沟通SLO
尽管对技术人员来说， VALET 很直观，但是对于产品经理来说，这个概念并不是那么直观。如何以业务术语转换指标，并在产品和开发之间共享可见的目标(SLO！)可能是个挑战。一旦解决，这将减少在大公司中经常看到的对可靠性的错位期望。