你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

DevOps 清单

  • 项目

DevOps 是指将开发、质量保证和 IT 运营集成到统一的环境以及软件交付过程中。 评估 DevOps 的环境和过程时，可从此查检表着手。

环境

确保不同组织和团队中的业务一致性。 组织中发生资源、用途、目标和优先级冲突可能会给成功的运营带来风险。 请确保业务团队、开发团队和运营团队的目标一致。

确保团队了解你的软件生命周期。 团队需要了解应用程序的总体生命周期，以及每个应用程序在该生命周期中所处的阶段。 准备好这些信息可帮助所有团队成员知道他们目前应该做些什么，以及应该要为将来规划和准备什么。

缩短周期时间。 目的是尽量缩短从创意到开发出可用软件所花费的时间。 限制各个版本的大小和范围，以保持较低的测试负担。 尽量将构建、测试、配置和部署过程自动化。 清除开发人员之间以及开发人员与运营团队之间的沟通障碍。

评审并改进过程。 过程和流程（不管是自动的还是手动的）永远不是最终性的。 建立当前工作流、流程和文档的定期评审制度，并制定持续改进的目标。

做出前瞻性的规划。 针对故障做出前瞻性的规划。 制定流程以快速识别出现的问题，将问题上报给适当的团队成员加以解决，并确认其解决方法。

从故障中学习经验。 故障不可避免，但必须在故障中学到经验教训，以免故障重复发生。 如果发生操作性故障，应该围绕问题进行会审，阐述原因和解决方法，并分享你学到的经验教训。 尽可能更新构建过程，以便将来发生此类故障时可以自动检测到。

优化速度并收集数据。 规划的每种改进方案都是基于假设。 从容不迫。 将新的思路视为试验。 检测试验，以便可以收集生产数据来评估试验有效性。 如果假设有误，应准备好快速失败。

花费足够的时间学习。 失败和成功都是不错的学习机会。 在转移到新项目之前，花费时间来收集重要的经验教训，并确保团队吸收这些教训。 此外，为团队提供一些时间来培养技能、展开试验，以及学习新的工具和技术。

文档操作。 以等同于产品代码的质量阐述所有工具、过程和自动化任务的运行方法。 阐述所支持的任何系统的当前设计和体系结构，以及恢复过程和其他维护流程。 专注于实际执行的步骤，而不是理论最佳的过程。 定期评审并更新文档。 对于代码，请确保包含有意义的注释，尤其是在公共 API 中。 尽可能使用工具自动生成代码文档。

分享知识。 文档只对知道它存在并可以找到它的人员才有作用。 确保文档组织有序且能轻松找到。 创新方式：使用牛皮纸袋（非正式演示）、视频或新闻稿分享知识。

开发

为开发人员提供类似于生产的环境。 如果开发和测试环境与生产环境不相符，则很难测试和诊断问题。 应该让开发和测试环境尽量接近生产环境。 确保测试数据与生产环境中使用的数据一致，即使测试数据是示例数据而不是实际生产数据（出于隐私或合规性原因）。 计划生成并匿名化示例测试数据。

确保所有已获授权的团队成员可以预配基础结构和部署应用程序。 设置类似于生产环境中所用的资源和部署应用程序不应涉及复杂的手动任务，或者要求对系统有深层的技术知识。 任何具有适当权限的人都应该能够创建或部署类似于生产环境中所用的资源，而无需求助于运营团队。

这项建议并不意味着任何人都可以将实时更新推送到生产部署。 其目的是减少开发和 QA 团队在创建类似于生产的环境时所产生的矛盾。

检测每个应用程序以获取见解。 若要了解应用程序的运行状况，需要知道它们的执行情况，以及它们是否遇到了任何错误或问题。 始终将检测包含为一项设计要求，并且一开始就在每个应用程序中内置检测功能。 检测必须包括用于分析根本原因的事件日志记录，同时还应包括用于监视每个应用程序运行状况和使用情况的遥测数据与指标。

