GitHub工程师解决平台问题的最佳实践

GitHub工程师如何解决平台问题

我们在大规模快速识别、解决和预防问题的最佳实践

在我的业余时间，我喜欢建造高达模型，这些是来自高达宇宙的标志性机甲模型套件。您可能想知道这与软件工程有什么关系。产品工程师可以看作是那些拿起这些套件并建造高达本身的工程师。他们能够利用所有部件构建一个可工作的产品，既有趣收藏甚至可以把玩！

另一方面，平台工程师提供建造这些套件所需的工具（如剪钳和锉刀），甚至可能建造一个很酷的展示架让每个人都能看到最终产品。他们确保建造者拥有所有必要的工具，即使他们自己不亲自建造高达。

大约一年前，我在GitHub的团队转移到了基础设施组织，继承了新的角色和责任领域（AoRs）。此前，该团队处理外部客户问题，例如构建跨环境的新部署视图。这涉及与依赖GitHub解决各自行业挑战的用户互动。作为平台工程团队，我们的新客户是内部的，这使得我们的职责与我们之前所做的产品导向工程工作不同。

回到我的高达例子，我们现在不是建造套件，而是负责建造套件的组件。适应这种变化意味着我必须重新思考代码测试和问题解决的方法。

无论您是从事产品工程还是平台方面的工作，以下是解决平台问题的一些最佳实践。

在解决问题之前，最关键的步骤之一是理解领域。“领域"是团队和平台组织运营的业务和技术主题领域。这需要理解技术术语以及这些系统如何交互以提供快速可靠的解决方案。以下是快速上手的方法：

虽然前面的建议提供了适用于产品和平台团队的一般指导，但作为基础层的平台团队需要更深入的理解。

网络：理解网络基础对所有工程师都至关重要，即使那些不直接参与网络操作的人也是如此。这包括TCP、UDP和L4负载均衡等概念，以及dig等调试工具。牢固掌握这些领域对于理解网络流量如何影响您的平台至关重要。
操作系统和硬件：选择适当的虚拟机（VM）或物理硬件对于可扩展性和成本管理都至关重要。为特定应用程序做出明智选择需要对两者有牢固掌握。这与为机器选择正确的操作系统密切相关，这对于避免具有漏洞或接近生命终止的系统很重要。
基础设施即代码（IaC）：像Terraform、Ansible和Consul这样的自动化工具变得越来越重要。随着这些工具在基础设施配置和修改过程中显著减少人为错误，熟练使用它们正在成为必需。
分布式系统：处理平台问题，特别是在分布式系统中，需要深刻理解故障是不可避免的。因此，采用像故障转移和恢复机制这样的主动解决方案对于保持系统可靠性和防止不良用户体验至关重要。这方面的最佳方法完全取决于具体问题和期望的系统行为。

通过分享经验教训和想法，工程师可以引入新的视角，从而带来突破和创新。花时间理解项目或解决方案为什么有效或无效，并分享这些发现提供了我们可以继续使用的新视角。

以下是知识共享如此重要的三个原因：

团队合作让梦想成真：协作通常导致更快的问题解决并促进新解决方案的创新，因为工程师有机会相互学习并扩展现有想法。
防止知识丢失：如果我们不分享经验教训，我们就阻止了信息在团队或组织中的传播。如果工程师离开公司或 simply 不可用，这就会成为问题。
提高客户成功：作为工程师，我们的解决方案应该有效地服务客户。通过分享我们的知识和经验教训，我们可以帮助团队构建可靠、可扩展和安全的平台，这将使我们能够创建满足客户需求和期望的更好产品！

但是在影响半径和测试过程方面，产品工程和基础设施工程之间开始出现巨大差异。

平台作为系统的基本构建块，任何更改（无论大小）都可能影响广泛的产品。我们的团队负责DNS，这是一项影响众多产品的基础服务。即使对此服务的微小改动也可能产生广泛后果，可能破坏我们网站上内容的访问，并影响从GitHub Pages到GitHub Copilot的产品。

理解半径：或理解下游依赖关系。与依赖我们服务的团队直接沟通提供了关于提议的更改如何影响其他服务的宝贵见解。
事后分析：通过查看与我们平台相关的过去事件并询问"此事件的影响是什么？"，我们可以围绕引入的更改或故障、我们的平台在其中扮演的角色以及如何修复形成更多上下文。
监控和遥测：将重要的监控和日志记录压缩成小而易于理解的媒介，以提供系统的总体健康状况。例如，这可以是单一可用性指标（SAM）。快速浏览单个仪表板的能力使工程师能够快速定位问题源，并简化调试和事件缓解过程，与搜索和解释详细监视器或日志消息相比。

在分布式环境中测试更改可能具有挑战性，特别是对于像DNS这样的服务。解决此问题的关键步骤是利用测试站点作为"真实"机器，您可以在其中实施和评估所有更改。

基础设施即代码（IaC）：当使用像Terraform或Ansible这样的工具时，测试像配置和取消配置机器这样的基本操作至关重要。在某些情况下，机器将需要重新配置。在这些情况下，我们希望确保机器不会被意外删除，并且如果需要，我们保留创建新机器的能力。
端到端（E2E）：开始将一些网络流量引导到这些服务器。然后团队可以通过直接与主机交互来观察主机行为，或者我们可以通过转移一小部分流量来评估功能。
自我修复：我们希望测试平台从意外负载中恢复的能力，并在瓶颈影响用户之前识别它们。早期识别瓶颈或错误对于维护我们平台健康至关重要。

理想情况下，测试完成后，更改将在逐主机的基础上实施。这种方法允许单独机器回滚，并防止更改应用于未受影响的主机。

平台工程可能很困难。GitHub运营的系统很复杂，有许多服务和移动部件。但是，没有什么比看到一切整合在一起更好的了。当平台平稳运行且团队能够更快、更可靠地交付时，我们工程团队在幕后所做的所有艰苦工作真的得到了回报——这使GitHub成为所有开发者的家园。

想深入了解？查看我们与基础设施相关的博客文章。