32、基础设施代码团队工作流最佳实践-优快云博客

基础设施代码团队工作流最佳实践

一、个人基础设施实例

在大多数工作流中，我们通常会拉取代码、进行编辑，然后将其推送到共享代码库，再通过管道交付流程将代码应用到相关环境。理想情况下，在将代码更改推送到共享存储库之前，我们应该对其进行测试，这样可以确保更改符合预期，并且比等待管道将代码运行到在线测试阶段更快，还能避免因更改导致管道阶段失败而破坏构建。

为了便于在推送代码更改之前进行测试，团队可以采取以下措施：
1. 创建个人基础设施实例 ：让每个参与基础设施代码工作的人都能创建自己的基础设施实例，并在不使用时销毁它们。避免使用共享的“开发”实例，因为多人将本地编辑的代码应用到共享实例会导致混乱。
2. 保持基础设施组件小型化 ：能够单独启动系统的任何组件实例，必要时可以使用测试夹具来处理依赖关系。如果需要启动整个系统，除非系统非常小，否则人们很难在个人实例上工作。
3. 使用相同工具和脚本 ：个人在应用和测试基础设施实例时，应使用与共享实例相同的工具和脚本。可以创建工具和脚本的包，以便在不同位置使用。

二、集中管理的个人实例

虽然从工作站将代码应用到个人实例比应用到共享实例更安全，但使用集中式服务管理个人实例也有优势。例如，曾有团队遇到过有人休假时个人实例仍在运行，且由于使用未推送到存储库的本地版本代码创建实例，导致难以销毁的问题。

因此，一些团队采用的做法是：每个人将更改推送到个人分支，由中央服务将这些更改应用到他们的个人基础设施实例进行测试。在这种安排下，个人分支模拟本地代码，直到将更改合并到共享分支或主干，人们才认为更改已提交。这样，代码可以集中供其他人在其不在时查看和使用。

三、工作流中的源代码分支

分支是共享源代码存储库的强大功能，它使人们更容易对代码库的不同副本（分支）进行更改，并在准备好时集成工作。在基础设施即代码的背景下，分支策略有两个重要区别：
1. 生产路径模式与集成模式 ：生产路径分支模式用于管理将哪些版本的代码应用到环境，常见的模式包括发布分支和环境分支；集成模式描述了在代码库上工作的人员如何管理工作的集成时间和方式，大多数团队使用主线集成模式，结合功能分支或持续集成。
2. 集成频率的重要性 ：团队使用分支的有效性最重要的因素是集成频率，即每个人将所有代码合并到中央存储库的同一（主）分支的频率。研究表明，团队内更频繁地集成所有代码与更高的商业绩效相关，建议团队成员每天至少将所有代码集成一次到主分支或主干。

需要注意的是，合并并不等同于集成。连续集成要求每个人在工作时进行双向合并，即个人将自己的更改合并到主分支，同时将主分支合并回自己的分支或本地代码副本，并且至少每天进行一次。

四、防止配置漂移

配置漂移是指相似的基础设施元素随着时间推移变得不一致的问题，通常是由于团队使用基础设施编码工具自动化旧工作方式的部分内容，而未完全适应新的工作方式导致的。为避免配置漂移，可以采取以下措施：

4.1 最小化自动化延迟

自动化延迟是指运行自动化过程（如应用基础设施代码）的间隔时间。间隔时间越长，过程失败的可能性就越大。即使代码没有更改，长时间后重新应用代码仍可能因各种原因失败，例如系统其他部分的更改、工具或服务的升级、传递依赖项的更新以及手动修复未融入代码等。因此，更频繁地应用基础设施代码可以降低失败的可能性，并且在失败发生时更容易快速发现原因。

4.2 避免临时应用

一些团队习惯仅为进行特定更改而应用代码，如仅使用基础设施代码来配置新基础设施，而不用于更改现有系统；或者编写并应用代码进行临时的特定部分更改。这些习惯可能会导致配置漂移或自动化延迟。