跟踪技术债务。 在许多项目中，发布计划的优先级在一定程度上高于代码质量。 始终阐述快捷做法或其他非最佳实施方法，并安排时间重新审视这些问题。

考虑将更新直接推送到生产环境。 为了缩短总体发布周期时间，请考虑将测试正确的代码直接推送到生产环境。 使用功能切换来控制要启用哪些功能。 这样，就可以使用切换机制来启用或禁用功能，快速从开发转移到发布阶段。 执行 Canary 发布（将特定的功能部署到生产环境的一部分区域）等测试时，切换机制也很有用。

正在测试

自动测试。 手动测试软件的过程非常繁琐且容易出错。 将常见的测试任务自动化，并将测试集成到生成过程中。 自动测试可确保测试覆盖范围一致，且能重现问题。 运行集成 UI 测试时，也使用自动化工具。 Azure 提供开发和测试资源，可帮助配置和运行测试。 有关详细信息，请参阅在 Azure 上进行开发和测试。

故障测试。 当系统无法连接到服务时，系统应正常做出响应。 当服务再次可用时，系统应该恢复。 将故障注入测试规定为测试环境和过渡环境评审的标准组成部分。 如果测试过程和做法比较健全，请考虑在生产环境中运行这些测试。

在生产环境中测试。 部署到生产环境并不是发布过程的最终结果。 请安排好测试，确保部署的代码可按预期方式运行。 对于不经常更新的部署，请将生产测试安排为日常性的维护工作。

自动执行性能测试以提前识别性能问题。 严重性能问题所造成的影响有时无非就是导致代码出现 bug。 尽管自动化的功能测试可以防止应用程序出现 bug，但这些测试可能无法检测性能问题。 根据延迟、加载时间和资源用量等指标定义可接受的性能目标。 在发布管道中包含自动化性能测试，确保应用程序符合这些目标。

执行容量测试。 应用程序可能在测试条件下可正常工作，但由于规模或资源限制，在生产环境中却出现问题。 始终定义最大预期容量和用量限制。 通过测试来确保应用程序可以处理这些限制，同时，测试在超过这些限制时会发生的情况。 定期执行容量测试。

完成初始发布后，每当你更新生产代码后，都应该运行性能和容量测试。 使用历史数据微调测试，并确定需要执行哪些类型的测试。

执行自动安全渗透测试。 确保应用程序的安全与测试任何其他功能一样重要。 将自动渗透测试规定为生成和部署过程的标准组成部分。 针对已部署的应用程序计划定期安全测试和漏洞扫描，以监视打开的端口、终结点和攻击活动。 自动测试并不意味着无需定期展开深入的安全评审。

执行自动业务连续性测试。 针对大规模业务连续性方案（包括备份、恢复和故障转移）制定测试方法。 设置自动化过程来定期执行这些测试。

发布

自动部署。 自动化提供许多优势，包括：

  • 能够更快、更可靠地完成部署。
  • 确保以一致的方式部署到任何受支持的环境，包括测试、过渡和生产环境。
  • 消除手动部署造成人为错误的风险。
  • 帮助将发布活动安排在方便的时间，从而尽量降低潜在停机造成的影响。

自动完成将每个应用程序部署到测试、过渡和生产环境的过程。 部署相应的系统来检测推出过程中出现的任何问题，并使用自动方法来前滚修复程序或回滚更改。

使用持续集成。 持续集成 (CI) 是根据定期计划将所有开发人员代码合并到中心代码库，然后自动执行标准生成和测试过程的做法。 CI 可确保整个团队同时处理代码库且不发生冲突。 CI 还有助于尽早发现代码缺陷。 最好是每次提交或签入代码时都运行 CI 过程。 它应该每天至少运行一次。

