# 准备
**Topics**
+ [
# OPS 4. 如何在工作负载中实现可观测性？
](ops-04.md)
+ [
# OPS 5. 如何减少缺陷、简化修复和改进生产流程？
](ops-05.md)
+ [
# OPS 6. 如何缓解部署风险？
](ops-06.md)
+ [
# OPS 7. 如何知道您已经准备好支持某种工作负载？
](ops-07.md)
# OPS 4. 如何在工作负载中实现可观测性？
在工作负载中实现可观测性，以便您可以了解其状态并根据业务要求作出数据驱动型决策。
**Topics**
+ [
# OPS04-BP01 确定关键绩效指标
](ops_observability_identify_kpis.md)
+ [
# OPS04-BP02 实施应用程序遥测
](ops_observability_application_telemetry.md)
+ [
# OPS04-BP03 实施用户体验遥测
](ops_observability_customer_telemetry.md)
+ [
# OPS04-BP04 实施依赖项遥测
](ops_observability_dependency_telemetry.md)
+ [
# OPS04-BP05 实施分布式跟踪
](ops_observability_dist_trace.md)
# OPS04-BP01 确定关键绩效指标
要在工作负载中实现可观测性，首先要了解其状态，并根据业务要求做出数据驱动型决策。确保监控活动与业务目标相一致的最有效方法之一是，定义和监控关键绩效指标（KPI）。
**期望结果：**与业务目标紧密协调的高效可观测性实践，确保监控工作始终为切实的业务成果服务。
**常见反模式：**
+ 不明确的 KPI：在没有明确 KPI 的情况下工作可能会导致监控过多或过少内容，从而缺少重要信号。
+ 静态 KPI：不会随着工作负载或业务目标的发展变化而重新审视或完善 KPI。
+ 不一致：重点关注与业务成果不直接相关或难以与现实问题关联的技术指标。
**建立此最佳实践的好处：**
+ 易于发现问题：业务 KPI 通常比技术指标能够更清楚地揭示问题。与筛查众多技术指标相比，深入研究业务 KPI 有助于更有效地查明问题。
+ 业务协调：确保监控活动直接支持业务目标。
+ 效率：将监控资源和注意力优先放在重要的指标上。
+ 积极主动：在问题对业务产生更广泛影响之前发现问题并加以解决。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要有效地定义工作负载 KPI，请执行以下操作：
1. **从业务成果开始：**在深入研究指标之前，请先了解期望的业务成果。是销售额增加、用户参与度提高还是响应时间更短？
1. **将技术指标与业务目标相关联：**并非所有技术指标都会对业务成果产生直接影响。确定那些确实会产生直接影响的指标，但使用业务 KPI 来发现问题通常更为简单。
1. **使用 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)：**使用 CloudWatch 来定义和监控代表 KPI 的指标。
1. **定期审查和更新 KPI：**随着工作负载和业务的发展，请保持 KPI 的相关性。
1. **让利益相关方参与其中：**让技术和业务团队参与定义和审查 KPI。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
+ [OPS04-BP03 实施用户体验遥测](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 实施依赖项遥测](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 实施分布式跟踪](ops_observability_dist_trace.md)
**相关文档：**
+ [AWS Observability Best Practices](https://aws-observability.github.io/observability-best-practices/)
+ 《[Amazon CloudWatch 用户指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)》
+ [AWS Observability Skill Builder Course](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
**相关视频：**
+ [Developing an observability strategy](https://www.youtube.com/watch?v=Ub3ATriFapQ)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US)
# OPS04-BP02 实施应用程序遥测
应用程序遥测是实现工作负载可观测性的基础。发射遥测数据至关重要，它可以提供切实可行的洞察，便于了解应用程序的状态以及技术和业务成果的实现情况。从故障排除到衡量新功能的影响或确保与业务关键绩效指标（KPI）保持一致，应用程序遥测可为构建、操作和改进工作负载的方式提供指导。
指标、日志和跟踪数据构成了可观测性的三个主要支柱。它们用作诊断工具来描述应用程序状态。随着时间的推移，还可协助创建基准和识别异常情况。但是，为了确保监控活动与业务目标协调一致，定义和监控 KPI 至关重要。与只考虑纯粹的技术指标相比，业务 KPI 通常有助于更轻松地发现问题。
真实用户监控（RUM）和综合事务等其他遥测类型，是对这些主要数据来源的补充。RUM 有助于了解实时用户交互，而综合事务则模拟潜在的用户行为，有助于提前发现瓶颈，以防真实用户遇到瓶颈。
**期望结果：**获得有关工作负载性能的切实可行的洞察。这些洞察有助于主动作出性能优化决策，提高工作负载稳定性，简化 CI/CD 流程，并有效地利用资源。
**常见反模式：**
+ **可观测性不完整：**忽略将可观测性纳入工作负载的每一层，造成盲点，从而掩盖重要的系统性能和行为洞察。
+ **支离破碎的数据视图：**当数据分散在多个工具和系统中时，要全面了解工作负载的运行状况和性能，会非常困难。
+ **用户报告的问题：**这表明缺乏通过遥测和业务 KPI 监控来主动发现问题的功能。
**建立此最佳实践的好处：**
+ **明智的决策：**借助从遥测和业务 KPI 中获得的洞察，可以作出以数据驱动型决策。
+ **提高运营效率：**数据驱动的资源利用率可提高成本效益。
+ **增强工作负载稳定性：**更快地检测和解决问题，延长正常运行时间。
+ **简化 CI/CD 流程：**从遥测数据获得的洞察有助于完善流程和可靠地交付代码。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要为工作负载实现应用程序遥测，请使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [AWS X-Ray](https://aws.amazon.com/xray/) 等 AWS 服务。Amazon CloudWatch 提供了一套全面的监控工具，可观察 AWS 和本地环境中的资源和应用程序。该服务会收集、跟踪和分析指标，整合和监控日志数据，并对资源的变化做出响应，从而增进对工作负载运行方式的了解。同时，利用 AWS X-Ray，还可以跟踪、分析和调试应用程序，深入了解工作负载的行为。借助服务地图、延迟分布和跟踪时间表等功能，AWS X-Ray 可让您深入了解工作负载的性能和影响工作负载性能的瓶颈。
### 实施步骤
1. **确定要收集哪些数据：**确定有助于深入了解工作负载运行状况、性能和行为的基本指标、日志和跟踪数据。
1. **部署 [CloudWatch 代理](https://aws.amazon.com/cloudwatch/)：**CloudWatch 代理在从工作负载及其底层基础设施中获取系统和应用程序指标和日志方面发挥重要作用。CloudWatch 代理还可用于收集 OpenTelemetry 或 X-Ray 跟踪数据，并将其发送到 X-Ray。
1. **对日志和指标实施异常检测：**使用 [CloudWatch Logs 异常检测功能](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html)和 [CloudWatch Metrics 异常检测功能](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)来自动识别应用程序操作中的异常活动。这些工具使用机器学习算法来检测异常情况并发出警报，从而增强了监控能力，加快了对潜在中断或安全威胁的响应速度。设置这些功能可主动管理应用程序的运行状况和安全性。
1. **保护敏感日志数据：**使用 [Amazon CloudWatch Logs 数据保护](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html)来掩蔽日志中的敏感信息。此功能会在访问敏感数据之前自动检测和掩蔽敏感数据，有助于维护隐私和合规性。实施数据掩蔽，以期安全地处理和保护个人身份信息（PII）等敏感详细信息。
1. **定义和监控业务 KPI：**建立与[业务结果](https://aws-observability.github.io/observability-best-practices/guides/operational/business/monitoring-for-business-outcomes/)一致的[自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。
1. **使用 AWS X-Ray 检测应用程序：**除了部署 CloudWatch 代理之外，还必须[对应用程序进行检测](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html)，以便发出跟踪数据。此过程可让您进一步了解工作负载的行为和性能。
1. **标准化整个应用程序中的数据收集：**标准化整个应用程序中的数据收集实践。统一性有助于关联和分析数据，从而全面了解应用程序的行为。
1. **实现跨账户可观测性：**借助 [Amazon CloudWatch 跨账户可观测性](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)，提高对多个 AWS 账户 的监控效率。利用该功能，可以将不同账户中的指标、日志和警报整合到一个视图中，从而简化管理，并提高对整个组织的 AWS 环境中已发现问题的响应速度。
1. **分析数据并据此采取行动：**数据收集和标准化完成后，使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 进行指标和日志分析，并使用 [AWS X-Ray](https://aws.amazon.com/xray/features/) 进行跟踪分析。此类分析可得出有关工作负载运行状况、性能和行为的重要洞察，从而指导决策过程。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [OPS04-BP01 定义工作负载 KPI](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS04-BP03 实施用户活动遥测](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_customer_telemetry.html)
+ [OPS04-BP04 实施依赖项遥测](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dependency_telemetry.html)
+ [OPS04-BP05 实施事务可追溯性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dist_trace.html)
**相关文档：**
+ [AWS Observability Best Practices](https://aws-observability.github.io/observability-best-practices/)
+ 《[Amazon CloudWatch 用户指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)》
+ [AWS X-Ray 开发人员指南](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility)
+ [AWS Observability Skill Builder Course](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
+ [Amazon CloudWatch 的新功能](https://aws.amazon.com/about-aws/whats-new/management-and-governance/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23amazon-cloudwatch)
+ [AWS X-Ray 的新功能](https://aws.amazon.com/about-aws/whats-new/developer-tools/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23aws-x-ray)
**相关视频：**
+ [AWS re:Invent 2022 - Observability best practices at Amazon](https://youtu.be/zZPzXEBW4P8)
+ [AWS re:Invent 2022 - Developing an observability strategy](https://youtu.be/Ub3ATriFapQ)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability)
+ [AWS 解决方案库：使用 Amazon CloudWatch 进行应用程序监控](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch)
# OPS04-BP03 实施用户体验遥测
深入了解客户体验以及与应用程序的交互至关重要。真实用户监控（RUM）和综合事务是实现此目的的强大工具。RUM 提供有关真实用户交互的数据，从未经筛选的视角反映用户满意度，而综合事务可模拟用户交互，有助于在潜在问题影响真实用户之前就发现这些问题。
**期望结果：**全面了解客户体验，主动检测问题，优化用户交互，从而提供无缝的数字体验。
**常见反模式：**
+ 应用程序没有真实用户监控（RUM）功能：
+ 问题检测延误：如果没有 RUM，可能要等到用户抱怨时，才会意识到性能瓶颈或问题。这种被动应对的方法可能会导致客户不满。
+ 缺乏对用户体验的了解：不使用 RUM 意味着无法掌握揭示真实用户如何与应用程序交互的关键数据，从而限制优化用户体验的能力。
+ 应用程序没有综合事务功能：
+ 错过边缘案例：综合事务有助于测试普通用户可能不经常使用、但对某些业务职能至关重要的路径和功能。没有综合事务，这些路径可能会出现故障并被忽视。
+ 在未使用应用程序时检查问题：定期的综合测试可以模拟真实用户未积极与应用程序交互时的情况，确保系统始终正常运行。
**建立此最佳实践的好处：**
+ 主动检测问题：在潜在问题影响真实用户之前，发现并解决这些问题。
+ 优化用户体验：来自 RUM 的持续反馈有助于完善和增强整体用户体验。
+ 获得有关设备和浏览器性能的洞察：了解应用程序在各种设备和浏览器上的表现，从而实现进一步优化。
+ 经过验证的业务工作流程：定期的综合事务可确保核心功能和关键路径始终可以使用且高效。
+ 增强应用程序性能：利用从真实用户数据中收集的洞察，提高应用程序的响应能力和可靠性。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
为利用 RUM 和综合事务进行用户活动遥测，AWS 提供了 [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 和 [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 等服务。指标、日志和跟踪数据，再加上用户活动数据，可让您全面了解应用程序的运行状态和用户体验。
### 实施步骤
1. **部署 Amazon CloudWatch RUM：**将应用程序与 CloudWatch RUM 集成，收集、分析和呈现真实的用户数据。
1. 使用 [CloudWatch RUM JavaScript 库](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)，将 RUM 与应用程序集成。
1. 设置控制面板，以可视化形式呈现和监控真实的用户数据。
1. **配置 CloudWatch Synthetics：**创建金丝雀或脚本化例程，模拟用户与应用程序的交互。
1. 定义关键应用程序工作流程和路径。
1. 使用 [CloudWatch Synthetics 脚本](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)设计金丝雀，模拟这些路径的用户交互。
1. 安排和监控金丝雀按指定的间隔运行，确保进行一致的性能检查。
1. **分析数据并据此采取行动：**利用来自 RUM 和综合事务的数据来获取洞察，并在检测到异常时采取纠正措施。使用 CloudWatch 控制面板和警报及时了解情况。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
+ [OPS04-BP04 实施依赖项遥测](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 实施分布式跟踪](ops_observability_dist_trace.md)
**相关文档：**
+ 《[Amazon CloudWatch RUM 指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)》
+ 《[Amazon CloudWatch Synthetics 指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)》
**相关视频：**
+ [Optimize applications through end user insights with Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [AWS on Air ft. Real-User Monitoring for Amazon CloudWatch](https://www.youtube.com/watch?v=r6wFtozsiVE)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US/intro)
+ [适用于 Amazon CloudWatch RUM Web 客户端的 Git 存储库](https://github.com/aws-observability/aws-rum-web)
+ [Using Amazon CloudWatch Synthetics to measure page load time](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)
# OPS04-BP04 实施依赖项遥测
要想监控工作负载所依赖的外部服务和组件的运行状况及性能，依赖项遥测必不可少。依赖项遥测提供有关与 DNS、数据库或第三方 API 等依赖项相关的可访问性、超时及其他关键事件的宝贵洞察。对应用程序进行检测，发布有关这些依赖项的指标、日志和跟踪数据时，能更清楚地了解可能影响工作负载的潜在瓶颈、性能问题或故障。
**期望结果：**确保工作负载所依赖的依赖项按预期执行，让您能够主动解决问题并确保最佳的工作负载性能。
**常见反模式：**
+ **忽略外部依赖项：**仅关注内部应用程序指标，而忽略与外部依赖项相关的指标。
+ **缺乏主动监控：**等待问题出现，而不是持续监控依赖项运行状况和性能。
+ **孤立监控：**使用多种不同的监控工具，这可能会导致依赖项运行状况视图支离破碎且不一致。
**建立此最佳实践的好处：**
+ **提高工作负载可靠性：**通过确保外部依赖项始终可用且性能出色来实现。
+ **更快地检测和解决问题：**在依赖项问题影响工作负载之前，主动发现和解决这些问题。
+ **全面视图：**全面了解影响工作负载运行状况的内部和外部组件。
+ **增强工作负载可扩展性：**通过了解外部依赖项的可扩展性限制和性能特征来实现。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
从确定工作负载所依赖的服务、基础设施和流程开始，实施依赖项遥测。量化这些依赖项按预期运行时的良好状况，然后确定将需要哪些数据来衡量这些状况。利用这些信息，可以创建控制面板和警报，为运营团队提供有关这些依赖项状态的洞察。当依赖项无法按需交付时，使用 AWS 工具来发现和量化影响。不断重新审视策略，考虑优先事项、目标和所获洞察的变化。
### 实施步骤
要有效地实现依赖项遥测，请执行以下操作：
1. **确定外部依赖项：**与利益相关方合作，查明工作负载所依赖的外部依赖项。外部依赖项可包括外部数据库、第三方 API、通往其他环境的网络连接路由以及 DNS 服务等内容。实现有效的依赖项遥测的第一步是全面了解这些依赖项是什么。
1. **制定监控策略：**一旦清楚地了解了外部依赖项，就可以针对它们构建一个量身定制的监控策略。这包括了解每个依赖项的重要程度、其预期行为以及任何相关的服务水平协议或目标（SLA 或 SLT）。设置主动警报，在出现状态变化或性能偏差时发出通知。
1. **使用[网络监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Network-Monitoring-Sections.html)：**使用[网络检测仪](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html)和[网络监视器](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html)，全面了解全球互联网和网络状况。这些工具有助于了解并应对影响外部依赖项的中断、破坏或性能下降。
1. **随时了解 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 的最新信息：**AWS Health 是有关 AWS 云资源运行状况的权威信息来源。使用 AWS Health 可视化并接收有关任何当前服务事件和即将发生的更改（例如计划的生命周期事件）的通知，以便您可以采取措施来减轻影响。
1. 通过 [AWS 用户通知服务](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) 创建要发送到电子邮件和聊天渠道且[契合目标的 AWS Health 事件通知](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)，并通过 Amazon EventBridge 或 [AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) 以编程方式与[监控和警报工具](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)集成。
1. 通过与您可能已经通过 Amazon EventBridge 或 AWS Health API 使用的变更管理或 ITSM 工具（如 [Jira](https://docs.aws.amazon.com/smc/latest/ag/cloud-sys-health.html) 或 [ServiceNow](https://docs.aws.amazon.com/smc/latest/ag/sn-aws-health.html)）集成，规划和跟踪需要采取行动的运行状况事件的进度。
1. 如果您使用 AWS Organizations，请启用 [organization view for AWS Health](https://docs.aws.amazon.com/health/latest/ug/aggregate-events.html) 以跨账户聚合 AWS Health 事件。
1. **使用 [AWS X-Ray](https://aws.amazon.com/xray/) 检测应用程序：**AWS X-Ray 让您能够深入了解应用程序及其底层依赖项的运行情况。通过从头到尾跟踪请求，可以找出应用程序所依赖的外部服务或组件中的瓶颈或故障。
1. **使用 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)：**这项服务由机器学习驱动，可发现操作问题，预测何时可能出现严重问题，并建议可采取的具体行动。其可贵之处在于，可以让您深入了解依赖项，并确保这些依赖项不会成为操作问题的根源。
1. **定期监控：**持续监控与外部依赖项相关的指标和日志。针对意外行为或性能下降设置警报。
1. **更改后进行验证：**每当任何外部依赖项有更新或更改时，都应验证其性能，并检查它们是否符合应用程序的要求。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 定义工作负载 KPI](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS04-BP02 实施应用程序遥测](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_application_telemetry.html)
+ [OPS04-BP03 实施用户活动遥测](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_customer_telemetry.html)
+ [OPS04-BP05 实施事务可追溯性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dist_trace.html)
+ [OP08-BP04 创建可操作的警报](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_workload_observability_create_alerts.html)
**相关文档：**
+ 《[Amazon Personal Health Dashboard User Guide](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)》
+ 《[AWS Internet Monitor User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html)》
+ [AWS X-Ray 开发人员指南](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ 《[AWS DevOps Guru User Guide](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)》
**相关视频：**
+ [Visibility into how internet issues impact app performance](https://www.youtube.com/watch?v=Kuc_SG_aBgQ)
+ [Introduction to Amazon DevOps Guru](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
**相关示例：**
+ [AWS Health Aware](https://github.com/aws-samples/aws-health-aware/)
+ [Using Tag-Based Filtering to Manage AWS Health Monitoring and Alerting at Scale](https://aws.amazon.com/blogs/mt/using-tag-based-filtering-to-manage-health-monitoring-and-alerting-at-scale/)
# OPS04-BP05 实施分布式跟踪
分布式跟踪提供了一种方法，可在请求遍历分布式系统的各个组件时对请求进行监控和可视化。通过从多个来源捕获跟踪数据并在一个统一视图中对其进行分析，团队可以更好地了解请求是如何流动的、哪里存在瓶颈以及优化工作的重点。
**期望结果：**全面了解流经分布式系统的请求，从而精确调试、优化性能和改善用户体验。
**常见反模式：**
+ 检测不一致：并非分布式系统中的所有服务都经过跟踪检测。
+ 忽略延迟：只关注错误，而不考虑延迟或性能逐渐下降的情况。
**建立此最佳实践的好处：**
+ 全面了解系统：以可视化方式呈现请求从进入到退出的整个路径。
+ 增强调试功能：快速发现出现故障或性能问题的地方。
+ 改善用户体验：监控并根据实际用户数据进行优化，确保系统满足现实需求。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
首先确定工作负载中所有需要检测的元素。将所有组件都考虑在内后，利用 AWS X-Ray 和 OpenTelemetry 之类的工具收集跟踪数据，以便使用 X-Ray 和 Amazon CloudWatch ServiceLens Map 等工具进行分析。定期与开发人员一起进行审查，并使用 Amazon DevOps Guru、X-Ray Analytics 和 X-Ray Insights 等工具来补充这些讨论，以便挖掘更深层次的信息。根据跟踪数据确立警报，以便在结果面临风险时，按照工作负载监控计划中定义的流程发出通知。
### 实施步骤
要有效地实施分布式跟踪，请执行以下操作：
1. **采用 [AWS X-Ray](https://aws.amazon.com/xray/)：**将 X-Ray 集成到应用程序中，以便深入了解其行为和性能并查明瓶颈。利用 X-Ray Insights 自动分析跟踪数据。
1. **检测服务：**验证从 [AWS Lambda](https://aws.amazon.com/lambda/) 函数到 [EC2 实例](https://aws.amazon.com/ec2/)的每项服务是否发送了跟踪数据。检测的服务越多，端到端视图就越清晰。
1. **整合 [CloudWatch 真实用户监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)和[综合监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)：**将真实用户监控（RUM）和综合监控与 X-Ray 集成。这可捕捉实际的用户体验并模拟用户交互，从而发现潜在问题。
1. **使用 [CloudWatch 代理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)：**该代理可发送来自 X-Ray 或 OpenTelemetry 的跟踪数据，从而增强所获得洞察的深度。
1. **使用 [Amazon DevOps Guru：](https://aws.amazon.com/devops-guru/)**DevOps Guru 使用来自 X-Ray、CloudWatch、AWS Config 和 AWS CloudTrail 的数据来提供切实可行的建议。
1. **分析跟踪数据：**定期审查跟踪数据，识别可能影响应用程序性能的模式、异常或瓶颈。
1. **设置警报：**在 [CloudWatch](https://aws.amazon.com/cloudwatch/) 中配置针对异常模式或延迟时间过长的警报，从而主动解决问题。
1. **持续改进：**在添加或修改服务时，重新审视跟踪策略，以便捕获所有相关数据点。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
+ [OPS04-BP03 实施用户体验遥测](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 实施依赖项遥测](ops_observability_dependency_telemetry.md)
**相关文档：**
+ 《[AWS X-Ray 开发人员指南](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)》
+ 《[Amazon CloudWatch 代理用户指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)》
+ 《[Amazon DevOps Guru User Guide](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)》
**相关视频：**
+ [Use AWS X-Ray Insights](https://www.youtube.com/watch?v=tl8OWHl6jxw)
+ [AWS on Air ft. Observability: Amazon CloudWatch and AWS X-Ray](https://www.youtube.com/watch?v=qBDBnPkZ-KI)
**相关示例：**
+ [ Instrumenting your application for AWS X-Ray](https://aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html)
# OPS 5. 如何减少缺陷、简化修复和改进生产流程？
采用的方法需能够改进将更改应用于生产环境的流程，激活重构、快速质量反馈和错误修复。这些方法可以加快有益更改进入生产环境的速度、减少产生的问题，并能够快速识别和修复通过部署活动引入的问题。
**Topics**
+ [
# OPS05-BP01 使用版本控制
](ops_dev_integ_version_control.md)
+ [
# OPS05-BP02 测试并验证更改
](ops_dev_integ_test_val_chg.md)
+ [
# OPS05-BP03 使用配置管理系统
](ops_dev_integ_conf_mgmt_sys.md)
+ [
# OPS05-BP04 使用构建和部署管理系统
](ops_dev_integ_build_mgmt_sys.md)
+ [
# OPS05-BP05 执行补丁管理
](ops_dev_integ_patch_mgmt.md)
+ [
# OPS05-BP06 共享设计标准
](ops_dev_integ_share_design_stds.md)
+ [
# OPS05-BP07 实施提高代码质量的实践
](ops_dev_integ_code_quality.md)
+ [
# OPS05-BP08 使用多个环境
](ops_dev_integ_multi_env.md)
+ [
# OPS05-BP09 频繁进行可逆的小规模更改
](ops_dev_integ_freq_sm_rev_chg.md)
+ [
# OPS05-BP10 完全自动化集成和部署
](ops_dev_integ_auto_integ_deploy.md)
# OPS05-BP01 使用版本控制
使用版本控制来跟踪更改和发布。
许多 AWS 服务都提供版本控制功能。使用 [Git](https://aws.amazon.com/devops/source-control/git/) 等修订或[源代码控制](https://aws.amazon.com/devops/source-control/)系统来管理代码和其它构件，例如基础设施的版本受控的 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 模板。
**期望结果：**团队协作编写代码。合并后，代码将保持一致，并且不会丢失任何更改。通过正确的版本控制，可以很容易纠正错误。
**常见反模式：**
+ 您一直在工作站上开发和存储代码。工作站上发生了不可恢复的存储故障，代码丢失了。
+ 用更改内容覆盖现有代码后，重新启动应用程序，但其无法运行。您无法撤销所做更改。
+ 您对报告文件执行了写入锁定，而其他人需要对此文件进行编辑。他们与您联系要求停止写入锁定，以便他们可以完成自己的任务。
+ 研究团队一直在进行详细的分析，以便对未来的工作进行规划。有人不小心把购物单保存在最终报告上了。您无法撤销更改，不得不重新创建报告。
**建立此最佳实践的好处：**借助版本控制功能，可以轻松地恢复到已知的良好状态和以前的版本，并降低资产丢失的风险。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
在版本受控的存储库中维护资产。这让您能够跟踪更改、部署新版本、检测对现有版本的更改，以及恢复到以前的版本（例如在发生故障时回滚到已知的良好状态）。将配置管理系统的版本控制功能集成到程序中。
## 资源
**相关最佳实践：**
+ [OPS05-BP04 使用构建和部署管理系统](ops_dev_integ_build_mgmt_sys.md)
**相关视频：**
+ [AWS re:Invent 2023 - How Lockheed Martin builds software faster, powered by DevSecOps ](https://www.youtube.com/watch?v=Q1OSyxYkl5w)
+ [AWS re:Invent 2023 - How GitHub operationalizes AI for team collaboration and productivity ](https://www.youtube.com/watch?v=cOVvGaiusOI)
# OPS05-BP02 测试并验证更改
部署的每一项更改都必须经过测试，避免在生产中出现错误。此最佳实践的重点是测试从版本控制到构件构建的更改。除应用程序代码更改外，测试还应该包括基础设施、配置、安全控制和操作程序。测试有多种形式，从单元测试到软件组件分析（SCA）等等。在软件集成和交付过程中，尽早进行测试可进一步确保构件质量。
组织必须为所有的软件构件制定测试标准。自动化测试可以减少工作量，并避免人工测试的错误。但有些情况下，可能必须进行手动测试。开发人员必须能够访问自动化测试结果，以便创建反馈环路，提高软件质量。
**期望结果：**软件更改在交付前经过测试。开发人员可以访问测试结果和验证结果。组织制定了适用于所有软件更改的测试标准。
**常见反模式：**
+ 在没有进行任何测试的情况下部署一项新软件更改。它无法在生产环境中运行，从而导致中断。
+ 使用 AWS CloudFormation 部署新安全组，而没有在预生产环境中进行测试。这些安全组导致客户无法访问应用程序。
+ 修改了一个方法，但没有进行单元测试。该软件在部署到生产环境中后无法运行。
**建立此最佳实践的好处：**降低了软件部署更改的失败率。软件质量得到改进。开发人员提高了对其代码可行性的认识。可以放心地推出安全策略，支持组织实现合规性。可以提前测试自动扩缩策略更新等基础设施更改，从而满足流量需求。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
作为持续集成实践的一部分，对从应用程序代码到基础设施的所有更改都进行测试。将公布测试结果，以便开发人员快速提供反馈。组织制定了测试标准，所有更改都必须通过该标准。
利用 Amazon Q 开发者版的生成式人工智能的强大功能，提高开发人员的生产力和代码质量。Amazon Q 开发者版包括生成代码建议（基于大型语言模型）、制作单元测试（包括边界条件），以及通过检测和修复安全漏洞来增强代码安全性。
**客户示例**
作为持续集成管道的一部分，AnyCompany Retail 对所有软件构件进行几种类型的测试。他们实行测试驱动型开发，因此所有软件都要进行单元测试。构件构建完毕后，他们会立即运行端到端测试。第一轮测试完成后，他们会运行静态应用程序安全扫描，寻找已知漏洞。在每个测试关口通过时，开发人员都会收到消息。所有测试均完成后，软件构件就会存储在构件库中。
### 实施步骤
1. 与组织中的利益相关方合作，为软件构件制定测试标准。所有构件均应通过哪些标准测试？ 测试范围内是否必须包含合规性或治理要求？ 是否需要进行代码质量测试？ 测试完成后，需要通知谁？
1. [AWS 部署管道参考架构](https://pipelines.devops.aws.dev/)包含一个权威的测试类型列表，可作为集成管道的一部分对软件构件执行这些测试。
1. 根据软件测试标准，利用必要的测试来检测应用程序。每组测试应在 10 分钟内完成。测试应该作为集成管道的一部分运行。
1. 使用 [Amazon Q 开发者版](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)，这是一款生成式人工智能工具，可以帮助创建单元测试案例（包括边界条件）、使用代码和注释生成函数以及实现已知算法。
1. 使用 [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 来测试应用程序代码是否存在缺陷。
1. 使用 [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 对软件构件执行测试。
1. [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 可以将软件测试编排到管道中。
## 资源
**相关最佳实践：**
+ [OPS05-BP01 使用版本控制](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_version_control.html)
+ [OPS05-BP06 共享设计标准](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html)
+ [OPS05-BP07 实施提高代码质量的实践](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_code_quality.html)
+ [OPS05-BP10 完全自动化集成和部署](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_auto_integ_deploy.html)
**相关文档：**
+ [采用测试驱动型开发方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [Accelerate your Software Development Lifecycle with Amazon Q](https://aws.amazon.com/blogs/devops/accelerate-your-software-development-lifecycle-with-amazon-q/)
+ [Amazon Q Developer, now generally available, includes previews of new capabilities to reimagine developer experience](https://aws.amazon.com/blogs/aws/amazon-q-developer-now-generally-available-includes-new-capabilities-to-reimagine-developer-experience/)
+ [The Ultimate Cheat Sheet for Using Amazon Q Developer in Your IDE](https://community.aws/content/2eYoqeFRqaVnk900emsknDfzhfW/the-ultimate-cheat-sheet-for-using-amazon-q-developer-in-your-ide)
+ [Shift-Left Workload, leveraging AI for Test Creation](https://community.aws/content/2gBZtC94gPzaCQRnt4P0rIYWuBx/shift-left-workload-leveraging-ai-for-test-creation)
+ [Amazon Q 开发人员中心](https://aws.amazon.com/developer/generative-ai/amazon-q/)
+ [10 ways to build applications faster with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/10-ways-to-build-applications-faster-with-amazon-codewhisperer/)
+ [Looking beyond code coverage with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/looking-beyond-code-coverage-with-amazon-codewhisperer/)
+ [Best Practices for Prompt Engineering with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/best-practices-for-prompt-engineering-with-amazon-codewhisperer/)
+ [Automated AWS CloudFormation Testing Pipeline with TaskCat and CodePipeline](https://aws.amazon.com/blogs/devops/automated-cloudformation-testing-pipeline-with-taskcat-and-codepipeline/)
+ [Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST, and DAST tools](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
+ [Getting started with testing serverless applications](https://aws.amazon.com/blogs/compute/getting-started-with-testing-serverless-applications/)
+ [My CI/CD pipeline is my release captain](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ 《[在 AWS 上练习持续集成和持续交付白皮书](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)》
**相关视频：**
+ [Implement an API with Amazon Q Developer Agent for Software Development](https://www.youtube.com/watch?v=U4XEvJUvff4)
+ [Installing, Configuring, & Using Amazon Q Developer with JetBrains IDEs (How-to)](https://www.youtube.com/watch?v=-iQfIhTA4J0)
+ [Mastering the art of Amazon CodeWhisperer - YouTube playlist](https://www.youtube.com/playlist?list=PLDqi6CuDzubxzL-yIqgQb9UbbceYdKhpK)
+ [AWS re:Invent 2020: Testable infrastructure: Integration testing on AWS](https://www.youtube.com/watch?v=KJC380Juo2w)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development](https://www.youtube.com/watch?v=1R7G_wcyd3s)
+ [Testing Your Infrastructure as Code with AWS CDK](https://www.youtube.com/watch?v=fWtuwGSoSOU)
**相关资源：**
+ [AWS Deployment Pipeline Reference Architecture - Application](https://pipelines.devops.aws.dev/application-pipeline/index.html)
+ [AWS Kubernetes DevSecOps 管道](https://github.com/aws-samples/devsecops-cicd-containers)
+ [Run unit tests for a Node.js application from GitHub by using AWS CodeBuild](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html)
+ [Use Serverspec for test-driven development of infrastructure code](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/use-serverspec-for-test-driven-development-of-infrastructure-code.html)
**相关服务：**
+ [Amazon Q 开发者版](https://aws.amazon.com/q/developer/)
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# OPS05-BP03 使用配置管理系统
使用配置管理系统来实现和跟踪配置更改。这些系统可以减少手动过程引起的错误，并减少部署更改的工作量。
静态配置管理在初始化资源时设置值，这些值预计在资源的生命周期内会保持一致。动态配置管理在初始化时设置值，这些值在资源的生命周期内可能或预计会发生变化。例如，可以设置功能切换，通过配置更改来激活代码中的功能，或者在意外事件发生期间更改日志详细信息级别。
配置应在已知且一致的状态下部署。应该使用自动化检查功能来持续监控跨环境和区域的资源配置。这些控制措施应定义为自动化代码和管理，从而确保在各个环境中始终如一地应用规则。配置更改应通过商定的更改控制程序进行更新，并一致地应用，从而遵守版本控制。应用程序配置应独立于应用程序和基础设施代码进行管理。这可实现在多个环境中进行一致的部署。配置更改不会导致重建或重新部署应用程序。
**期望结果：**可以作为持续集成、持续交付（CI/CD）管道的一部分进行配置、验证和部署。通过监控来验证配置是否正确。这样可以最大限度地减少对终端用户和客户的任何影响。
**常见反模式：**
+ 手动更新整个实例集中的 Web 服务器配置，由于更新错误，许多服务器变得没有响应。
+ 手动更新应用程序服务器实例集需要花费很长时间。在更改过程中，如果配置不一致会导致意外行为发生。
+ 有人更新了安全组，Web 服务器变得无法访问。如果不知道进行了哪些更改，就需要花费大量时间来调查问题，导致恢复时间延长。
+ 未经验证即通过 CI/CD 将预生产配置推送到生产环境中。让用户和客户接触到不正确的数据和服务。
**建立此最佳实践的好处：**采用配置管理系统可以减少更改及对其进行跟踪的工作量，还可以降低手动程序导致错误的频率。配置管理系统为治理、合规性和监管要求提供了保障。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
配置管理系统用于跟踪和实施对应用程序和环境配置的更改。配置管理系统还用于减少手动流程导致的错误，让配置更改可重复且可审核，并减少工作量。
在 AWS 上，可以使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 持续监控[跨账户和区域](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html)的 AWS 资源配置。这有助于跟踪其配置历史记录，了解配置更改会如何影响其他资源，并使用 [AWS Config 规则](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 和 [AWS Config 合规包](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)根据预期或期望的配置对其进行审查。
对于在 Amazon EC2 实例、AWS Lambda、容器、移动应用程序或 IoT 设备上运行的应用程序中的动态配置，可以使用 [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 在各环境中对其进行配置、验证、部署和监控。
### 实施步骤
1. 确定配置负责人。
1. 让配置负责人了解任何合规性、治理或监管需求。
1. 确定配置项和可交付成果。
1. 配置项是受 CI/CD 管道内的部署影响的所有应用程序和环境配置。
1. 可交付成果包括成功标准、验证和要监控的内容。
1. 根据业务要求和交付管道，选择配置管理工具。
1. 考虑使用加权部署，例如用于重大配置更改的金丝雀部署，以便尽可能减少错误配置的影响。
1. 将配置管理集成到 CI/CD 管道中。
1. 验证推送的所有更改。
## 资源
**相关最佳实践：**
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 测试部署](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 采用安全部署策略](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS 登录区加速器](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [什么是 AWS Config？](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [什么是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+ [AWS CodePipeline](https://aws.amazon.com/codepipeline/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
**相关视频：**
+ [AWS re:Invent 2022 - Proactive governance and compliance for AWS workloads](https://youtu.be/PpUnH9Y52X0?si=82wff87KHXcc6nbT)
+ [AWS re:Invent 2020: Achieve compliance as code using AWS Config](https://youtu.be/m8vTwvbzOfw?si=my4DP0FLq1zwKjho)
+ [Manage and Deploy Application Configurations with AWS AppConfig](https://youtu.be/ztIxMY3IIu0?si=ovYGsxWOBysyQrg0)
# OPS05-BP04 使用构建和部署管理系统
使用构建和部署管理系统。这些系统可以减少手动过程引起的错误，并减少部署更改的工作量。
在 AWS 中，您可以使用 [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/)（例如 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、[AWS CodePipeline](https://aws.amazon.com/codepipeline/) 和 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)）等服务，来构建持续集成/持续部署（CI/CD）管道。
**期望结果：**构建和部署管理系统支持组织的持续集成/持续交付（CI/CD）系统，该系统提供使用正确配置自动进行安全部署的功能。
**常见反模式：**
+ 在开发系统上编译代码后，将可执行文件复制到生产系统中，但它无法启动。本地日志文件显示这是因为缺少依赖项所致。
+ 成功在开发环境中构建了具有新功能的应用程序，并将代码送交质量检查（QA）。由于缺少静态资产，它没有通过质量检查。
+ 星期五，经过大量的努力，成功地在开发环境中手动构建了应用程序，包括新编码的功能。星期一，无法重复支持成功构建应用程序的步骤。
+ 执行为新版本创建的测试。花费了接下来一周的时间来设置测试环境，并执行所有现有的集成测试，然后执行性能测试。新代码产生了难以接受的性能影响，因此必须重新开发并测试。
**建立此最佳实践的好处：**制定相应机制来管理活动的构建和部署。这样，可以减少执行重复任务的工作量，让团队成员腾出时间专注于高价值的创造性任务，还可以减少手动程序导致的错误。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
构建和部署管理系统用于跟踪和实施变更，减少手动流程导致的错误，并减少安全部署所需的工作量。将集成和部署管道完全自动化，从代码签入到构建、测试、部署和验证都包含在内。这可以缩短准备时间，降低成本，鼓励更频繁地进行更改，减少工作量并增进协作。
### 实施步骤
![\[图中显示了使用 AWS CodePipeline 和相关服务的 CI/CD 管道\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-pipeline-tooling.png)
1. 使用版本控制系统来存储和管理资产（例如文档、源代码和二进制文件）。
1. 使用 CodeBuild 来编译源代码，运行单元测试，并生成可供部署的构件。
1. 使用 CodeDeploy 作为部署服务，可以自动将应用程序部署到 [Amazon EC2](https://aws.amazon.com/ec2/) 实例、本地实例、[无服务器 AWS Lambda 函数](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)或 [Amazon ECS](https://aws.amazon.com/ecs/)。
1. 监控部署。
## 资源
**相关最佳实践：**
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/)
+ [什么是 AWS CodeBuild ？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+ [什么是 AWS CodeDeploy ？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**相关视频：**
+ [AWS re:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)
# OPS05-BP05 执行补丁管理
执行补丁管理以便实现功能、解决问题并保持监管合规性。实现自动补丁管理，减少手动流程导致的错误，进行扩展，并减少修补工作量。
补丁和漏洞管理是益处与风险管理活动的一部分。最好是具有不可变的基础设施并在经验证的已知良好状态下部署工作负载。如果该方法不可行，那就只能进行修补。
[AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 是有关计划的生命周期事件以及其它影响 AWS 云 资源运行状况而需采取措施的事件的权威信息来源。您应该知道即将进行的更改和应执行的更新。计划的重大生命周期事件至少提前六个月发送。
[Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) 提供了更新机器映像的管道。作为补丁管理的一部分，可以考虑使用 [AMI 映像管道](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)的[亚马逊机器映像（AMI）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html )或带有 [Docker 映像管道](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)的容器映像，而 AWS Lambda 提供适用于[自定义运行时和其他库](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html)的模式用来消除漏洞。
应使用 [Amazon EC2 Image Builder](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) 管理适用于 Linux 或 Windows Server 映像的[亚马逊机器映像（AMI）](https://aws.amazon.com/image-builder/)的更新。可以结合使用 [Amazon Elastic Container Registry（Amazon ECR）](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)和现有管道来管理 Amazon ECS 映像和 Amazon EKS 映像。Lambda 包含[版本管理功能](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)。
在未事先在安全环境中测试的情况下，不应对生产系统执行修补操作。仅当补丁支持运营或业务成果时，才应该应用补丁。在 AWS 上，可以使用 [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 自动完成托管系统的修补过程，并使用 [Systems Manager 维护时段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)安排活动。
**期望结果：**AMI 和容器映像经过修补、处于最新状态，随时可以启动。可以跟踪所有已部署映像的状态，并了解补丁合规性。可以报告当前状态，并制定流程来满足合规性需求。
**常见反模式：**
+ 您接到任务，需要在两个小时内应用所有新的安全补丁，但由于应用程序与补丁不兼容，导致了多次停机。
+ 没有安装补丁的库会引发意外后果，这是因为未知方会利用其中的漏洞来访问工作负载。
+ 在未通知开发人员的情况下自动修补开发人员环境。收到来自开发人员的多起投诉，称他们的环境不能按预期运行。
+ 尚未修补持久性实例上的现有商用软件。遇到软件问题并与供应商联系时，他们告知已不再为该版本提供支持，您必须安装特定级别的补丁才能获得帮助。
+ 您使用的加密软件最近发布了新补丁，对性能进行了重大改进。未安装补丁的系统仍然存在性能问题，恰恰是因为没有安装补丁造成的。
+ 您收到通知，告知存在零日漏洞，需要紧急修复，而您不得不手动为所有环境打补丁。
+ 您不知道维护资源所需的关键操作，例如强制版本更新，因为您未查看即将发生的计划生命周期事件和其它信息。您错失了计划和执行的关键时间，导致团队发生紧急变化，并可能造成影响或意外停机。
**建立此最佳实践的好处：**通过建立补丁管理流程，包括修补标准以及在环境中分发补丁的方法，可以进行扩展和报告补丁级别。这为安全补丁提供了保障，并确保清楚地了解已知修复的状态。这会促进采用所需特性和功能、快速解决问题并保持监管合规性。实施补丁管理系统和自动化，可减少部署补丁的工作量，并减少手动流程导致的错误。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
修补系统以便纠正问题、获得所需的特性或功能、符合监管政策并满足供应商支持需求。在不可变系统中，使用适当的补丁集进行部署，以便实现所需结果。自动执行补丁管理机制以便缩短修补时间、避免手动流程导致的错误，并减少修补工作量。
### 实施步骤
对于 Amazon EC2 Image Builder：
1. 使用 Amazon EC2 Image Builder，指定管道详细信息：
1. 创建映像管道并为其命名
1. 定义管道计划和时区
1. 配置任何依赖项
1. 选择方案：
1. 选择现有方案或创建新方案
1. 选择映像类型
1. 为方案命名并确定其版本
1. 选择基础映像
1. 添加构建组件并添加到目标注册表
1. 可选 – 定义基础设施配置。
1. 可选 – 定义配置设置。
1. 查看设置。
1. 定期检查方案，保持方案正常发挥作用。
对于 Systems Manager Patch Manager：
1. 创建补丁基准。
1. 选择补丁操作方法。
1. 启用合规性报告和扫描。
## 资源
**相关最佳实践：**
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [What is Amazon EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)
+ [Create an image pipeline using the Amazon EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)
+ [Create a container image pipeline](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [使用 Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-console.html)
+ [使用补丁合规性报告](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-compliance-reports.html)
+ [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools)
**相关视频：**
+ [CI/CD for Serverless Applications on AWS](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [Design with Ops in Mind](https://youtu.be/uh19jfW7hw4)
**相关示例：**
+ [AWS Systems Manager Patch Manager 教程](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-tutorials.html)
# OPS05-BP06 共享设计标准
在不同团队间共享最佳实践，以便提高认识并最大程度地实现开发工作的效益。随着架构的发展，记录最佳实践并使其保持最新。如果在组织中强制实施了共享标准，则必须制定相应的机制来请求对标准进行添加、更改和例外处理。如果没有这样的机制，标准将成为创新的约束。
**期望结果：**在组织中的不同团队间共享设计标准。随着最佳实践的发展，记录标准并使其保持最新。
**常见反模式：**
+ 两个开发团队各自创建了一个用户身份验证服务。对于用户来说，他们想要访问系统的每一部分，都必须使用一套单独的凭据。
+ 每个团队管理他们自己的基础设施。新的合规性要求迫使您更改基础设施，各个团队以不同的方式实施更改。
**建立此最佳实践的好处：**使用共享标准支持最佳实践的采用，并充分实现开发工作的效益。记录和更新设计标准，让组织可以了解最新的最佳实践以及安全和合规性要求。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
在不同团队间共享现有的最佳实践、设计标准、检查清单、操作程序、指南和监管要求。建立针对设计标准的更改、添加和例外请求程序，以便支持改进和创新。让团队了解已发布的内容。随着新最佳实践的出现，制定一种机制来让设计标准保持最新。
**客户示例**
AnyCompany Retail 拥有负责创建软件架构模式的跨职能架构团队。此团队构建具有内置合规性和治理的架构。采用这些共享标准的团队可以从内置合规性和治理中受益。他们可以在设计标准的基础上快速构建。架构团队每季度召开一次会议，评估架构模式，如有必要，更新架构模式。
### 实施步骤
1. 组建一个跨职能团队，负责开发和更新设计标准。此团队应与整个组织的利益相关方合作，制定设计标准、操作程序、检查清单、指南和治理要求。记录设计标准并在组织内共享。
1. [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) 可用于使用基础设施即代码创建代表设计标准的产品组合。可以在不同账户间共享产品组合。
1. 随着新最佳实践的确定，制定一种机制来让设计标准保持最新。
1. 如果集中执行设计标准，则制定一个流程来请求更改、更新和豁免。
**实施计划的工作量级别：**中。制定一个流程来创建和共享设计标准，就可以与整个组织的利益相关方进行协调与合作。
## 资源
**相关最佳实践：**
+ [OPS01-BP03 评估治理要求](ops_priorities_governance_reqs.md) – 治理要求会影响设计标准。
+ [OPS01-BP04 评估合规性要求](ops_priorities_compliance_reqs.md) – 在创建设计标准时，合规性是一项至关重要的输入。
+ [OPS07-BP02 确保以一致的方式对运营准备情况进行审查](ops_ready_to_support_const_orr.md) – 运营准备检查清单是一种在设计工作负载时实施设计标准的机制。
+ [OPS11-BP01 设置持续改进流程](ops_evolve_ops_process_cont_imp.md) – 更新设计标准是持续改进的一部分。
+ [OPS11-BP04 执行知识管理](ops_evolve_ops_knowledge_management.md) – 在知识管理实践过程中，记录和共享设计标准。
**相关文档：**
+ [Automate AWS Backups with AWS Service Catalog](https://aws.amazon.com/blogs/mt/automate-aws-backups-with-aws-service-catalog/)
+ [AWS Service Catalog Account Factory-Enhanced](https://aws.amazon.com/blogs/mt/aws-service-catalog-account-factory-enhanced/)
+ [How Expedia Group built Database as a Service (DBaaS) offering using AWS Service Catalog](https://aws.amazon.com/blogs/mt/how-expedia-group-built-database-as-a-service-dbaas-offering-using-aws-service-catalog/)
+ [Maintain visibility over the use of cloud architecture patterns](https://aws.amazon.com/blogs/architecture/maintain-visibility-over-the-use-of-cloud-architecture-patterns/)
+ [Simplify sharing your AWS Service Catalog portfolios in an AWS Organizations setup](https://aws.amazon.com/blogs/mt/simplify-sharing-your-aws-service-catalog-portfolios-in-an-aws-organizations-setup/)
**相关视频：**
+ [AWS Service Catalog – Getting Started](https://www.youtube.com/watch?v=A9kKy6WhqVA)
+ [AWS re:Invent 2020: Manage your AWS Service Catalog portfolios like an expert](https://www.youtube.com/watch?v=lVfXkWHAtR8)
**相关示例：**
+ [AWS Service Catalog Reference Architecture](https://github.com/aws-samples/aws-service-catalog-reference-architectures)
+ [AWS Service Catalog 讲习会](https://catalog.us-east-1.prod.workshops.aws/workshops/d40750d7-a330-49be-9945-cde864610de9/en-US)
**相关服务：**
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)
# OPS05-BP07 实施提高代码质量的实践
实施能够提高代码质量并尽可能减少缺陷的最佳实践。一些示例包括测试驱动型开发、代码审查、标准采用和结对编程。将这些实践合并到持续集成和交付流程中。
**期望结果：**组织使用代码审查或结对编程等最佳实践来提高代码质量。在软件开发生命周期内，开发人员和操作人员采用代码质量最佳实践。
**常见反模式：**
+ 在没有进行代码审查的情况下将代码提交到应用程序的主分支。更改会自动部署到生产环境并导致中断。
+ 开发新应用程序，而不进行任何单元测试、端到端测试或集成测试。在部署之前无法测试应用程序。
+ 团队在生产中进行手动更改来解决缺陷问题。更改没有经过测试或代码审查，也不会通过持续集成和交付流程得到捕获或记录。
**建立此最佳实践的好处：**通过采用提高代码质量的实践，能够帮助最大限度地减少引入生产中的问题。代码质量最佳实践包括结对编程、代码审查和实施人工智能生产力工具等。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
实施提高代码质量的实践，以便在部署代码之前尽可能减少缺陷。使用测试驱动型开发、代码审查和结对编程等实践来提高开发的质量。
利用 Amazon Q 开发者版的生成式人工智能的强大功能，提高开发人员的生产力和代码质量。Amazon Q 开发者版包括生成代码建议（基于大型语言模型）、制作单元测试（包括边界条件），以及通过检测和修复安全漏洞来增强代码安全性。
**客户示例**
AnyCompany Retail 采用几种实践来提高代码质量。他们采用了测试驱动型开发作为编写应用程序的标准。对于一些新功能，他们让开发人员在冲刺阶段结对编程。在集成和部署之前，由高级开发人员对每个拉取请求进行代码审查。
### 实施步骤
1. 在持续集成和交付流程中采用测试驱动型开发、代码审查和结对编程等代码质量实践。使用这些技术来提高软件质量。
1. 使用 [Amazon Q 开发者版](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)，这是一款生成式人工智能工具，可以帮助创建单元测试案例（包括边界条件）、使用代码和注释生成函数、实现已知算法、检测代码中的安全策略违规行为和漏洞、检测机密、扫描基础设施即代码（IaC）、记录代码以及更快地学习第三方代码库。
1. [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 可以使用机器学习为 Java 和 Python 代码提供编程建议。
**实施计划的工作量级别：**中。实施此最佳实践有很多方法，但获得组织采用可能并非易事。
## 资源
**相关最佳实践：**
+ [OPS05-BP02 测试并验证更改](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_test_val_chg.html)
+ [OPS05-BP06 共享设计标准](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html)
**相关文档：**
+ [采用测试驱动型开发方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [Accelerate your Software Development Lifecycle with Amazon Q](https://aws.amazon.com/blogs/devops/accelerate-your-software-development-lifecycle-with-amazon-q/)
+ [Amazon Q Developer, now generally available, includes previews of new capabilities to reimagine developer experience](https://aws.amazon.com/blogs/aws/amazon-q-developer-now-generally-available-includes-new-capabilities-to-reimagine-developer-experience/)
+ [The Ultimate Cheat Sheet for Using Amazon Q Developer in Your IDE](https://community.aws/content/2eYoqeFRqaVnk900emsknDfzhfW/the-ultimate-cheat-sheet-for-using-amazon-q-developer-in-your-ide)
+ [Shift-Left Workload, leveraging AI for Test Creation](https://community.aws/content/2gBZtC94gPzaCQRnt4P0rIYWuBx/shift-left-workload-leveraging-ai-for-test-creation)
+ [Amazon Q 开发人员中心](https://aws.amazon.com/developer/generative-ai/amazon-q/)
+ [10 ways to build applications faster with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/10-ways-to-build-applications-faster-with-amazon-codewhisperer/)
+ [Looking beyond code coverage with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/looking-beyond-code-coverage-with-amazon-codewhisperer/)
+ [Best Practices for Prompt Engineering with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/best-practices-for-prompt-engineering-with-amazon-codewhisperer/)
+ 《[Agile Software Guide](https://martinfowler.com/agile.html)》
+ [My CI/CD pipeline is my release captain](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [Automate code reviews with Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [采用测试驱动型开发方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [How DevFactory builds better applications with Amazon CodeGuru](https://aws.amazon.com/blogs/machine-learning/how-devfactory-builds-better-applications-with-amazon-codeguru/)
+ [On Pair Programming](https://martinfowler.com/articles/on-pair-programming.html)
+ [RENGA Inc. automates code reviews with Amazon CodeGuru](https://aws.amazon.com/blogs/machine-learning/renga-inc-automates-code-reviews-with-amazon-codeguru/)
+ [The Art of Agile Development: Test-Driven Development](http://www.jamesshore.com/v2/books/aoad1/test_driven_development)
+ [Why code reviews matter (and actually save time\$1)](https://www.atlassian.com/agile/software-development/code-reviews)
**相关视频：**
+ [Implement an API with Amazon Q Developer Agent for Software Development](https://www.youtube.com/watch?v=U4XEvJUvff4)
+ [Installing, Configuring, & Using Amazon Q Developer with JetBrains IDEs (How-to)](https://www.youtube.com/watch?v=-iQfIhTA4J0)
+ [Mastering the art of Amazon CodeWhisperer - YouTube playlist](https://www.youtube.com/playlist?list=PLDqi6CuDzubxzL-yIqgQb9UbbceYdKhpK)
+ [AWS re:Invent 2020: Continuous improvement of code quality with Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development](https://www.youtube.com/watch?v=1R7G_wcyd3s)
**相关服务：**
+ [Amazon Q 开发者版](https://aws.amazon.com/q/developer/)
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
# OPS05-BP08 使用多个环境
使用多个环境来试验、开发和测试工作负载。当环境接近于生产环境时，逐步加强控制，确保工作负载在部署后能够按预期运行。
**期望结果：**您有多个环境，这些环境均反映合规性和治理需求。在通往生产的道路上，可以通过环境来测试和推广代码。
1. 组织可通过建立登录区来实现这一目标，登录区可提供治理、控制、账户自动化、联网、安全性和运营可观测性。通过使用多个环境来管理这些登录区功能。一个常见的例子是沙盒组织，用于开发和测试对基于 [AWS Control Tower](https://aws.amazon.com/controltower/) 的登录区的更改，其中包括 [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 和 [service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 等策略。所有这些因素都会对登录区内 AWS 账户的访问和操作产生重大影响。
1. 除了这些服务外，您的团队还可通过 AWS 和 AWS 合作伙伴发布的解决方案，或作为组织内部开发的自定义解决方案，来扩展登录区的功能。AWS 发布的解决方案示例包括 [AWS Control Tower 的自定义选项（CfCT）](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/)和 [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)。
1. 您的组织对登录区的测试、推广代码和策略变更采用相同的原则，贯穿通往生产之路的各个环境。该策略为您的应用程序和工作负载团队提供了一个稳定且安全的登录区环境。
**常见反模式：**
+ 您正在共享开发环境中执行开发，另一位开发人员将覆盖您的代码更改。
+ 对共享开发环境严苛的安全控制导致您无法试验新的服务和功能。
+ 对生产系统执行负载测试，导致用户停机。
+ 生产中发生了严重错误，导致数据丢失。在生产环境中，尝试重新创建导致数据丢失的条件，以便能够确定它是如何发生的，并防止它再次发生。为了防止在测试期间再次丢失数据，您被迫采取措施，导致用户无法使用应用程序。
+ 您正在运行多租户服务，无法支持客户对专用环境的请求。
+ 您可能并不总是进行测试，但在需要测试时，您在生产环境中进行。
+ 您认为单一环境的简单性比更改在环境中的影响范围更加重要。
+ 您升级了一项关键的登录区功能，但此项更改会削弱您的团队为新项目或现有工作负载销售账户的能力。
+ 您对 AWS 账户应用了新的控制，但此项更改会影响工作负载团队在其 AWS 账户内部署更改的能力。
**建立此最佳实践的好处：**当您部署多个环境时，可以为多个同时进行的开发、测试和生产环境提供支持，而不会在开发人员或用户社区间造成冲突。对于诸如登录区之类的复杂功能，它可以显著降低变更风险，简化改进过程，并降低对环境进行关键更新的风险。使用登录区的组织自然会因其 AWS 环境中的多个账户而受益，包括账户结构、治理、网络和安全配置。随着时间推移，组织不断成长，登录区可以不断发展，以保护和组织您的工作负载和资源。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
使用多个环境，为开发人员提供控制机制最少的沙盒环境，协助进行试验。提供单独的开发环境来协助并行工作，并提高开发的敏捷性。在接近生产的环境中实施更严格的控制，让开发人员能够创新。使用基础设施即代码和配置管理系统来部署与生产环境中的控制机制配置一致的环境，确保系统在部署后按照预期运行。关闭不使用的环境，以免空闲资源（例如，晚上和周末的开发系统）产生费用。在负载测试时部署与生产等效的环境，以改善有效结果。
诸如平台工程、网络和安全运营等团队通常在组织层面管理可满足不同要求的功能。单靠分离账户不足以为实验、开发和测试提供和维护单独的环境。在此类情况下，请创建单独的 AWS Organizations 实例。
## 资源
**相关文档：**
+ [AWS 实例调度器](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
+ [什么是 AWS CloudFormation ？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [ Organizing Your AWS Environment Using Multiple Accounts - Multiple organizations - Test changes to your overall AWS environment ](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/multiple-organizations.html#test-changes-to-your-overall-aws-environment)
+ [AWS Control Tower Guide ](https://catalog.workshops.aws/control-tower)
# OPS05-BP09 频繁进行可逆的小规模更改
频繁进行可逆的小规模更改可以减少更改的范围和影响。当与变更管理系统、配置管理系统以及构建和交付系统结合使用时，频繁进行可逆的小规模更改可以减少更改的范围和影响。这样可以提高故障排除工作的效率、加快修复速度，并支持回滚更改。
**常见反模式：**
+ 每季度部署一个新版本的应用程序，这会存在一个变更窗口，意味着核心服务将关闭。
+ 经常更改数据库架构，而不跟踪管理系统中的更改。
+ 执行手动就地更新，覆盖现有安装和配置，并且没有明确的回滚计划。
**建立此最佳实践的好处：**通过频繁部署小更改，可以加快开发速度。更改很小时，更易于确定是否会带来意外后果，并且更容易撤回。更改可逆时，由于简化了恢复过程，因此实施更改的风险更小。更改过程的风险降低，更改失败的影响也减小。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
频繁进行可逆的小规模更改可以减小更改的范围和影响。这可以简化故障排除、加快修复速度，并支持回滚更改。这还可以加快实现业务价值。
## 资源
**相关最佳实践：**
+ [OPS05-BP03 使用配置管理系统](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 使用构建和部署管理系统](ops_dev_integ_build_mgmt_sys.md)
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [Microservices - Observability](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/observability.html)
# OPS05-BP10 完全自动化集成和部署
实现自动构建、部署和测试工作负载。这可以减少手动流程导致的错误，并减少部署更改的工作量。
使用[资源标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)和 [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html)，按照一致的[标记策略](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)应用元数据，以标识资源。标记资源，以便进行整理、成本核算、访问控制并有针对性地自动执行运营活动。
**期望结果：**开发人员使用工具来交付代码并推广到生产环境。开发人员无需登录 AWS 管理控制台 即可提供更新。对更改和配置进行全面的审计跟踪记录，可满足治理和合规性需求。流程是可重复的，并且可跨团队实现标准化。开发人员可以腾出时间专注于开发和代码推送，从而提高工作效率。
**常见反模式：**
+ 星期五，您完成了为功能分支编写新代码的工作。星期一，在运行代码质量测试脚本和各单元测试脚本后，您将代码签入计划发行的下一版本中。
+ 您接到任务，需要为重要问题编写修复代码，该问题在生产中影响了大量客户。对修复代码进行测试后，您提交代码并通过电子邮件发送变更管理，请求批准，以便将其部署到生产环境中。
+ 作为开发人员，您可以登录 AWS 管理控制台，使用非标准方法和系统创建新的开发环境。
**建立此最佳实践的好处：**通过实施自动化的构建和部署管理系统，可以减少手动流程导致的错误，并减少部署更改的工作量，有助于团队成员专注于实现业务价值。推广到生产环境后，交付速度也随之提高。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
使用构建和部署管理系统来跟踪并实施更改，以便减少手动流程引起的错误，并减少工作量。将集成和部署管道完全自动化，从代码签入到构建、测试、部署和验证都包含在内。这可以缩短准备时间，鼓励更频繁地进行更改，减少工作量，提高面市速度，提升生产力，并增进代码在推广到生产环境时的安全性。
## 资源
**相关最佳实践：**
+ [OPS05-BP03 使用配置管理系统](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 使用构建和部署管理系统](ops_dev_integ_build_mgmt_sys.md)
**相关文档：**
+ [什么是 AWS CodeBuild ？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [什么是 AWS CodeDeploy ？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**相关视频：**
+ [AWS re:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)
# OPS 6. 如何缓解部署风险？
采用的方法需能够提供快速质量反馈，并在更改没有达到预期结果时实现快速恢复。使用这些实践可以减轻因部署更改而产生的问题的影响。
**Topics**
+ [
# OPS06-BP01 针对不成功的更改制定计划
](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [
# OPS06-BP02 测试部署
](ops_mit_deploy_risks_test_val_chg.md)
+ [
# OPS06-BP03 采用安全部署策略
](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [
# OPS06-BP04 自动测试和回滚
](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 针对不成功的更改制定计划
制定计划，以便在部署没有达到期望结果时，在生产环境中恢复到已知良好状态，或者进行修复。制定一项策略来建立这样的计划，有助于所有团队制定从失败的更改中恢复的策略。这样的示例策略包括部署和回滚步骤、更改策略、功能标记、流量隔离和流量转移。单个发布版本可能包括多个相关的组件更改。该策略应提供承受任何组件更改的失败或从中恢复过来的能力。
**期望结果：**已为更改失败准备了详细的恢复计划。此外，还缩小了发布内容的大小，以便最大限度地减少对其他工作负载组件的潜在影响。因此，通过缩短更改失败可能造成的停机时间，提高恢复时间的灵活性和效率，减少了对业务的影响。
**常见反模式：**
+ 执行部署后，应用程序变得不稳定，但是系统上似乎还有活动用户。您必须决定是回滚更改并影响活动用户，还是等到知道用户无论如何都可能受到影响后再回滚更改。
+ 执行例行更改后，可以访问新环境，但是无法访问其中一个子网。必须决定是回滚所有内容还是尝试修复无法访问的子网。做决定时，子网仍然无法访问。
+ 系统的架构不允许使用较小的发布版本进行更新。因此，在部署失败时，很难撤销这些大批量的更改。
+ 没有使用基础设施即代码（IaC）模式，而且对基础设施进行的手动更新导致了不希望出现的配置。无法有效地跟踪和撤销手动更改。
+ 由于没有将部署频率的增加作为衡量标准，因此团队没有动力来缩小更改规模，也不愿意改进每次更改的回滚计划，从而导致风险增加和失败率上升。
+ 没有衡量因更改失败而导致的中断的总持续时间。团队无法确定部署流程的优先顺序和恢复计划的有效性，也无法进行改进。
**建立此最佳实践的好处：**制定从失败更改中恢复的计划可以最大限度地缩短平均恢复时间（MTTR），并减少对业务的影响。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
发布团队采用的一致、有据可查的策略和实践，让组织能够计划在更改失败时应如何处理。该策略应允许在特定情况下向前修复。无论是哪种情况，在部署到实际生产环境之前，都应妥善记录并测试向前修复或回滚计划，以便最大限度地减少从更改中恢复所需的时间。
### 实施步骤
1. 记录策略，该策略要求团队制定有效计划以便在指定时间内撤销更改。
1. 策略应指定何时允许出现向前修复的情况。
1. 要求所有相关人员都能查阅记录在案的回滚计划。
1. 指定回滚要求（例如，当发现部署了未经授权的更改时）。
1. 分析与工作负载每个组件相关的所有更改的影响级别。
1. 如果可重复的更改遵循的工作流程，与执行更改策略的工作流程保持一致，则允许对这些更改进行标准化、模板化和预授权。
1. 通过缩小更改的规模来减少任何更改的潜在影响，从而减少恢复所需的时间和对业务的影响。
1. 确保回滚程序将代码恢复到已知的良好状态，尽可能避免意外事件。
1. 集成工具和工作流程，以编程方式执行策略。
1. 让其他工作负载所有者能够查看有关更改的数据，以便提高对无法回滚的任何失败更改的诊断速度。
1. 利用可见的更改数据来衡量这一做法是否成功，并确定迭代改进措施。
1. 使用监控工具来验证部署的成败，从而加快制定回滚决策的速度。
1. 衡量更改失败时的停机时间，以便不断改进恢复计划。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [AWS Builders Library \$1 确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS 白皮书 \$1 Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**相关视频：**
+ [re:Invent 2019 \$1 Amazon’s approach to high-availability deployment](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)
# OPS06-BP02 测试部署
使用与生产环境相同的部署配置、安全控制、步骤和程序，在预生产环境中测试发布程序。验证所有部署步骤是否按预期完成，如检查文件、配置和服务。通过功能测试、集成测试和负载测试以及运行状况检查等各种监控方法，进一步测试所有更改。通过这些测试，可以及早发现部署问题，并有机会在进入生产之前规划和缓解问题。
可以创建临时的并行环境来测试每项更改。使用基础设施即代码（IaC）自动部署测试环境，有助于减少所涉及的工作量，确保稳定性、一致性和更快的功能交付。
**期望结果：**组织采用了包含测试部署在内的测试驱动型开发文化。这样可以确保团队专注于实现业务价值，而不是管理发布版本。各团队在发现部署风险后尽早参与进来，确定适当的缓解方案。
**常见反模式：**
+ 在发布生产版本期间，未经测试的部署会导致问题频发，需要进行故障排除和上报。
+ 发布版本包含用于更新现有资源的基础设施即代码（IaC）。不确定 IaC 是会成功运行，还是会对资源造成影响。
+ 在应用程序中部署一项新功能。此功能未按预期运行，并且在受影响的用户报告之前都无从了解问题。
+ 您更新了证书。您不小心将证书安装到了错误的组件上，而这却没有被发现，于是因为无法建立与网站的安全连接而影响网站访客。
**建立此最佳实践的好处：**在预生产环境中对部署程序及其引入的更改进行全面测试，可最大限度地减少部署步骤对生产的潜在影响。这增强了生产版本发布过程中的信心，并最大限度地减少了运营支持，而且不会减慢更改交付速度。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
测试部署过程与测试部署所产生的更改同样重要。要完成这一步骤，可以在尽可能接近生产环境的预生产环境中测试部署步骤。可以在投入生产之前发现一些常见问题，如部署步骤不完整、不正确或配置错误。此外，还可以测试恢复步骤。
**客户示例**
作为持续集成和持续交付（CI/CD）管道的一部分，AnyCompany Retail 在类似生产的环境中执行为客户发布基础设施和软件更新所需的既定步骤。该管道包含预检查过程，用于在部署之前检测资源中的偏差（检测在 IaC 之外对资源执行的更改），以及验证 IaC 在启动时采取的操作。该管道会验证部署步骤，例如在向负载均衡器重新注册之前，验证特定文件和配置是否已准备就绪，服务是否处于正在运行状态，以及是否正确响应本地主机上的运行状况检查。此外，所有更改都要进行一系列自动测试，如功能测试、安全测试、回归测试、集成测试和负载测试。
### 实施步骤
1. 执行预安装检查，模拟生产环境打造预生产环境。
1. 使用[偏差检测](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)功能，检测是否在 CloudFormation 之外更改了资源。
1. 使用[更改集](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html)功能，验证堆栈更新的意图是否与 CloudFormation 在启动更改集时所采取的操作相匹配。
1. 这会触发 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) 中的手动批准步骤，以授权部署到预生产环境。
1. 使用 [AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) 文件等部署配置来定义部署和验证步骤。
1. 在适用的情况下，[将 AWS CodeDeploy 与其他 AWS 服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html)，或[将 AWS CodeDeploy 与合作伙伴的产品和服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html)。
1. 使用 Amazon CloudWatch、AWS CloudTrail 和 Amazon SNS 事件通知[监控部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html)。
1. 执行部署后的自动化测试，包括功能测试、安全测试、回归测试、集成测试和负载测试。
1. 部署问题[疑难解答](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html)。
1. 成功验证上述步骤后应启动手动审批工作流程，授权部署到生产环境。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [OPS05-BP02 测试并验证更改](ops_dev_integ_test_val_chg.md)
**相关文档：**
+ [AWS Builders' Library \$1 自动实现无需干预的安全部署 \$1 测试部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS 白皮书 \$1 在 AWS 上练习持续集成和持续交付](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [The Story of Apollo - Amazon's Deployment Engine](https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html)
+ [How to test and debug AWS CodeDeploy locally before you ship your code](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [Integrating Network Connectivity Testing with Infrastructure Deployment](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)
**相关视频：**
+ [re:Invent 2020 \$1 Testing software and systems at Amazon](https://www.youtube.com/watch?v=o1sc3cK9bMU)
**相关示例：**
+ [Tutorial \$1 Deploy and Amazon ECS service with a validation test](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)
# OPS06-BP03 采用安全部署策略
在安全的生产环境滚动部署中，会对有益更改的流程进行控制，目标是尽可能减少这些更改让客户感知到的任何影响。安全控制措施提供检查机制，用于验证是否达成期望结果，并针对由于更改或部署失败所引入的任何缺陷，限制这些缺陷的影响范围。安全滚动部署可包括功能标记、单盒、滚动（金丝雀版本）、不可变、流量分割和蓝绿部署等策略。
**期望结果：**组织使用持续集成/持续交付（CI/CD）系统，提供自动进行安全滚动部署的功能。团队必须使用适当的安全滚动部署策略。
**常见反模式：**
+ 将不成功的更改一次性部署到所有生产环境中。因此，所有客户同时受到影响。
+ 在同时部署到所有系统时，引入的缺陷需要紧急进行修复。为所有客户修复该缺陷需要几天时间。
+ 管理生产版本发布需要多个团队的规划和参与。这限制了为客户更新功能的频率。
+ 通过修改现有系统来执行可变部署。发现更改不成功后，被迫再次修改系统，还原旧版本，导致恢复时间延长。
**建立此最佳实践的好处：**自动化的部署，在快速滚动部署与持续向客户提供有益更改之间取得平衡。限制影响范围可以防止代价高昂的部署失败，并最大限度地提高团队有效应对失败的能力。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
持续交付失败会导致服务可用性降低，带来糟糕的客户体验。为了最大限度地提高部署成功率，请在端到端发布流程中实施安全控制措施，以便最大限度地减少部署错误，以达成零部署失败为目标。
**客户示例**
AnyCompany Retail 的目标是尽可能减少部署的停机时间，甚至实现零停机，这意味着在部署期间，不会对用户造成任何可察觉影响。为了实现这一目标，公司建立了部署模式（参阅以下工作流程图），例如滚动部署和蓝绿部署。所有团队在各自的 CI/CD 管道中都采用了其中一种或多种模式。
| 适用于 Amazon EC2 的 CodeDeploy 工作流程 | 适用于 Amazon ECS 的 CodeDeploy 工作流程 | 适用于 Lambda 的 CodeDeploy 工作流程 |
| --- | --- | --- |
| ![\[适用于 Amazon EC2 的部署流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-process-ec2.png) | ![\[适用于 Amazon ECS 的部署流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-process-ecs.png) | ![\[适用于 Lambda 的部署流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-process-lambda.png) |
### 实施步骤
1. 使用审批工作流程在提升到生产版本后，启动生产版本滚动部署步骤序列。
1. 使用 [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 等自动化部署系统。AWS CodeDeploy [部署选项](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html)包括 EC2/本地就地部署及 EC2/本地蓝绿部署、AWS Lambda 和 Amazon ECS（参阅前面的工作流程图）。
1. 在适用的情况下，[将 AWS CodeDeploy 与其他 AWS 服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html)，或[将 AWS CodeDeploy 与合作伙伴的产品和服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html)。
1. 对诸如 [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) 和 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) 之类的数据库使用蓝/绿部署。
1. 使用 Amazon CloudWatch、AWS CloudTrail 和 Amazon Simple Notification Service（Amazon SNS）[监控部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html)。
1. 执行部署后的自动化测试，包括功能测试、安全测试、回归测试、集成测试以及任何负载测试。
1. 部署问题[疑难解答](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html)。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS05-BP02 测试并验证更改](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP09 频繁进行可逆的小规模更改](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 完全自动化集成和部署](ops_dev_integ_auto_integ_deploy.md)
**相关文档：**
+ [AWS Builders Library \$1 自动实现无需干预的安全部署 \$1 生产部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders Library \$1 My CI/CD pipeline is my release captain \$1 Safe, automatic production releases](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [AWS 白皮书 \$1 在 AWS 上练习持续集成和持续交付 \$1 部署方法](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [AWS CodeDeploy《用户指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)》
+ [Working with deployment configurations in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [设置 API Gateway 金丝雀版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Amazon ECS Deployment Types](https://docs.aws.amazon.com/)
+ [Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS](https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/)
+ [Blue/Green deployments with AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
**相关视频：**
+ [re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon's Approach to high-availability deployment](https://www.youtube.com/watch?v=bCgD2bX1LI4)
**相关示例：**
+ [Try a Sample Blue/Green Deployment in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [ Workshop \$1 Building CI/CD pipelines for Lambda canary deployments using AWS CDK](https://catalog.workshops.aws/cdk-cicd-for-lambda-canary-deployment/en-US)
+ [ Workshop \$1 Building your first DevOps Blue/Green pipeline with Amazon ECS ](https://catalog.us-east-1.prod.workshops.aws/workshops/4b59b9fb-48b6-461c-9377-907b2e33c9df/en-US)
+ [ Workshop \$1 Building your first DevOps Blue/Green pipeline with Amazon EKS ](https://catalog.us-east-1.prod.workshops.aws/workshops/4eab6682-09b2-43e5-93d4-1f58fd6cff6e/en-US)
+ [ Workshop \$1 EKS GitOps with ArgoCD ](https://catalog.workshops.aws/eksgitops-argocd-githubactions)
+ [ Workshop \$1 CI/CD on AWS Workshop ](https://catalog.workshops.aws/cicdonaws/en-US)
+ [ Implementing cross-account CI/CD with AWS SAM for container-based Lambda functions ](https://aws.amazon.com/blogs/compute/implementing-cross-account-cicd-with-aws-sam-for-container-based-lambda/)
# OPS06-BP04 自动测试和回滚
为了提高部署过程的速度和可靠性以及对该过程的信心，需要制定一项策略，用于在预生产环境和生产环境中实现自动化的测试和回滚功能。在部署到生产环境时自动进行测试，模拟人与系统的交互，从而验证已经部署的更改。利用自动回滚功能，可以快速恢复到先前已知的良好状态。回滚应在预先定义的条件下自动启动，例如更改未达到期望结果或自动化测试失败时。自动执行这两项活动可以提高部署的成功率，尽可能缩短恢复时间，并减少可能对业务造成的影响。
**期望结果：**自动化测试和回滚策略已集成到持续集成/持续交付（CI/CD）管道中。监控功能可以根据成功标准进行验证，并能在失败时启动自动回滚。这样可以最大限度地减少对终端用户和客户的任何影响。例如，对所有测试结果都感到满意时，可以将代码提升到生产环境中，该环境启动了使用相同测试案例的自动回归测试。如果回归测试结果与预期不符，则在管道工作流程中启动自动回滚。
**常见反模式：**
+ 系统的架构不允许使用较小的发布版本进行更新。因此，在部署失败时，很难撤销这些大批量的更改。
+ 部署流程包括一系列手动步骤。将更改部署到工作负载后，启动部署后测试。完成测试之后，发现工作负载不可操作，而且客户断开了连接。然后，开始回滚到之前的版本。所有这些手动步骤都会延误整个系统的恢复，并对客户造成长时间的影响。
+ 花时间为应用程序中不常用的功能开发了自动化测试案例，这极大地降低了在自动化测试功能上的投资回报率。
+ 发布版本由应用程序、基础设施、补丁和配置更新组成，这些组件相互独立。但是，只有一个 CI/CD 管道，只能同时交付所有更改。一个组件中的失败会迫使撤销所有更改，导致回滚过程复杂且效率低下。
+ 团队完成了冲刺一的编码工作并开始冲刺二的工作，但是按照计划，直到冲刺三才会进行测试。结果，自动化测试发现冲刺一中存在缺陷，必须先解决这些缺陷，才能开始测试冲刺二的可交付成果，这延误了整个发布过程，大大降低了自动化测试的价值。
+ 生产版本的自动化回归测试案例已完成，但没有监控工作负载运行状况。由于无法监控服务是否已重新启动，因此不确定是否需要回滚或者是否已经进行了回滚。
**建立此最佳实践的好处：**自动化测试可提高测试过程的透明度，以及在更短的时间内测试更多功能的能力。通过对生产环境中的更改进行测试和验证，可以立即发现问题。利用自动化测试工具改进一致性，可以更好地检测缺陷。通过自动回滚到之前的版本，可以将对客户的影响降至最低。自动回滚可以减少业务影响，最终提升对部署功能的信心。总体而言，这些功能可在确保质量的同时缩短交付时间。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
自动测试部署的环境，以便更快地确认期望结果。在没有达到预定义的结果时，自动回滚到之前的已知良好状态，尽可能地缩短恢复时间，并减少手动流程导致的错误。将测试工具与管道工作流程集成，以便一致地开展测试并尽可能减少手动输入。确定优先执行的自动化测试案例，例如能够降低最大风险的测试案例，以及每次更改都需要频繁测试的测试案例。此外，还可以根据在测试计划中预定义的特定条件自动回滚。
### 实施步骤
1. 为开发生命周期建立测试生命周期，针对测试过程，从需求规划到测试案例开发、工具配置、自动化测试和测试案例关闭，对每个阶段进行定义。
1. 根据整体测试策略，创建特定于工作负载的测试方法。
1. 考虑在整个开发生命周期中适宜的阶段实施持续测试策略。
1. 根据业务要求和管道投资，选择用于测试和回滚的自动化工具。
1. 确定要自动执行哪些测试案例，以及应手动执行哪些测试案例。这个过程可以根据所测试功能的业务价值优先级来定义。确保所有团队成员都遵守该计划，并核实执行手动测试的责任人。
1. 在自动化测试可以实现价值的特定测试案例上使用自动化测试功能，例如可重复或经常运行的案例、需要重复任务的案例或者多种配置中所需的案例。
1. 在自动化工具中定义测试自动化脚本和成功标准，以便在特定案例失败时可以启动持续的自动化工作流程。
1. 为自动回滚定义具体的失败标准。
1. 优先考虑测试自动化，在过于复杂和人工交互会导致更高失败风险的案例中，通过开发全面的测试案例来获得一致的结果。
1. 将自动化测试和回滚工具集成到 CI/CD 管道中。
1. 为更改制定明确的成功标准。
1. 监控并观察以便检测这些标准，以及在满足特定回滚标准时自动撤销更改。
1. 执行不同类型的自动化生产测试，例如：
1. A/B 测试，显示在两个用户测试组之间当前版本的结果对比。
1. 金丝雀测试，允许先对一部分用户部署更改，然后再向所有用户发布。
1. 功能标记测试，允许在应用程序外部，每次将新版本的单个功能标记为打开和关闭，以便每次逐个验证各个新功能。
1. 回归测试，用于验证现有相互关联组件的新功能。
1. 监控应用程序的操作情况、事务，以及与其他应用程序和组件的交互。编制报告，用于按工作负载显示更改是否成功，以便确定对自动化和工作流程的哪些部分进一步进行优化。
1. 编制测试结果报告，以便快速决定是否应调用回滚程序。
1. 实施策略，以便根据一种或多种测试方法的预定义失败条件进行自动回滚。
1. 开发自动化测试案例，以便在将来的可重复更改中重用。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 测试部署](ops_mit_deploy_risks_test_val_chg.md)
**相关文档：**
+ [AWS Builders Library \$1 确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [Redeploy and rollback a deployment with AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
+ [ 8 best practices when automating your deployments with AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)
**相关示例：**
+ [Serverless UI testing using Selenium, AWS Lambda, AWS Fargate, and AWS Developer Tools](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)
**相关视频：**
+ [re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon's Approach to high-availability deployment ](https://www.youtube.com/watch?v=bCgD2bX1LI4)
# OPS 7. 如何知道您已经准备好支持某种工作负载？
评估工作负载、流程及程序和工作人员的操作准备情况，以便了解与工作负载相关的操作风险。
**Topics**
+ [
# OPS07-BP01 确保员工能力
](ops_ready_to_support_personnel_capability.md)
+ [
# OPS07-BP02 确保以一致的方式对运营准备情况进行审查
](ops_ready_to_support_const_orr.md)
+ [
# OPS07-BP03 使用运行手册执行程序
](ops_ready_to_support_use_runbooks.md)
+ [
# OPS07-BP04 根据行动手册调查问题
](ops_ready_to_support_use_playbooks.md)
+ [
# OPS07-BP05 作出明智的决策来部署系统和变更
](ops_ready_to_support_informed_deploy_decisions.md)
+ [
# OPS07-BP06 为生产工作负载创建支持计划
](ops_ready_to_support_enable_support_plans.md)
# OPS07-BP01 确保员工能力
制定一种机制来验证是否有适当数量训练有素的员工来支持工作负载。必须针对构成工作负载的平台和服务对他们进行培训。为他们提供运营工作负载所需的知识。必须有足够训练有素的员工来支持工作负载的正常运营和排查发生的意外事件。拥有足够数量的员工，以便在值班和休假期间轮换，避免出现倦怠。
**期望结果：**
+ 在工作负载可用时，有足够训练有素的员工为工作负载提供支持。
+ 针对构成工作负载的软件和服务，对员工进行培训。
**常见反模式：**
+ 部署工作负载，但没有对团队成员进行培训来运营所使用的平台和服务。
+ 员工数量不足，无法支持轮流值班或休假。
**建立此最佳实践的好处：**
+ 拥有技能娴熟的团队成员能够为工作负载提供有效支持。
+ 有足够的团队成员，可以支持工作负载和实现轮流值班，同时降低出现倦怠的风险。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
确认是否有足够的训练有素的员工来支持工作负载。确认是否有足够的团队成员来执行正常运营活动，包括轮流值班。
**客户示例**
AnyCompany Retail 确保支持工作负载的团队配备了适当的人员，并经过培训。他们有足够的工程师支持轮流值班。他们针对构建工作负载的软件和平台对员工进行培训，并鼓励他们获得认证。他们有足够的员工，所以员工可以休假，同时仍然可以支持工作负载和轮流值班。
### 实施步骤
1. 分配足够数量的人员来运营和支持工作负载，包括随叫随到的职责、安全问题和生命周期事件，如终止支持和证书轮换任务。
1. 针对构成工作负载的软件和平台方面对员工进行培训。
1. [AWS 培训和认证](https://aws.amazon.com/training/)有一个关于 AWS 的课程库。这里提供线上和线下的免费和付费课程。
1. [AWS 举办活动和网络研讨会](https://aws.amazon.com/events/)，可以从中向 AWS 专家学习。
1. 定期执行以下操作：
+ 随着运营条件和工作负载发生变化，评估团队规模和技能。
+ 调整团队规模和技能来满足运营要求。
+ 验证通过 AWS Health 来[解决计划内生命周期事件](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html)、计划外安全性和运营通知的能力。
**实施计划的工作量级别：**高。雇用和培训团队来支持工作负载需要付出巨大的努力，但可带来可观的长期效益。
## 资源
**相关最佳实践：**
+ [OPS11-BP04 执行知识管理](ops_evolve_ops_knowledge_management.md) – 团队成员必须具备运营和支持工作负载所需的信息。知识管理是提供这些信息的关键。
**相关文档：**
+ [AWS 活动和网络研讨会](https://aws.amazon.com/events/)
+ [AWS 培训和认证](https://aws.amazon.com/training/)
# OPS07-BP02 确保以一致的方式对运营准备情况进行审查
使用运营准备情况审查（ORR），确保可以运营工作负载。ORR 是 Amazon 开发的一种机制，用于验证团队是否可以安全地运营工作负载。ORR 是一个使用要求核对清单进行审查和检查的过程。ORR 是一种自助服务体验，供团队用于验证其工作负载。ORR 中包含的最佳实践源自我们多年构建软件的经验教训。
ORR 核对清单包括架构推荐、运营流程、事件管理和发布质量。我们的错误更正（CoE）流程是这些项目的主要推动因素。意外事件后分析应该可以推动自己的 ORR 演进。ORR 不仅在于遵循最佳实践，还在于预防以前的事件再次发生。最后，ORR 中还可以包括安全、治理和合规性方面的要求。
在工作负载正式公开发布之前运行 ORR，然后在整个软件开发生命周期中运行 ORR。在发布之前运行 ORR 可以提升安全运营工作负载的能力。在工作负载上定期重新运行 ORR 可以收集任何偏离最佳实践的情况。可以准备用于新服务发布的 ORR 核对清单以及用于定期审查的 ORR。这有助于遵循最新制定的最佳实践，并吸取从意外事件后分析中学到的经验教训。随着对云的使用日趋成熟，可以将 ORR 要求作为默认设置整合到自己的架构中。
**期望结果：**已准备好 ORR 核对清单，其中包括适用于组织的最佳实践。在工作负载发布之前执行 ORR。在整个工作负载生命周期中定期执行 ORR。
**常见反模式：**
+ 您启动了工作负载，但不知道自己是否能够运营工作负载。
+ 在验证工作负载以便发布时，没有包括治理和安全要求。
+ 没有定期重新评估工作负载。
+ 在未准备好所需程序的情况下发布工作负载。
+ 在多个工作负载中发现相同的根本原因反复导致出现故障。
**建立此最佳实践的好处：**
+ 工作负载包括架构、流程和管理最佳实践。
+ 学到的经验教训可合并到 ORR 流程中。
+ 在工作负载发布时已准备好所需程序。
+ 在工作负载的整个软件生命周期中执行 ORR。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
ORR 关系到两点：流程和核对清单。ORR 流程应该由组织采用并获得执行发起人支持。至少，在工作负载正式公开发布之前执行 ORR。在整个软件开发生命周期中执行 ORR，可确保软件始终遵循新的最佳实践或新要求。ORR 核对清单应包括组织的配置项目、安全要求和治理要求以及最佳实践。随着时间的推移，可以使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)、[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 和 [AWS Control Tower Guardrails](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 等服务将源自 ORR 的最佳实践构建到防护机制中，以便自动检测最佳实践。
**客户示例**
在经历了多起生产意外事件之后，AnyCompany Retail 决定实施 ORR 流程。他们构建了核对清单，其中包括最佳实践、治理要求和合规性要求，以及从中断中学到的经验教训。他们在发布新工作负载之前执行 ORR。每个工作负载会每年执行一次 ORR，其中包括一小组最佳实践，用于整合添加到 ORR 核对清单中的新最佳实践和要求。随着时间的推移，AnyCompany Retail 使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 来检测某些最佳实践，加快了 ORR 流程。
**实施步骤**
有关 ORR 的更多信息，请阅读《[Operational Readiness Reviews（ORR）白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)》。其中详细介绍了 ORR 流程的历史、如何构建自己的 ORR 实践，以及如何制定自己的 ORR 核对清单。以下步骤是该文档的缩减版本。如需深入了解什么是 ORR 以及如何自行构建，建议阅读该白皮书。
1. 让关键利益相关方聚在一起讨论，包括来自安全、运营和开发部门的代表。
1. 让每个利益相关方至少提一项要求。对于第一次迭代，请尝试将项目数限制为不超过三十个。
+ [Appendix B: Example ORR questions](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) 源自《Operational Readiness Reviews（ORR）白皮书》，包含在开始着手时可借鉴的示例问题。
1. 在电子表格中收集要求。
+ 您可以使用 [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) 中的[自定义剖析](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)来开发 ORR，并在账户和 AWS 组织中共享这些剖析。
1. 确定一个工作负载来执行 ORR。最好选择发布前的工作负载或内部工作负载。
1. 运行 ORR 核对清单并记录任何发现结果。如果采取了缓解措施，发现结果可能是可接受的。对于任何没有防范措施的发现结果，请将它们记录到项目的积压工作项中，并在发布之前处理它们。
1. 在一段时间后，继续在 ORR 核对清单中添加最佳实践和要求。
使用 Enterprise Support 的 支持 客户可以向其技术客户经理申请[运营准备情况审查讲习会](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)。该讲习会是一个交互式*逆向工作*会议，旨在制定自己的 ORR 核对清单。
**实施计划的工作量级别：**高。在组织中采用 ORR 实践需要获得高管支持以及利益相关方的支持。利用整个组织的意见来构建和更新核对清单。
## 资源
**相关最佳实践：**
+ [OPS01-BP03 评估治理要求](ops_priorities_governance_reqs.md) – 治理要求非常适合包括在 ORR 核对清单中。
+ [OPS01-BP04 评估合规性要求](ops_priorities_compliance_reqs.md) – 合规性要求有时候包括在 ORR 核对清单中。另一些时候它们可作为单独的流程。
+ [OPS03-BP07 为团队配置适当的资源](ops_org_culture_team_res_appro.md) – 团队能力是适合加入 ORR 要求的候选项。
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – 在发布工作负载之前，必须建立回滚或前滚计划。
+ [OPS07-BP01 确保员工能力](ops_ready_to_support_personnel_capability.md) – 为了支持工作负载，必须具备所需的人员。
+ [SEC01-BP03 确定和验证控制目标](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – 安全控制目标进一步完善了 ORR 要求。
+ [REL13-BP01 定义停机和数据丢失的恢复目标](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – 灾难恢复计划是一项很好的 ORR 要求。
+ [COST02-BP01 根据组织要求制定政策](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – 成本管理政策非常适合包含在 ORR 核对清单中。
**相关文档：**
+ [AWS Control Tower - Guardrails in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [AWS Well-Architected Tool - Custom Lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [Operational Readiness Review Template by Adrian Hornsby](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79)
+ [Operational Readiness Reviews（ORR）白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
**相关视频：**
+ [AWS 支持s You \$1 Building an Effective Operational Readiness Review (ORR)](https://www.youtube.com/watch?v=Keo6zWMQqS8)
**相关示例：**
+ [运营准备情况审查（ORR）剖析示例](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens)
**相关服务：**
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 使用运行手册执行程序
*运行手册*是实现特定结果的书面流程。运行手册由人们为完成某件事而遵循的一系列步骤组成。早在航空发展的早期，运行手册便已用于运营。在云运营中，我们使用运行手册来降低风险并实现期望结果。简单而言，运行手册就是完成一项任务的核对清单。
运行手册是运营工作负载的重要组成部分。从新团队成员入职到部署主要版本，运行手册都是一个成文的流程，无论谁使用，都能获得一致的结果。运行手册应发布在中央位置，并随着流程的发展而更新，因为更新运行手册是变更管理流程的一个关键组成部分。运行手册还应包括关于错误处理、工具、权限、异常和出现问题时进行上报的指导。
随着组织日益成熟，应开始实现运行手册自动化。从简短且经常使用的运行手册开始。使用脚本语言来实现步骤自动化或让步骤更容易执行。自动化前几本运行手册后，将花时间自动化更复杂的运行手册。随着时间的推移，大多数运行手册应以某种方式实现自动化。
**期望结果：**团队有一系列执行工作负载任务的分步指南。运行手册包含期望结果、必要的工具和权限，以及关于错误处理的说明。运行手册存储在一个中央位置（版本控制系统）并经常更新。例如，在应用程序发出警报、出现操作问题和计划内生命周期事件期间，运行手册可为团队提供监控、沟通和响应关键账户 AWS Health 事件的功能。
**常见反模式：**
+ 依靠记忆完成流程的每个步骤。
+ 手动部署更改而不使用核对清单。
+ 不同的团队成员执行相同的流程，但执行不同的步骤或取得不同的结果。
+ 运行手册与系统更改和自动化不同步。
**建立此最佳实践的好处：**
+ 降低手动任务的错误率。
+ 以一致的方式执行操作。
+ 新的团队成员可以更早地开始执行任务。
+ 可以自动化运行手册来减少工作量。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
根据组织的成熟程度，运行手册可以采用多种形式。它们至少应该包含一个分步文本文档。应明确指出期望结果。清楚地记录必要的特殊权限或工具。提供关于错误处理和出现问题时进行上报的详细指导。列出运行手册负责人，并将运行手册发布在中央位置。一旦运行手册编写完成，让团队中的其他人运行它来进行验证。随着程序的发展，根据变更管理流程更新运行手册。
随着组织日益成熟，文本运行手册应实现自动化。使用 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 等服务，可以将纯文本转换为可以根据工作负载运行的自动化代码。这些自动化代码可以根据发生的事件运行，从而减轻维持工作负载的运营负担。AWSSystems Manager Automation 还提供了低代码[视觉对象设计体验](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-visual-designer.html)，可以更轻松地创建自动化运行手册。
**客户示例**
AnyCompany Retail 必须在软件部署期间执行数据库架构更新。云运营团队与数据库管理团队合作，构建了一个用于手动部署这些更改的运行手册。该运行手册以核对清单的形式列出了流程中的每个步骤。其中有一节是关于出错时的错误处理。他们在内部 Wiki 上发布了该运行手册和其他运行手册。云运营团队计划在未来的冲刺阶段实现运行手册的自动化。
### 实施步骤
如果当前没有文档存储库，则版本控制存储库是开始构建运行手册库的理想之处。可以使用 Markdown 构建运行手册。我们提供了一个示例运行手册模板，您可以用该模板开始构建运行手册。
```
# Runbook Title
## Runbook Info
| Runbook ID | Description | Tools Used | Special Permissions | Runbook Author | Last Updated | Escalation POC |
|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this runbook for? What is the desired outcome? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name |
## Steps
1. Step one
2. Step two
```
1. 如果当前没有文档存储库或 Wiki，请在版本控制系统中创建一个新的版本控制存储库。
1. 确定没有运行手册的流程。理想流程是半定期执行的流程，步骤少，且故障影响小。
1. 在文档存储库中，使用模板创建新的草稿 Markdown 文档。填写运行手册书名以及“运行手册信息”下的必填字段。
1. 从第一步开始，填写运行手册的“步骤”部分。
1. 将运行手册分发给团队成员。让他们使用运行手册来验证这些步骤。如果有遗漏或需要澄清的地方，请更新运行手册。
1. 将运行手册发布到内部文档存储区。发布后，告诉团队和其他利益相关方。
1. 随着时间的推移，将构建运行手册库。随着该库的增长，开始努力实现运行手册的自动化。
**实施计划的工作量级别：**低。运行手册的最低标准是一个分步文本指南。实现运行手册自动化可能会增加实施工作量。
## 资源
**相关最佳实践：**
+ [OPS02-BP02 确定流程和程序负责人](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP04 根据行动手册调查问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html)
+ [OPS10-BP01 使用流程来管理事件、意外事件和问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 针对每个警报设置一个流程](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 执行知识管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相关文档：**
+ [Achieving Operational Excellence using automated playbook and runbook](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager：使用运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Migration playbook for AWS large migrations - Task 4: Improving your migration runbooks](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html)
+ [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**相关视频：**
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [How to automate IT Operations on AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**相关示例：**
+ [Well-Architected Lab：使用行动手册和运行手册实现运营自动化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [AWS Blog 文章：Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS Systems Manager：自动化演练](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager：从最新的快照运行手册中还原根卷](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+ [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Gitlab – 运行手册](https://gitlab.com/gitlab-com/runbooks)
+ [Rubix – 用于在 Jupyter Notebook 中构建运行手册的 Python 库](https://github.com/Nurtch/rubix)
+ [使用文档生成器创建自定义运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**相关服务：**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 根据行动手册调查问题
*行动手册*是用于调查意外事件的分步指南。发生意外事件时，行动手册用于开展调查，以及确定影响范围和根本原因。行动手册可用于从失败部署到安全事件的各种场景。在许多情况下，行动手册可确定根本原因，而运行手册可用来缓解根本原因带来的风险。行动手册是组织意外事件响应计划的必要组成部分。
出色的行动手册有几个主要特点。它逐步指导用户完成事件的发现过程。引导用户由外而内地进行思考，应执行哪些步骤来诊断意外事件？ 如果行动手册中需要特殊工具或提升的权限，行动手册中会明确定义。制定沟通计划，以便向利益相关方提供有关调查状态的最新信息，这是事件响应计划的关键组成部分。在无法确定根本原因的情况下，行动手册应具有上报计划。如果确定了根本原因，行动手册应指向介绍如何解决根本原因的运行手册。行动手册应集中存储并定期维护。如果行动手册用于特定提醒，请向团队提供关于提醒中行动手册的提示。
随着组织日趋成熟，可自动实施行动手册。从包含低风险意外事件的行动手册开始实施。使用脚本自动执行发现步骤。确保有配套的运行手册来缓解常见根本原因带来的风险。
**期望结果**：组织有针对常见意外事件的行动手册。行动手册存储在中心位置，可供团队成员使用。行动手册经常进行更新。对于任何已知的根本原因，将制定配套的运行手册。
**常见反模式：**
+ 没有调查意外事件的标准方法。
+ 团队成员依靠肌肉记忆或对机构的了解，对失败的部署进行故障排除。
+ 新的团队成员将了解如何通过试错法来调查问题。
+ 调查问题的最佳实践无法在团队间分享。
**建立此最佳实践的好处：**
+ 行动手册有助于缓解意外事件带来的影响。
+ 不同的团队成员可使用同一行动手册，以一致的方式确定根本原因。
+ 可以针对已知的根本原因制定运行手册，从而加快恢复速度。
+ 团队成员根据行动手册能够更快地开始行动。
+ 团队可以使用可重复的行动手册来扩展其流程。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
制定和使用行动手册的方式取决于组织的成熟度。如果是初次使用云，请在中央文档存储库中以文本形式制定行动手册。随着组织日趋成熟，可以使用 Python 等脚本语言实现行动手册的半自动化。可以在 Jupyter Notebook 中运行这些脚本来加快发现速度。先进的组织已针对可通过运行手册自动修正的常见问题，制定了完全自动化的行动手册。
通过列出工作负载所发生的常见意外事件，开始制定行动手册。为风险较低且根本原因范围已缩小到几个问题的意外事件选择行动手册。在为较简单的场景制定行动手册后，可以着手处理风险较高的场景或根本原因尚不确定的场景。
随着组织日趋成熟，文本形式的行动手册应实现自动化。使用 [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 等服务，可以将纯文本转换为自动化代码。可以针对工作负载运行这些自动化代码，从而加快调查速度。可以激活这些自动化代码来响应事件，从而减少发现和解决意外事件所需的平均时间。
客户可以使用 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 来响应意外事件。此服务提供了一个单一界面，可对意外事件进行分类、在发现和缓解问题期间通知利益相关方，并在整个意外事件中进行协作。其使用 AWS Systems Manager Automations 加快检测和恢复的速度。
**客户示例**
一个生产意外事件影响了 AnyCompany Retail。随时待命的工程师根据行动手册调查了问题。随着他们逐步地解决问题，他们不断为行动手册中确定的关键利益相关方提供最新信息。工程师最终确定，根本原因是后端服务中出现竞态条件。根据运行手册，工程师重新启动了该服务，并使 AnyCompany Retail 重新联机。
### 实施步骤
如果当前没有文档存储库，建议为行动手册库创建版本控制存储库。可以使用 Markdown 制定行动手册，该服务与大多数行动手册自动化系统兼容。如果从头开始制定行动手册，请使用以下行动手册示例模板。
```
# Playbook Title
## Playbook Info
| Playbook ID | Description | Tools Used | Special Permissions | Playbook Author | Last Updated | Escalation POC | Stakeholders | Communication Plan |
|-------|-------|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this playbook for? What incident is it used for? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name | Stakeholder Name | How will updates be communicated during the investigation? |
## Steps
1. Step one
2. Step two
```
1. 如果当前没有文档存储库或 Wiki，请在版本控制系统中为行动手册创建一个新的版本控制存储库。
1. 确定需要进行调查的常见问题。这应该是根本原因范围限于几个问题且解决方案风险较低的场景。
1. 利用 Markdown 模板，填写“行动手册书名”部分，并填写“行动手册信息”下的字段。
1. 填写故障排除步骤。尽可能清楚地填写要采取哪些行动，或者应调查哪些方面。
1. 将行动手册分发给团队成员，让他们仔细阅读并加以验证。如果发现有遗漏之处或某些内容不清楚，请更新行动手册。
1. 在文档存储库中发布行动手册，并告知团队和任何利益相关方。
1. 随着添加更多的行动手册，这个行动手册库将会不断扩大。拥有多个行动手册后，可以开始使用 AWS Systems Manager Automations 等工具自动执行行动手册，从而使自动化操作和行动手册保持同步。
**实施计划的工作量级别：**低。行动手册应该是存储在中心位置的文本文档。对于更加成熟的组织，将转为自动化行动手册。
## 资源
**相关最佳实践：**
+ [OPS02-BP02 确定流程和程序负责人](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP03 使用运行手册执行程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 使用流程来管理事件、意外事件和问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 针对每个警报设置一个流程](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 执行知识管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相关文档：**
+ [Achieving Operational Excellence using automated playbook and runbook](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager：使用运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**相关视频：**
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS Systems Manager Incident Manager - AWS 虚拟讲习会](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**相关示例：**
+ [AWS 客户行动手册框架](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager：自动化演练](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Rubix – 用于在 Jupyter Notebook 中构建运行手册的 Python 库](https://github.com/Nurtch/rubix)
+ [使用文档生成器创建自定义运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**相关服务：**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
# OPS07-BP05 作出明智的决策来部署系统和变更
为工作负载的成功和不成功变更制定恰当的流程。故障演练是一种演习，团队模拟发生故障的情况来制定缓解策略。使用故障演练来预测故障，并在适当的时候创建程序。评估将变更部署到工作负载所获得益处和产生的风险。确认所有变更符合治理要求。
**期望结果：**
+ 将变更部署到工作负载时作出明智的决策。
+ 变更符合治理要求。
**常见反模式：**
+ 将变更部署到工作负载，而没有处理失败部署的流程。
+ 对生产环境作出不符合治理要求的变更。
+ 部署新版本的工作负载，而不为资源利用建立基准。
**建立此最佳实践的好处：**
+ 为工作负载的不成功变更做好了准备。
+ 工作负载的变更符合治理政策。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
使用故障演练制定不成功变更的流程。记录不成功变更的流程。确保所有变更均符合治理要求。评估将变更部署到工作负载所获得益处和产生的风险。
**客户示例**
AnyCompany Retail 定期执行故障演练来验证不成功变更的流程。他们在共享的 Wiki 中记录流程并经常更新。所有变更均符合治理要求。
**实施步骤**
1. 将变更部署到工作负载时作出明智的决策。确立并审查成功部署的条件。制定将启动变更回滚的方案或条件。在部署变更带来的好处与不成功变更产生的风险之间进行权衡。
1. 确认所有变更均符合治理政策。
1. 使用故障演练为不成功的变更制定计划，并记录缓解策略。运行桌面演练，为不成功的变更建模，并验证回滚程序。
**实施计划的工作量级别：**中。实施故障演练的实践需要整个组织内的利益相关方进行协调和付出努力
## 资源
**相关最佳实践：**
+ [OPS01-BP03 评估治理要求](ops_priorities_governance_reqs.md) – 治理要求是确定是否部署变更的关键因素。
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – 制定计划来缓解失败的部署，并使用故障演练来进行验证。
+ [OPS06-BP02 测试部署](ops_mit_deploy_risks_test_val_chg.md) – 在部署之前应适当地测试每项软件变更，以便减少生产中的缺陷。
+ [OPS07-BP01 确保员工能力](ops_ready_to_support_personnel_capability.md) – 有足够训练有素的人员来支持工作负载，这对于作出部署系统变更的明智决策很重要。
**相关文档：**
+ [亚马逊云科技：风险与合规性](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [AWS 责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [Governance in the AWS 云: The Right Balance Between Agility and Safety](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
# OPS07-BP06 为生产工作负载创建支持计划
为生产工作负载所依赖的所有软件和服务启用支持。选择适当的支持级别来满足生产服务水平需求。以防出现服务中断或软件问题，这些依赖项的支持计划必不可少。记录支持计划以及如何向所有服务和软件供应商请求支持。实施机制，以便确认主要支持联系人的信息保持最新。
**期望结果：**
+ 为生产工作负载所依赖的软件和服务实施支持计划。
+ 根据服务水平需求选择适当的支持计划。
+ 记录支持计划、支持级别以及如何请求支持。
**常见反模式：**
+ 没有制定面向关键软件供应商的支持计划。工作负载受到影响，无法采取任何措施来加快修复或从供应商获得及时更新。
+ 作为软件供应商主要联系人的开发人员离开了公司。您无法直接联系供应商支持人员。您必须花时间研究和浏览通用联系系统，延长在需要时作出反应所需的时间。
+ 软件供应商发生生产中断。没有关于如何提出支持案例的文档。
**建立此最佳实践的好处：**
+ 通过适当的支持级别，可以在满足服务水平需求所需的时间范围内获得响应。
+ 作为受支持的客户，如果存在生产问题，您可以上报。
+ 发生意外事件时，软件和服务供应商可协助排除故障。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
为生产工作负载所依赖的所有软件和服务供应商启用支持计划。设置适当的支持计划来满足服务水平需求。对于 AWS 客户，这意味着要在具有生产工作负载的任何账户上激活 AWS Business Support 或更高级别的支持。定期与支持供应商会面，获取有关支持产品、流程和联系人的更新。记录如何向软件和服务供应商请求支持，包括在出现中断时如何上报。实施机制，让支持联系人的信息保持最新。
**客户示例**
在 AnyCompany Retail，所有商用软件和服务依赖项均有支持计划。例如，他们在具有生产工作负载的所有账户上都激活了 AWS Enterprise Support。如果出现问题，任何开发人员都可以提出支持案例。有一个 Wiki 页面，其中包含有关如何请求支持、向谁发出通知以及加快处理案例最佳实践的信息。
**实施步骤**
1. 与组织内的利益相关方合作确定工作负载所依赖的软件和服务供应商。记录这些依赖项。
1. 确定工作负载的服务水平需求。选择与需求匹配的支持计划。
1. 对于商用软件和服务，与供应商一起制定支持计划。
1. 为所有生产账户订阅 AWS Business Support 或更高级别的支持，可以让 AWS 支持 更快响应，强烈建议订阅此支持。如果没有高级支持，则必须制定行动计划来处理问题，而这需要 AWS 支持 的帮助。AWS 支持 提供工具和技术的组合、人员和计划，旨在主动协助您优化性能、降低成本和加快创新速度。此外，AWS Business Support 还提供其它优势，包括 API 对 AWS Trusted Advisor 和 AWS Health 的访问权限以便与系统进行编程集成，以及其它访问方法，例如 AWS 管理控制台和 Amazon EventBridge 渠道。
1. 在知识管理工具中记录支持计划。包括如何请求支持、在提出支持案例时向谁发出通知以及在发生意外事件时如何上报。Wiki 是一种很好的机制，让任何人都可以在发现支持流程或联系人的更改时对文档进行必要的更新。
**实施计划的工作量级别：**低。大部分软件和服务供应商都提供选择加入的支持计划。在知识管理系统中记录和分享支持最佳实践，可以确认团队是否知道在出现生产问题时该怎么做。
## 资源
**相关最佳实践：**
+ [OPS02-BP02 确定流程和程序负责人](ops_ops_model_def_proc_owners.md)
**相关文档：**
+ [AWS 支持 Plans](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)
**相关服务：**
+ [AWS Business Support](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS Enterprise Support](https://aws.amazon.com/premiumsupport/plans/enterprise/)