4.3 持续应用代码

消除配置漂移的核心策略是持续将基础设施代码应用到实例，即使代码没有更改。许多服务器配置工具（如 Chef 和 Puppet）设计为按计划（通常每小时）重新应用配置。GitOps 方法也强调持续将源代码分支的代码同步到环境，使用服务持续比较代码和系统，减少配置漂移。

4.4 不可变基础设施

不可变基础设施通过另一种方式解决配置漂移问题。它只在创建实例时应用一次配置代码，当代码更改时，创建新实例并替换旧实例。不过，通过创建新实例进行更改需要复杂的技术来避免停机，并且自动化延迟仍然可能是一个问题，因此使用不可变基础设施的团队通常会频繁重建实例。

4.5 GitOps

GitOps 是基础设施即代码的一种变体，强调将系统定义为代码。它不规定基础设施代码的测试和交付方法，但与使用管道交付代码兼容。GitOps 不鼓励使用交付工件，而是通过将更改合并到源代码分支来推动代码更改。其关键要素是持续将代码同步到系统，使用服务持续比较代码和系统，减少配置漂移。但有些团队仅实现了环境分支实践，而未持续同步代码，容易陷入临时更改过程和不良的复制粘贴习惯。

下面是一个简单的 mermaid 流程图，展示防止配置漂移的主要步骤：

graph LR
    A[开始] --> B[最小化自动化延迟]
    A --> C[避免临时应用]
    A --> D[持续应用代码]
    A --> E[使用不可变基础设施]
    A --> F[采用GitOps]
    B --> G[减少配置漂移]
    C --> G
    D --> G
    E --> G
    F --> G
    G --> H[结束]

五、基于管道工作流的治理

对于大多数组织，尤其是大型组织和受监管行业（如金融和医疗保健）的组织，治理是一个重要问题。治理并非是增加不必要的工作摩擦，而是确保工作按照组织政策负责任地进行。

5.1 重新分配职责

将系统定义为代码为重新分配参与基础设施工作的人员的职责和工作方式创造了机会，具体因素如下：
1. 可重用性 ：基础设施代码可以在多个环境和系统中设计、审查和重用，无需为每个新服务器或环境进行冗长的设计、审查和签字流程。
2. 可运行代码 ：代码编写速度快，人们可以基于可运行代码和示例基础设施进行审查和决策，反馈循环更快、更准确。
3. 一致性 ：代码创建的环境比人工遵循清单更加一致，在早期环境中测试和审查基础设施能提供更快、更好的反馈。
4. 自动化测试 ：自动化测试（包括安全和合规性测试）为基础设施代码工作者提供快速反馈，他们可以在工作中自行纠正许多问题，无需频繁求助专家。
5. 质量民主化 ：非专家人员也可以对基础设施中敏感区域（如网络和安全策略）的代码进行更改，并使用专家创建的工具和测试进行检查。专家可以在更改应用到生产系统之前进行审查和批准，这种审查方式更高效。
6. 治理渠道 ：基础设施代码库和用于将更改交付到生产实例的管道可以根据治理要求进行组织，不同敏感级别的更改经过不同的审查和签字步骤。

5.2 左移原则

左移原则描述了在代码实现阶段进行严格测试对工作流和交付实践的影响。组织可以减少在将代码应用到生产之前的繁琐流程，参与治理和测试的人员应专注于代码实现阶段，为团队提供工具和支持，促进早期和频繁的测试。

5.3 一个带治理的基础设施即代码示例流程

以 ShopSpinner 为例，它有一个可重用的堆栈用于创建应用服务器的基础设施。技术领导团队定义了应用服务器基础设施必须支持的 CFRs（如用户订单数量和频率、界面响应时间、服务器故障恢复时间等）。

基础设施团队、应用团队、站点可靠性工程师（SRE）和质量保证（QA）人员共同实施自动化测试，将这些测试构建到管道的多个阶段，逐步测试堆栈的不同组件。有了这些测试后，人们无需再将基础设施更改提交给技术领导团队或 SRE 进行审查。当工程师更改网络配置时，管道会自动检查结果基础设施是否仍符合 CFRs，若不符合，工程师能在几分钟内发现并立即纠正。

