GitHub工程师如何应对平台问题

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

在我的业余时间，我喜欢拼装高达模型，这是一种可以组装高达宇宙中标志性机甲的模型套件。你可能想知道这跟软件工程有什么关系。产品工程师可以看作是那些拿着这些套件组装高达本身的工程师。他们能够利用所有部件，构建出一个可供收藏甚至把玩的产品！ 而平台工程师，则提供组装这些套件所需的工具（如剪钳和锉刀），甚至可能搭建一个很酷的展示柜，让大家都能看到最终成品。他们确保任何组装者都拥有所有必要的工具，即使他们自己并不亲手组装高达。

大约一年前，我在GitHub的团队转入了基础设施组织，继承了新的角色和职责领域。此前，该团队处理的是外部客户的问题，例如构建跨环境的新部署视图。这涉及与依赖GitHub解决其所在行业挑战的用户互动。作为平台工程团队，我们的新客户是内部的，这使得我们的职责与我们之前所做的以产品为重点的工程工作不同。 回到我的高达例子，我们现在负责的不是组装套件，而是构建套件中的组件。适应这种变化意味着我必须重新思考代码测试和问题解决的方法。 无论你是从事产品工程还是平台方面的工作，以下是一些解决平台问题的最佳实践。

理解你的领域

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

• 与同事沟通：与一个对该主题有更多知识和经验的团队安排一次交接会议。这次会议提供了询问术语并更深入理解团队将要解决的问题的机会。
• 调查旧问题：如果存在一批未解决或持续存在的问题，它们可能会让你更好地理解系统当前的限制以及潜在的改进领域。
• 阅读文档：文档是知识的宝库，可以帮助你理解系统的工作原理。

将概念与平台特定技能联系起来

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

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

知识共享

通过分享经验教训和想法，工程师可以引入新的视角，从而带来突破和创新。花时间理解一个项目或解决方案成功或失败的原因，并分享这些发现，可以提供我们在未来可以利用的新视角。 以下是知识共享如此重要的三个原因：

• 团队合作成就梦想：协作通常能更快地解决问题，并促进新解决方案的创新，因为工程师有机会相互学习并在现有想法上扩展。
• 防止知识流失：如果我们不分享我们学到的经验教训，就会阻止信息在团队或组织内传播。如果一名工程师离开公司或只是暂时无法联系，这就会成为一个问题。
• 提升客户成功：作为工程师，我们的解决方案应该有效地服务客户。通过分享我们的知识和经验教训，我们可以帮助团队构建可靠、可扩展和安全的平台，从而使我们能够创造出满足客户需求和期望的更好的产品！

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

影响半径

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

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

测试变更

在分布式环境中测试变更可能具有挑战性，尤其是对于像DNS这样的服务。解决这个问题的关键步骤是利用测试站点作为一台“真实”机器，在那里你可以实施和评估所有变更。

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

理想情况下，测试完成后，变更将按主机逐一实施。这种方法允许单个机器回滚，并防止变更被应用到未受影响的主机。

需要记住的要点

平台工程可能很困难。GitHub运行的系统很复杂，有许多服务和移动部件。然而，没有什么比看到一切顺利运转更令人欣慰的了。当平台平稳运行，团队能够更快、更可靠地交付时，我们工程团队在幕后所做的所有艰苦工作都会得到回报——这使得GitHub能够成为所有开发者的家园。

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