在我空闲的时候，我喜欢拼装高达模型，这些都是用来构建《高达》宇宙中标志性机甲的模型套件。你可能会好奇这和软件工程有什么关系。产品工程师可以被看作是利用这些套件来组装高达本身的工程师。他们能够利用所有部件，构建出一个可以运行、值得收藏甚至把玩的产品！

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

大约一年前，我在GitHub的团队转移到了基础设施组织，承担了新的角色和职责范围。此前，该团队处理的是外部客户问题，例如构建跨环境的新部署视图。这涉及到与依赖GitHub应对其所在行业挑战的用户互动。作为平台工程团队，我们的新客户是内部的，这使得我们的职责与之前以产品为中心的工程工作有所不同。

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

无论你是从事产品工程还是平台方面的工作，以下是一些应对平台难题的最佳实践。

理解你的领域

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

• 与你的"邻居"交流：与在该领域拥有更多知识和经验的团队安排一次交接会议。这次会议提供了一个询问术语和更深入了解团队将要解决问题的机会。
• 调查旧问题：如果存在一些已过时或仍然悬而未决的问题积压，它们可能会让你更好地了解系统当前的局限性和潜在的改进领域。
• 阅读文档：文档是知识的宝库，可以帮助你理解系统的工作原理。

将概念转化为平台特定技能

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

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

知识共享

通过分享经验教训和想法，工程师可以引入新的视角，从而带来突破和创新。花时间理解一个项目或解决方案成功或失败的原因，并分享这些发现，为我们未来的工作提供了新的视角。

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

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

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

影响半径

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

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

测试变更

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

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

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

需要记住的要点

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

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