如果更改导致客户实例出现问题且未被自动化测试捕获，团队可以进行无责事后分析，审查问题原因，可能需要更改或添加 CFRs，或者改进测试套件。

5.4 规范紧急修复流程

许多团队有单独的紧急更改流程以快速交付修复，但这可能表明正常更改流程需要改进。紧急更改流程通常通过省略不必要步骤或必要步骤来加快速度。如果在紧急情况下可以安全地省略某个步骤，那么在正常流程中也可以考虑省略；如果省略步骤风险不可接受，则应找到更有效的处理方式并每次都执行。

六、总结

当组织采用基础设施即代码时，人员应减少日常事务和守门工作的时间，将更多时间用于持续改进系统本身的能力。这些努力将反映在软件交付和运营绩效的四个指标上。通过合理管理个人基础设施实例、有效使用源代码分支、防止配置漂移以及实施基于管道工作流的治理等措施，可以提高团队的工作效率和系统的稳定性。

下面是一个 mermaid 流程图，展示带治理的基础设施即代码示例流程：

graph LR
    A[定义CFRs] --> B[实施自动化测试]
    B --> C[构建到管道阶段]
    C --> D[工程师更改配置]
    D --> E[管道检查CFRs]
    E --> F{是否符合CFRs}
    F -- 是 --> G[应用到生产]
    F -- 否 --> H[工程师纠正问题]
    H --> D
    G --> I[持续监控]
    I --> J{是否出现问题}
    J -- 是 --> K[无责事后分析]
    K --> L[调整CFRs或测试套件]
    L --> B
    J -- 否 --> M[继续运行]

七、关键要点回顾与深入分析

7.1 个人基础设施实例与集中管理

个人基础设施实例的创建和管理是保障代码测试效率和独立性的关键。创建个人实例能让团队成员在不干扰共享环境的前提下进行代码测试，避免了多人在共享实例上操作带来的混乱。而集中管理个人实例则提供了代码的可追溯性和可维护性，防止因个人操作不当导致无法销毁实例的问题。

例如，在团队开发中，如果成员A在休假前忘记关闭自己的个人实例，且该实例是基于未推送至仓库的本地代码创建的，那么其他成员很难对其进行清理。而采用集中管理，所有更改都通过个人分支推送到中央服务，即使成员不在，其他成员也能根据代码状态进行相应操作。

7.2 源代码分支策略

源代码分支策略在团队协作中起着至关重要的作用。生产路径模式和集成模式的区分，让团队能够更清晰地管理代码版本和集成过程。集成频率更是影响团队效率和商业绩效的关键因素。

以一个软件开发团队为例，如果团队成员采用功能分支模式，且长时间不将自己的功能分支集成到主分支，那么当多个成员的功能分支都完成后，集成时可能会出现大量的冲突和问题，导致项目进度延迟。而如果团队能够保证每天至少进行一次全面的代码集成，那么就能及时发现和解决冲突，提高代码的稳定性和可维护性。

7.3 防止配置漂移的措施

配置漂移是基础设施管理中的一个常见问题，会导致系统的不一致性和不可靠性。最小化自动化延迟、避免临时应用、持续应用代码、采用不可变基础设施和 GitOps 等措施，从不同角度解决了配置漂移的问题。

防止配置漂移措施	优点	缺点
最小化自动化延迟	降低代码应用失败概率，快速定位问题	需要更频繁的自动化操作，增加系统资源消耗
避免临时应用	减少配置不一致性	可能需要调整工作流程，增加开发成本
持续应用代码	保持系统配置一致性	对自动化工具和服务要求较高
不可变基础设施	彻底解决配置漂移问题	更改实例需要复杂技术，可能导致停机
GitOps	持续同步代码，减少人为错误	部分团队难以完全实现，易陷入不良习惯