考虑采用基于树干的开发模型。 在此模型中，开发人员可将内容提交到单个树枝（树干）。 有一项要求是，提交不得中断生成。 此模型有助于实现 CI，因为所有的功能性工作都在树干中完成，并且所有合并冲突都可在每次提交时解决。

考虑使用持续交付。 持续交付 (CD) 是通过自动生成、测试代码并将其部署到类似生产的环境，确保代码随时可供部署的做法。 添加 CD 来创建完整 CI/CD 管道的做法有助于尽早检测到代码缺陷。 这还可以确保能够在短时间内发布经过适当测试的更新。

持续部署是自动引入通过 CI/CD 管道传递的所有更新，并将其部署到生产环境的过程。 持续部署需要可靠的自动测试和高级过程规划， 不一定适合所有团队。

保持小规模的增量更改。 相比小规模的更改，大规模的代码更改更有可能造成 bug。 请尽量保持小规模的更改。 这样可以限制每次更改造成的潜在影响，并简化识别和调试问题的任务。

控制更改内容透露。 确保你能够控制最终用户何时可以看到更新。 考虑使用功能切换来控制何时为最终用户启用功能。

实施发布管理策略，以降低部署风险。 将应用程序更新部署到生产环境始终存在一定的风险。 要降低此风险，请使用 Canary 发布或蓝绿部署等策略将更新部署到一部分用户。 确认每项更新按预期工作，然后将每项更新推出到系统的其他部分。

阐述所有更改。 次要更新和配置更改可能是产生混淆和版本冲突的根源。 请始终保留任何更改的明确记录，即使是轻微的更新。 记录更改的任何内容，包括应用的修补程序、策略更改和配置更改。 更改记录应该向整个团队显示。 但是，不要在这些日志中包含敏感数据。 例如，在日志中指出凭据已更新以及谁做了更改，但不要记录更新的凭据。

考虑使基础结构保持不可变。 不可变基础结构基于在将基础结构部署到生产环境后不应对其进行修改的原则。 否则，可能会陷入这种状态：应用即席更改后，很难确切地知道哪些内容已更改。 不可变基础结构的工作原理是将整个服务器作为任何新部署的一部分进行替换。 通过这种方法，可将代码和托管环境作为块进行测试和部署。 部署后，在达到下一个生成和部署周期之前，请不要修改基础结构组件。

监视

使系统可观测。 运营团队始终应该能够清晰洞察系统或服务的运行状况和状态。 设置外部运行状况终结点来监视状态，并确保应用程序在编程设计上可以检测操作指标。 可使用常见的一致性架构，以便跨系统关联事件。 跟踪 Azure 资源运行状况和状态的标准方法是使用 Azure 诊断和 Application Insights。 Azure Monitor 还针对云或混合解决方案提供集中式监视和管理。

聚合并关联日志和指标。 适当检测的遥测系统会提供大量原始性能数据和事件日志。 确保系统快速处理并关联遥测数据和日志数据，使运营人员始终获得系统运行状况的最新画面。 以合理的方式组织和显示数据，以便在事件相互关联时，能够看到问题的内聚视图。

有关数据处理方式及其存储期限的要求，请查阅企业保留策略。

实施自动警报和通知。 设置 Monitor 等监视工具，以检测指示潜在问题或当前问题的模式或状态。 将警报发送给可以解决问题的团队成员。 优化警报以避免误报。

监视资产和资源的过期。 某些资源和资产（例如证书）会过期。 请确保跟踪哪些资产会过期、何时过期，以及哪些服务或功能依赖于这些资产。 使用自动化过程来监视这些资产。 在资产过期之前通知运营团队，如果过期可能会导致应用程序中断，请上报问题。

管理

将操作任务自动化。 手动处理重复的操作过程是容易出错。 请尽量将这些任务自动化，以确保一致的执行结果和质量。 使用源代码管理对实现自动化的代码进行版本控制。 与对待任何其他代码一样测试自动化工具。

