自我疗伤的夏天今年夏天，我在云基础设施团队实习。该团队负责构建可扩展的基础设施，以支持Databricks的多云产品，同时使用Terraform和Kubernetes等云无关技术。我的主要精力是开发一种新的自动修复服务Healer，它可以自动修复我们的Kubernetes基础设施，以提高我们的服务可用性并减少呼叫负担。自动减少停机和停机时间Databricks的Cloud Infra团队负责所有Databricks的底层计算基础设施，跨云和区域管理数千个vm和数据库实例。作为分布式系统中的组件，这些云管理的资源可能会不时出现故障。随叫随到的工程师有时会执行重复的任务来修复这些预期的事件。当PagerDuty警报触发时，随叫随到的工程师通过遵循有文档记录的行动手册来手动解决问题。虽然理想情况下，我们希望找到并解决每一个问题的根本原因，但这样做的成本将高得令人望而却步。对于这些问题的长尾，我们转而依赖于解决症状并控制它们的剧本。在某些情况下，根本原因是我们工作的许多开源项目中的一个（比如Kubernetes、Prometheus、Employment、Consult、Hashicorp Vault）的已知问题，因此解决方法是唯一可行的选择。待命页面需要我们的工程师仔细关注。Databricks engineering根据优先级对问题进行分类。较低优先级的问题只会在工作时间出现（即工程师晚上不会被叫醒！）。例如，如果Kubernetes节点在我们的开发环境中损坏了，那么只会在第二天早上通知随叫随到的工程师来对问题进行分类。由于Databricks engineering分布在世界各地（在旧金山、多伦多和阿姆斯特丹都有办事处），而且大多数团队都在一个办公室之外，开发环境的问题可能会让某些工程师耽搁数小时，降低开发人员的生产效率。我们一直在寻找方法来减轻保持灯亮（KTLO）的负担，因此，设计一个系统，通过执行工程师定义的剧本来响应警报而无需人工干预，对于管理我们规模的资源非常有意义。我们着手设计一个系统，帮助我们解决这些系统性问题。自愈架构Healer架构由输入事件（Prometheus/Alertmanager）、执行（Healer端点、工作队列/线程）和操作（Jenkins、Kubernetes、Spinnaker作业）组成。Healer是使用一个事件驱动的体系结构设计的，它可以自主地修复Kubernetes基础设施。我们的警报系统（Prometheus，Alertmanager）监控我们的生产基础设施，并根据定义的表达式发出警报。Healer作为后端服务运行，监听来自Alertmanager的HTTP请求和警报有效负载。使用警报元数据，Healer根据警报类型和警报标签构建适当的修正。修正决定了修正操作以及所需的任何参数。每个修正都计划到工作线程池中。工作线程将通过调用相应的服务来运行相应的修正，然后监视修正是否完成。实际上，这可能是启动Jenkins、Kubernetes或Spinnaker自动化手动脚本工作流的工作。我们选择支持这些框架，因为它们为Databricks工程师提供了定制响应警报的操作的广泛能力。一旦修正完成，JIRA和Slack通知将被发送到相应的团队，以确认修正任务完成。治疗者可以很容易地扩展到新的治疗方法。Cloud Infra之外的工程团队可以将与服务警报集成在一起的补救工作，采取必要的措施从事故中恢复，从而降低整个工程部门的随叫随到负载。示例用例Healer的一个用例是修复Kubernetes节点上的低磁盘空间。待命工程师通过一个名为"NodeDiskPressure"的警报通知该问题。为了补救NodeDiskPressure，一个随叫随到的工程师将连接到适当的节点并执行docker image prune命令。为了实现自动化，我们首先开发一个由Healer触发的操作；我们定义了一个名为dockerprunode的Jenkins作业，它自动执行相当于连接到节点并执行docker image prune的手动步骤。然后，我们配置一个修复程序修复程序，通过定义一个修复程序规则来自动解决NodeDiskPressure警报，该规则绑定一个给定警报及其参数的精确修复（dockerprenode）。下面是如何将NodeDiskPressure警报转换为特定修正的示例，包括要运行的作业和所有需要的参数。最后一个修正对象有三个来自警报的"翻译"参数以及一个"静态"硬编码参数。Databricks自动修正服务修复程序针对NodeDiskPressure警报启动的示例修复。该配置还有一些其他参数，工程师可以配置这些参数来调整修复的确切行为。为了简洁起见，这里省略了它们。在定义了这个规则之后，底层问题就完全自动化了，让随叫随到的工程师可以专注于其他更重要的事情！未来的步骤目前Healer正在启动、运行并提高我们的开发基础设施的可用性。服务的下一步是什么样的？最初，我们计划搭载更多的云基础设施团队的用例。具体来说，我们正在研究以下用例：通过利用现有的系统使用率警报（CPU、内存）触发一个将增加集群容量的修正，支持对集群的细粒度自动扩展。终止并重新配置标识为不正常的Kubernetes节点。当服务TLS认证即将到期时，轮换。此外，我们希望继续在工程组织中推动这个工具的采用，并帮助其他团队加入他们的用例。这个通用框架可以扩展到其他团队，以减少他们的随叫随到的负载。我期待着看到在未来有什么其他的事件治疗师可以帮助补救数据块！特别感谢我的导师廖子恒（Ziheng Liao）、经理康南熙（Nanxi Kang）和Eric Wang，以及Databricks的其他云团队成员，提供了一次非常棒的实习体验！我在Databricks度过了一个非常愉快的暑假，我鼓励那些在平台工程领域寻找有挑战性和回报的职业的人加入这个团队。如果您有兴趣为我们的自愈架构作出贡献，请查看我们的开放式工作机会！免费试用Databricks。今天就开始吧