7.4 基于管道工作流的治理

治理在组织的基础设施管理中不可或缺，尤其是对于受监管行业的组织。重新分配职责、左移原则、示例流程和规范紧急修复流程等方面，为组织提供了一套完整的治理方案。

重新分配职责让团队成员能够根据自身能力和专业领域更好地参与到基础设施管理中，提高工作效率和质量。左移原则强调在代码实现阶段进行严格测试，减少后期的问题和成本。示例流程展示了如何通过自动化测试和 CFRs 来保障基础设施的质量和合规性。规范紧急修复流程则确保了在紧急情况下能够快速、安全地进行系统修复。

八、实际应用建议

8.1 团队协作方面

建立明确的工作流程 ：团队应制定详细的代码拉取、编辑、测试和推送流程，明确每个环节的责任人。例如，规定在推送代码到共享仓库前，必须先在个人实例上进行充分测试，并通过自动化测试套件的检查。
加强沟通与培训 ：定期组织团队内部的沟通会议，分享工作进展和遇到的问题。同时，为团队成员提供相关技术和工具的培训，提高他们的技能水平和工作效率。

8.2 技术实施方面

选择合适的工具和平台 ：根据团队的需求和规模，选择适合的基础设施管理工具和平台，如 batect 和 Dojo 等，确保能够创建可重复、可共享的容器。
持续优化自动化流程 ：不断优化自动化测试和部署流程，减少自动化延迟，提高系统的稳定性和可靠性。例如，采用定时任务或事件触发机制，确保基础设施代码能够及时应用到各个环境。

8.3 治理与合规方面

制定完善的治理策略 ：根据组织的政策和法规要求，制定详细的治理策略，明确不同敏感级别的代码更改需要经过的审查和签字步骤。
定期进行审计和评估 ：定期对基础设施进行审计和评估，检查是否存在配置漂移、安全漏洞等问题，并及时进行整改。

九、未来趋势展望

9.1 自动化程度的进一步提高

随着人工智能和机器学习技术的发展，未来基础设施管理的自动化程度将进一步提高。例如，自动化工具可以根据系统的运行状态自动调整配置，预测潜在的问题并提前进行处理。

9.2 云原生技术的广泛应用

云原生技术（如 Kubernetes、Docker 等）将在基础设施管理中得到更广泛的应用。这些技术能够提供更高效、更灵活的资源管理和部署方式，帮助组织更好地应对业务的变化和挑战。

9.3 安全与合规的重要性日益凸显

在数字化时代，安全和合规问题将越来越受到关注。组织需要加强对基础设施的安全防护，确保数据的保密性、完整性和可用性。同时，要严格遵守相关法规和标准，避免因违规行为而带来的法律风险。

十、总结与结语

通过合理管理个人基础设施实例、有效运用源代码分支策略、防止配置漂移以及实施基于管道工作流的治理等措施，组织能够提高团队的工作效率和系统的稳定性，实现软件交付和运营绩效的提升。在实际应用中，团队应根据自身的需求和特点，选择合适的方法和工具，并不断进行优化和改进。同时，要关注未来的技术趋势，提前做好准备，以适应不断变化的市场环境。

在未来的基础设施管理中，自动化、云原生和安全合规将成为重要的发展方向。组织应积极拥抱这些趋势，不断提升自身的竞争力，为业务的发展提供坚实的支撑。

下面是一个 mermaid 流程图，展示未来基础设施管理的发展趋势：

graph LR
    A[当前基础设施管理] --> B[自动化程度提高]
    A --> C[云原生技术应用]
    A --> D[安全与合规加强]
    B --> E[智能自动化管理]
    C --> F[高效资源管理]
    D --> G[严格安全防护]
    E --> H[未来基础设施管理]
    F --> H
    G --> H

总之，基础设施即代码的实践为组织带来了诸多好处，但也需要团队不断学习和探索，以适应不断变化的技术和业务需求。通过持续改进和创新，组织能够在竞争激烈的市场中取得优势，实现可持续发展。