在预配中采用基础结构即代码方法。 尽量减少预配资源所需的手动配置工作量。 应该使用脚本和 Azure 资源管理器模板。 像维护的其他代码一样，在源代码管理中保留脚本和模板。

考虑使用容器。 容器提供标准的基于包的接口用于部署应用程序。 使用容器时，可以通过独立的包（其中包含运行应用程序所需的所有软件、依赖项和文件）来部署应用程序。 这种做法大大简化了部署过程。

容器还在应用程序与底层操作系统之间创建一个抽象层，使不同的环境保持一致性。 这种抽象还能将容器与主机上运行的其他进程或应用程序隔离开来。

实施复原和自我修复。 复原是指应用程序在故障后恢复的能力。 复原策略包括重试暂时性故障，以及故障转移到辅助实例（甚至另一个区域）。 有关详细信息，请参阅设计可靠的 Azure 应用程序。 检测应用程序以立即报告问题，以便可以应对服务中断或其他系统故障。

创建操作手册。 操作手册或 runbook 阐述操作人员在维护系统时所需的流程和管理信息。 另外，它还阐述在服务发生故障或其他中断问题时，可以派上用场的任何操作方案和缓解计划。 请在开发过程中创建此文档，并一直使其保持最新。 将这些资源视为需要定期审查、测试和改进的动态文档。

共享文档至关重要。 鼓励团队成员参与并分享知识。 整个团队应有权访问文档。 为团队中更新文档的任何人员提供方便。

制定值守流程。 确保制作值守职责、计划和流程的文档并与所有团队成员共享。 始终使这些信息保持最新。

阐述第三方依赖关系的升级流程。 如果应用程序依赖于不直接受你控制的外部第三方服务，则必须做好应对服务中断的计划。 为计划的缓解过程创建文档。 包含支持人员联系人和升级路径。

使用配置管理。 规划配置更改，使其对操作人员可见，并记录这些更改。 可以使用配置管理数据库或配置即代码方法来实现这些目的。 定期审核配置，确保所需的设置已实际部署到位。

获取 Azure 支持计划并了解支持过程。 Azure 提供许多支持计划。 确定符合需求的计划，并确保整个团队了解该计划的用法。 团队成员应了解该计划的细节、支持过程的工作方式，以及如何使用 Azure 开具支持票证。 如果你预期会发生大规模事件，Azure 支持人员可以帮助你提高服务限制。 有关详细信息，请参阅 Azure 支持计划常见问题解答。

授予资源访问权限时，请遵循最低特权原则。 谨慎管理资源的访问权限。 除非要显式授予某个用户对某个资源的访问权限，否则应默认拒绝访问。 只向用户授予完成其任务所需的访问权限。 跟踪用户权限并执行定期安全审核。

使用 Azure 基于角色的访问控制。 分配用户帐户和资源访问权限不应是手动过程。 使用 Azure 基于角色的访问控制 (Azure RBAC) 根据 Microsoft Entra ID 标识和组来授予访问权限。

用 bug 跟踪系统来跟踪问题。 如果没有适当的问题跟踪方法，则很容易丢失进度、产生重复工作，或造成新问题。 不要依赖于非正式的人际交流来跟踪 bug 状态。 请使用 bug 跟踪工具来记录有关问题的详细信息、分配资源来解决问题，并提供进度和状态的审核线索。

在更改管理系统中管理所有资源。 如果在管理和版本控制系统中包括 DevOps 过程的所有方面，则你可以轻松跟踪和审核更改。 包括代码、基础结构、配置、文档和脚本。 在整个测试、生成和审查过程中，将所有这些类型的资源视为代码。

使用查检表。 操作查检表可帮助你按照过程行事。 大手册很容易遗漏内容，但遵循查检表可以促使你关注可能会忽略的细节。 维护查检表，并持续寻求可自动执行任务和优化过程的方法。

后续步骤