# 变更管理
**Topics**
+ [REL 6. 如何监控工作负载资源？](rel-06.md)
+ [REL 7. 如何设计工作负载以适应需求变化？](rel-07.md)
+ [REL 8. 您如何实施更改？](rel-08.md)
# REL 6. 如何监控工作负载资源？
日志和指标是深入了解工作负载运行状况的强大工具。您可以将工作负载配置为监控日志和指标，并在超过阈值或发生重大事件时发送通知。通过监控，您的工作负载可以发现超出低性能阈值和发生故障的情形，从而自动恢复以做出响应。
**Topics**
+ [REL06-BP01 为工作负载监控全部组件（生成）](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 定义与计算指标（聚合）](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 发送通知（实时处理和报警）](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 自动响应（实时处理和警报）](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 分析日志](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 定期审核监控范围和指标](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 对系统中的请求进行端到端跟踪监控](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 为工作负载监控全部组件（生成）
使用 Amazon CloudWatch 或第三方工具监控工作负载组件。使用 AWS Health 控制面板监控 AWS 服务。
应监控工作负载的全部组件，包括前端、业务逻辑和存储层。定义关键指标，描述如何将其从日志中提取出来（如有必要），并为对应的警报事件设置阈值。确保指标与工作负载的关键性能指标（KPI）相关，并使用指标和日志来识别服务性能下降的早期预警信号。例如，与业务成果相关的指标（例如每分钟成功处理的订单数）可以比技术指标（例如 CPU 利用率）更快地表明工作负载问题。使用 AWS Health 控制面板可提供 AWS 资源底层的 AWS 服务性能和可用性的个性化视图。
云中监控创造新的机会。大多数云提供商都开发了可自定义的挂钩，可以提供见解来帮助您监控多层工作负载。Amazon CloudWatch 等 AWS 服务应用统计和机器学习算法来持续分析系统和应用程序的指标，只需最少的用户干预即可确定正常基线和表面异常。异常检测算法将指标的季节性变化和趋势变化考虑在内。
AWS 提供了大量的监控和日志信息，这些信息可用于定义工作负载特定的指标、需求变化流程，也助于采用机器学习技术，无论是否具备机器学习专业知识如何。
此外，还可监控所有外部端点，确保这些端点独立于基本实施。这种主动监控可通过综合事务实现（有时被称为*用户金丝雀*，但与金丝雀部署不同），这些事务会按照工作负载的客户端所执行的操作，定期执行许多常见任务。确保这些任务的持续时间较短，不要让工作负载在测试期间过载。Amazon CloudWatch Synthetics 让您可以[创建 Synthetics 金丝雀](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)，以便对端点和 API 进行监控。您还可以整合 Synthetics 金丝雀客户端节点和 AWS X-Ray 控制台，精确定位哪些 Synthetics 金丝雀遇到错误、故障，或对指定时段的速率进行限制的问题。
**期望结果：**
收集并使用来自工作负载所有组件的关键指标，确保工作负载的可靠性和最佳的用户体验。若能检测到工作负载无法实现业务成果，可快速宣布发生灾难并从事件中恢复。
**常见反模式：**
+ 仅监控连接到工作负载的外部接口。
+ 不生成任何工作负载特定的指标，只依靠工作负载使用的 AWS 服务所提供的指标。
+ 仅使用工作负载中的技术指标，而不监控与工作负载带来的非技术性 KPI 相关的任何指标。
+ 依靠生产流量和简单的运行状况检查来监控并评估工作负载状态。
**建立此最佳实践的好处：**在工作负载的各个层级进行监控，便于更快地预测并解决构成工作负载的组件中的问题。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
1. **启用日志记录（如适用）。**应从工作负载的所有组件获取监控数据。启用其他日志记录（例如 S3 访问日志），让工作负载记录工作负载特定的数据。收集来自 Amazon ECS、Amazon EKS、Amazon EC2、弹性负载均衡、AWS Auto Scaling 和 Amazon EMR 等服务的 CPU、网络 I/O 和磁盘 I/O 平均值的指标。有关向 CloudWatch 发布指标的 AWS 服务列表，请参阅[发布 CloudWatch 指标的 AWS 服务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)。
1. **审查所有默认指标并探究任何数据收集欠缺。**每项服务都会生成默认指标。通过收集默认指标，您可以更好地了解工作负载组件之间的依赖关系，以及组件的可靠性和性能对工作负载的影响。您可使用 AWS CLI 或 API 向 CloudWatch [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。
1. **评估所有指标，决定要针对工作负载中每项 AWS 服务的哪些指标发出警报。**您可以选择对工作负载可靠性有重大影响的指标子集。关注关键指标和阈值有助于细化[警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)数量，也助于尽量减少误报。
1. **定义警报以及在调用警报之后工作负载的恢复流程。**通过定义警报，您可以快速通知、上报和执行必要的步骤，以便从事件中恢复并达到规定的恢复时间目标（RTO）。您可以使用 [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)调用自动工作流，并根据定义的阈值启动恢复程序。
1. **探索使用综合事务来收集有关工作负载状态的相关数据。**综合监控遵循相同的路线并执行与客户相同的操作，让您能够持续验证客户体验，即使应用程序中没有任何客户流量。使用[综合事务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)，您可以早于客户先行发现问题。
## 资源
**相关最佳实践：**
+ [REL11-BP03 自动修复所有层](rel_withstand_component_failures_auto_healing_system.md)
**相关文档：**
+ [Getting started with your AWS Health Dashboard – Your account health](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [发布 CloudWatch 指标的 AWS 服务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Access Logs for Your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Access logs for your application load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [访问 AWS Lambda 的 Amazon CloudWatch Logs](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Amazon S3 服务器访问日志记录](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Enable Access Logs for Your Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Exporting log data to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [在 Amazon EC2 实例上安装 CloudWatch 代理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Using Amazon CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [使用金丝雀（Amazon CloudWatch Synthetics）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [What are Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**用户指南：**
+ [创建跟踪](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Monitoring memory and disk metrics for Amazon EC2 Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [将 CloudWatch Logs 与容器实例结合使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [VPC 流日志](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [What is Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [什么是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**相关博客：**
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**相关示例：**
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Observability 讲习会](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 定义与计算指标（聚合）
从工作负载组件收集指标和日志，并从中计算相关的聚合指标。这些指标为工作负载提供了广泛而深入的可观测性，并可以显著提高韧性态势。
可观测性不仅仅是从工作负载组件中收集指标以及能够查看指标和针对指标发出警报。其最终目的是对工作负载的行为进行全面的了解。此类行为信息来自工作负载中的所有组件，包括它们所依赖的云服务、精心制定的日志和指标。这些数据使您能够监督工作负载的整体行为，并可以非常详细地了解每个组件与每个工作单元的交互情况。
**期望结果：**
+ 可以从工作负载组件和 AWS 服务依赖关系中收集日志，然后将其发布到一个便于访问和处理的中心位置。
+ 日志包含高保真和准确的时间戳。
+ 日志包含有关处理上下文的相关信息，例如跟踪标识符、用户或账户标识符以及远程 IP 地址。
+ 可以从日志中创建聚合指标，这些指标从高层次视角表示工作负载的行为。
+ 可以查询聚合的日志，以获得有关工作负载的深入和相关的见解，并确定实际和潜在的问题。
**常见反模式：**
+ 您未从运行工作负载的计算实例或工作负载使用的云服务中收集相关日志或指标。
+ 您忽略了与业务关键绩效指标（KPI）相关的日志和指标的收集。
+ 您单独分析与工作负载相关的遥测数据，而没有采用聚合和关联。
+ 您让指标和日志过快过期，这会阻碍趋势分析和识别反复出现的问题。
**建立这些最佳实践的好处：**您可以检测更多异常情况，并使工作负载的不同组件之间的事件和指标相关联。您可以根据日志中包含的信息，从工作负载组件中创建见解，而这些信息通常仅在指标中不可用。通过大规模查询日志，您可以更快地确定失败原因。
**在未建立这些最佳实践的情况下暴露的风险等级：**高
## 实施指导
确定与您的工作负载及其组件相关的遥测数据来源。这些数据不仅来自发布指标的组件，例如您的操作系统（OS）和应用程序运行时（例如 Java），还来自应用程序和云服务日志。例如，Web 服务器通常会记录每个请求以及诸如时间戳、处理延迟、用户 ID、远程 IP 地址、路径和查询字符串等详细信息。这些日志中的详细程度有助于您执行详细的查询，并生成原本可能无法得到的指标。
使用适当的工具和流程收集指标和日志。在 Amazon EC2 实例上运行的应用程序生成的日志可以由 [Amazon CloudWatch 代理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)等代理收集，并发布到 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 等中央存储服务。[AWS Lambda](https://aws.amazon.com/lambda/) 和 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) 等 AWS 托管式计算服务会自动将日志发布到 CloudWatch Logs。为工作负载使用的 AWS 存储和处理服务启用日志收集，如 [Amazon CloudFront](https://aws.amazon.com/cloudfront/)、[Amazon S3](https://aws.amazon.com/s3/)、[弹性负载均衡](https://aws.amazon.com/elasticloadbalancing/)和 [Amazon API Gateway](https://aws.amazon.com/api-gateway/)。
使用*[维度](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)* 丰富遥测数据，维度有助于您更清楚地看到行为规律，并将相关问题隔离到相关组件组中。添加后，您可以更详细地观察组件行为，检测相关的故障，并采取适当的补救措施。有用维度的示例包括可用区、EC2 实例 ID 和容器任务或容器组（pod）ID。
收集指标和日志后，您可以编写查询并从中生成聚合指标，从而为正常和异常行为提供有用的见解。例如，您可以使用 [Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 从应用程序日志中得出自定义指标，使用 [Amazon CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) 大规模查询您的指标，使用 [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) 从容器化应用程序和微服务中收集、聚合和汇总指标和日志，或者，如果您使用的是 AWS Lambda 函数，则可以使用 [Amazon CloudWatch Lambda 洞察](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html)。要创建聚合错误率指标，可以在每次在组件日志中发现错误响应或消息时递增计数器，或者计算现有错误率指标的聚合值。可以使用这些数据来生成显示*尾部行为* 的直方图，例如性能最差的请求或进程。还可以使用 CloudWatch Logs [anomaly detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html) 等解决方案实时扫描这些数据，来发现异常规律。这些见解可以放在控制面板上，以便根据您的需求和偏好进行整理。
查询日志有助于您了解工作负载组件如何处理特定的请求，并揭示影响工作负载韧性的请求规律或其它上下文。根据您对应用程序和其它组件行为的了解，提前研究和准备查询可能很有用，这样您就可以更轻松地根据需要运行它们。例如，使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)，您能够以交互方式搜索和分析存储在 CloudWatch Logs 中的日志数据。还可以使用 [Amazon Athena](https://aws.amazon.com/athena/) 查询来自多个来源（包括[许多 AWS 服务](https://docs.aws.amazon.com/athena/latest/ug/querying-aws-service-logs.html)）的日志，数据量可达 PB 级。
在定义日志保留策略时，请考虑历史日志的价值。历史日志有助于确定工作负载性能的长期使用情况和行为规律、回归以及改进领域。永久删除的日志以后无法分析。然而，历史日志的价值往往会随着时间推移而减少。选择的策略应能够适当平衡您的需求，并符合您可能需要遵守的任何法律或合同要求。
### 实施步骤
1. 为您的可观测性数据选择收集、存储、分析和显示机制。
1. 在工作负载的适当组件上安装和配置指标和日志收集器（例如，在 Amazon EC2 实例上和[边车容器](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/)中）。将这些收集器配置为在意外停止时自动重新启动。为收集器启用磁盘或内存缓冲，这样，临时发布失败就不会影响应用程序或导致数据丢失。
1. 在您用作工作负载一部分的 AWS 服务上启用日志记录，并在需要时将这些日志转发到您选择的存储服务。有关详细说明，请参阅相应服务的用户或开发人员指南。
1. 定义与基于遥测数据的工作负载相关的操作指标。这些指标可能基于从工作负载组件发出的直接指标，其中可能包括与业务 KPI 相关的指标，也可能基于聚合计算的结果，例如总和、比率、百分位数或直方图。使用日志分析器计算这些指标，并根据需要将其放在控制面板上。
1. 根据需要准备相应的日志查询，来分析工作负载组件、请求或事务行为。
1. 为组件日志定义并启用日志保留策略。当日志的时间超过策略允许的时间时，定期删除日志。
## 资源
**相关最佳实践：**
+ [REL06-BP01 为工作负载监控全部组件（生成）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 发送通知（实时处理和报警）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL06-BP04 自动响应（实时处理和警报）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_automate_response_monitor.html)
+ [REL06-BP05 分析日志](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_storage_analytics.html)
+ [REL06-BP06 定期审核监控范围和指标](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_review_monitoring.html)
+ [REL06-BP07 对系统中的请求进行端到端跟踪监控](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html)
**相关文档：**
+ [说明 Amazon CloudWatch 的工作原理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [Amazon Managed Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html)
+ [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)。
+ [Analyzing log data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Amazon CloudWatch Lambda 洞察](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html)
+ [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)
+ [使用 CloudWatch Metrics Insights 查询您的指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
+ [适用于 OpenTelemetry 的 AWS Distro](https://aws.amazon.com/otel/)
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Searching and Filtering Log Data](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Sending Logs Directly to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
**相关讲习会：**
+ [One Observability 讲习会](https://observability.workshop.aws/)
**相关工具：**
+ [AWS Distro for OpenTelemetry (GitHub)](https://aws-otel.github.io/)
# REL06-BP03 发送通知（实时处理和报警）
当组织检测到潜在问题时，会向相应的人员和系统发送实时通知和警报，以便快速有效地处理这些问题。
**期望结果：**通过根据服务和应用程序指标配置相关警报，可对运维事件做出快速响应。当超出警报阈值时，相应的人员和系统会收到通知，以便解决潜在的问题。
**常见反模式：**
+ 配置的警报阈值过高，导致无法发送重要通知。
+ 配置的警报阈值过低，导致通知过多，而重要警报无法得到处理。
+ 使用情况发生变化时不更新警报及其阈值。
+ 对于最好通过自动操作来处理的警报，向人员发送通知而不是生成自动操作，导致发送的通知过多。
**建立此最佳实践的好处：**通过向相应的人员和系统发送实时通知和警报，可以及早发现问题并快速处理运维方面的意外事件。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
工作负载应配备实时处理和报警功能，从而更及时地检测到可能影响应用程序可用性的问题，并充当自动响应的触发器。组织可以通过使用定义的指标创建警报来执行实时处理和报警，以便在发生重大事件或指标超过阈值时收到通知。
[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 有助于您使用基于静态阈值、异常检测和其他标准的 CloudWatch 警报创建[指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)和复合警报。有关可以使用 CloudWatch 配置的警报类型的更多详细信息，请参阅 [CloudWatch 文档的警报部分](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。
您可以使用 [CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)为团队自定义 AWS 资源指标和警报的视图。通过 CloudWatch 控制台中的可自定义主页，您可以在单一视图中监控多个区域的资源。
警报可执行一项或多项操作，例如向 [Amazon SNS 主题](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)发送通知、执行 [Amazon EC2](https://aws.amazon.com/ec2/) 操作或 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 操作，或在 AWS Systems Manager 中[创建 OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 或[事件](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
Amazon CloudWatch 使用 [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 在警报状态发生变化时发送通知，提供从发布者（生产者）到订阅用户（使用者）的信息传递。要了解有关设置 Amazon SNS 通知的更多信息，请参阅 [Configuring Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html)。
每当 CloudWatch 警报被创建、更新、删除或警报状态发生变化时，CloudWatch 都会发送 [EventBridge](https://aws.amazon.com/eventbridge/) [事件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html)。您可以将 EventBridge 与这些事件结合使用来创建执行操作的规则，例如，每当警报状态发生变化时通知您，或者使用 [Systems Manager 自动化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)在账户中自动触发事件。
随时了解 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 的最新信息。AWS Health 是有关 AWS 云资源运行状况的权威信息来源。使用 AWS Health 可获取任何已确认的服务事件的通知，以便您可以快速采取措施来减轻任何影响。通过 [AWS 用户通知服务](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) 创建要发送到电子邮件和聊天渠道且契合目标的 AWS Health 事件通知，并以编程方式[通过 Amazon EventBridge 与监控和警报工具](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)集成。如果您使用 AWS Organizations，则跨账户汇总 AWS Health 事件。
**EventBridge 和 Amazon SNS 的使用时机**
EventBridge 和 Amazon SNS 都可用于开发事件驱动型应用程序，您可以根据自己的具体需求进行选择。
如果想要构建能够对自己的应用程序、SaaS 应用程序和 AWS 服务中的事件做出反应的应用程序，建议使用 Amazon EventBridge。EventBridge 是唯一直接与第三方 SaaS 合作伙伴集成的基于事件的服务。EventBridge 还可以自动从 200 多项 AWS 服务中提取事件，无需开发者在其账户中创建任何资源。
EventBridge 使用已定义的基于 JSON 的事件结构，有助于您创建应用于整个事件主体的规则，以便选择要转发到[目标](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)的事件。EventBridge 目前支持 20 多项 AWS 服务作为目标，包括 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)、[Amazon SQS](https://aws.amazon.com/sqs/)、Amazon SNS、[Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 和 [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)。
对于需要高扇出（数千或数百万个端点）的应用程序，建议使用 Amazon SNS。常见的一种模式是，客户将 Amazon SNS 用作规则的目标，来筛选所需的事件并扇出到多个端点。
消息是非结构化的，可以采用任意格式。Amazon SNS 支持将消息转发到六种不同类型的目标，包括 Lambda、Amazon SQS、HTTP/S 端点、短信、移动推送和电子邮件。Amazon SNS [典型延迟不超过 30 毫秒](https://aws.amazon.com/sns/faqs/)。有许多 AWS 服务通过配置服务来发送 Amazon SNS 消息（超过 30 项服务，包括 Amazon EC2、[Amazon S3](https://aws.amazon.com/s3/) 和 [Amazon RDS](https://aws.amazon.com/rds/)）。
### 实施步骤
1. 使用 [Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)创建警报。
1. 指标警报可监控单个 CloudWatch 指标或依赖于 CloudWatch 指标的表达式。这种警报会根据在若干时间间隔内，指标或表达式的值与阈值的比较结果，启动一项或多项操作。操作可以是向 [Amazon SNS 主题](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)发送通知、执行 [Amazon EC2](https://aws.amazon.com/ec2/) 操作或 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 操作，或在 AWS Systems Manager 中[创建 OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 或[事件](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
1. 复合警报由一个规则表达式组成，该规则表达式考虑了您创建的其他警报的警报条件。只有满足所有规则条件，复合警报才会进入警报状态。复合警报的规则表达式中指定的警报可以包括指标警报和其他复合警报。复合警报可以在改变状态时发送 Amazon SNS 通知，并且可以在进入警报状态时创建 Systems Manager [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 或[事件](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)，但无法执行 Amazon EC2 Auto Scaling 操作。
1. 设置 [Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)。创建 CloudWatch 警报时，可以包括 Amazon SNS 主题，以便在警报状态发生变化时发送通知。
1. [在 EventBridge 中创建](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)与指定的 CloudWatch 警报相匹配的规则。每条规则都支持多个目标，包括 Lambda 函数。例如，您可以定义一个会在可用磁盘空间不足时启动的警报，通过 EventBridge 规则触发 Lambda 函数来清理空间。有关 EventBridge 目标的更多详细信息，请参阅 [EventBridge targets](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)。
## 资源
**相关的 Well-Architected 最佳实践：**
+ [REL06-BP01 为工作负载监控全部组件（生成）](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 定义与计算指标（聚合）](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL12-BP01 使用行动手册调查故障](rel_testing_resiliency_playbook_resiliency.md)
**相关文档：**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [使用 Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Using Amazon CloudWatch dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [设置 Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [CloudWatch 异常检测](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [CloudWatch Logs data protection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html)
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [Amazon Simple Notification Service](https://aws.amazon.com/sns/)
**相关视频：**
+ [re:Invent 2022 observability 视频](https://www.youtube.com/results?search_query=reinvent+2022+observability)
+ [AWS re:Invent 2022 – Observability best practices at Amazon](https://www.youtube.com/watch?v=zZPzXEBW4P8)
**相关示例：**
+ [One Observability 讲习会](https://observability.workshop.aws/)
+ [Amazon EventBridge to AWS Lambda with feedback control by Amazon CloudWatch Alarms](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern)
# REL06-BP04 自动响应（实时处理和警报）
检测到事件后，利用自动化功能执行操作；例如，更换故障组件。
实施警报的自动实时处理，以便系统可以快速采取纠正措施，并在触发警报时尝试防止故障或服务降级。警报的自动响应可能包括更换故障组件，调整计算容量，将流量重定向到运行状况良好的主机、可用区或其他区域，以及通知操作员。
**期望结果：**识别实时警报，并设置警报的自动处理，以便调用适当措施来维护服务级别目标和服务水平协议（SLA）。自动处理的范围可以是单个组件的自我修复活动，也可以是全站点的失效转移。
**常见反模式：**
+ 没有明确的关键实时警报的清单或目录。
+ 关键警报没有自动响应（例如，当计算资源即将耗尽时自动进行扩展）。
+ 警报响应操作相互矛盾。
+ 操作员在收到警报通知时没有任何标准操作程序（SOP）可以遵循。
+ 不监控配置更改，因为未检测到的配置更改可能会导致工作负载停机。
+ 没有撤消意外配置更改的策略。
**建立此最佳实践的好处：**自动处理警报可以提高系统的韧性。系统会自动采取纠正措施，从而减少手动操作，而手动操作往往是容易出错的人工干预。工作负载的运行符合可用性目标，并减少服务中断。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
为了有效地管理警报并自动进行响应，请根据警报的严重程度和影响对警报进行分类，记录响应程序，并在对任务进行评级之前制定好响应计划。
确定需要特定操作的任务（通常在运行手册中详细说明），并检查所有运行手册和行动手册，判断哪些任务可以自动执行。如果操作可以定义，通常就可以实现自动化。如果操作无法自动化，请在 SOP 中记录手动步骤并对操作员进行培训。不断挑战手动流程，寻找自动化机会，以便制定和维护自动响应警报的计划。
### 实施步骤
1. **创建警报清单：**要获取所有警报的列表，您可以使用 [Amazon CloudWatch 命令](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) `[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)` 来使用 [AWS CLI](https://aws.amazon.com/cli/)。根据设置的警报数量，您可能需要使用分页来检索每个呼叫的警报子集，或者也可以使用 AWS SDK [通过 API 调用](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html)获取警报。
1. **记录所有警报操作：**更新包含所有警报及其操作的运行手册，无论它们是手动还是自动的。[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html) 提供预定义的运行手册。有关运行手册的更多信息，请参阅[使用运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)。有关如何查看运行手册内容的详细信息，请参阅 [View runbook content](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json)。
1. **设置和管理警报操作：**对于任何需要操作的警报，请[使用 CloudWatch SDK 指定自动操作](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html)。例如，您可以通过创建和启用警报操作或禁用警报操作，根据 CloudWatch 警报自动更改 Amazon EC2 实例的状态。
您还可以使用 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) 自动响应系统事件，例如应用程序可用性问题或资源更改。您可以创建规则来指示要关注的事件，以及在事件匹配规则时要执行的操作。可以自动启动的操作包括调用 [AWS Lambda](https://aws.amazon.com/lambda/) 函数、调用 [Amazon EC2](https://aws.amazon.com/ec2/) `Run Command`、将事件中继到 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 以及查看[使用 EventBridge 自动执行 Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html)。
1. **标准操作程序（SOP）：**根据应用程序组件，[AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 会推荐多个 [SOP 模板](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html)。您可以使用这些 SOP 来记录在出现警报时操作员应遵循的所有流程。您还可以根据韧性监测中心的建议[构造 SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html)，前提是有一个具有相关韧性策略的 Resilience Hub 应用程序，以及针对该应用程序的历史韧性评测。针对 SOP 的建议由韧性评测生成。
韧性监测中心与 Systems Manager 结合使用，通过提供大量可用作这些 SOP 基础的 [SSM 文档](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html)，自动执行 SOP 的步骤。例如，韧性监测中心可能会根据现有的 SSM 自动化文档推荐用于添加磁盘空间的 SOP。
1. **使用 Amazon DevOps Guru 执行自动操作：**可以使用 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) 自动监控应用程序资源的异常行为并提供针对性的建议，缩短识别问题和进行修复所需的时间。借助 DevOps Guru，您可以近乎实时地监控来自多个来源的运营数据流，包括 Amazon CloudWatch 指标、[AWS Config](https://aws.amazon.com/config/)、[AWS CloudFormation](https://aws.amazon.com/cloudformation/) 和 [AWS X-Ray](https://aws.amazon.com/xray/)。您还可以使用 DevOps Guru 在 OpsCenter 中自动创建 [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)，并将事件发送到 [EventBridge](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html) 实现更多自动化操作。
## 资源
**相关最佳实践：**
+ [REL06-BP01 为工作负载监控全部组件（生成）](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 定义与计算指标（聚合）](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 发送通知（实时处理和报警）](rel_monitor_aws_resources_notification_monitor.md)
+ [REL08-BP01 对部署等标准活动使用运行手册](rel_tracking_change_management_planned_changemgmt.md)
**相关文档：**
+ [AWS Systems Manager 自动化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Creating an EventBridge Rule That Triggers on an Event from an AWS Resource](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [One Observability 讲习会](https://observability.workshop.aws/)
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [What is Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [使用自动化文档（行动手册）](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
**相关视频：**
+ [AWS re:Invent 2022 – Observability best practices at Amazon](https://www.youtube.com/watch?v=zZPzXEBW4P8)
+ [AWS re:Invent 2020: Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [ Introduction to AWS Resilience Hub](https://www.youtube.com/watch?v=_OTTCOjWqPo)
+ [ Create Custom Ticket Systems for Amazon DevOps Guru Notifications ](https://www.youtube.com/watch?v=Mu8IqWVGUfg)
+ [ Enable Multi-Account Insight Aggregation with Amazon DevOps Guru ](https://www.youtube.com/watch?v=MHezNcTSTbI)
**相关示例：**
+ [Amazon CloudWatch and Systems Manager 讲习会](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US)
# REL06-BP05 分析日志
收集日志文件和指标历史记录并加以分析，获得更全面的趋势和工作负载见解。
Amazon CloudWatch Logs Insights 支持[简单但强大的查询语言](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)，可用于分析日志数据。Amazon CloudWatch Logs 还支持订阅，允许数据无缝流动到 Amazon S3（可在其中使用数据）或 Amazon Athena（可在其中查询数据）。该服务支持查询多种格式。请参阅《Amazon Athena 用户指南》，了解[支持的 SerDes 和数据格式](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html)。针对大型日志文件集的分析，您可以运行 Amazon EMR 集群以执行 PB 级分析。
AWS 合作伙伴和第三方提供了许多用于聚合、处理、存储和分析的工具。这些工具包括 New Relic、Splunk、Loggly、Logstash、CloudHealth 和 Nagios。但是，系统和应用程序日志之外的生成对于每个云提供商，甚至每个服务来说都是独一无二的。
监控过程中常常被忽视的部分是数据管理。您需要确定数据监控的保留要求，然后相应地应用生命周期策略。Amazon S3 支持 S3 存储桶级别的生命周期管理。此生命周期管理可以通过不同的方式应用到存储桶中的不同路径。您可以在生命周期临近结束时，将数据转移到 Amazon Glacier 进行长期存储，然后在保留期结束后让它们过期。S3 Intelligent-Tiering 存储类旨在通过将数据自动移动到最具成本效益的访问层来优化成本，却不会对性能或运营开销产生影响。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
+ 您可以使用 CloudWatch Logs Insights，通过交互方式搜索并分析 Amazon CloudWatch Logs 中的日志数据。
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ 使用 Amazon CloudWatch Logs 将日志发送到 Amazon S3 以供使用，或发送到 Amazon Athena 以查询数据。
+ [如何使用 Athena 分析我的 Amazon S3 服务器访问日志？](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ 为服务器访问日志存储桶创建 S3 生命周期策略。配置生命周期策略以定期删除日志文件。这样做可以减少 Athena 为每个查询分析的数据量。
+ [如何为 S3 存储桶创建生命周期策略？](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## 资源
**相关文档：**
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [如何为 S3 存储桶创建生命周期策略？](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [如何使用 Athena 分析我的 Amazon S3 服务器访问日志？](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [One Observability 讲习会](https://observability.workshop.aws/)
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 定期审核监控范围和指标
经常审核工作负载监控的实施情况，并根据工作负载及其架构的发展进行更新。定期审计监控有助于降低遗漏或忽视故障指标的风险，并进一步协助工作负载实现其可用性目标。
有效的监控以关键业务指标为基础，这些指标会随着业务优先级变化而变化。监控审核过程应强调服务级别指标（SLI），并纳入来自基础设施、应用程序、客户和用户的见解。
**期望结果：**您拥有有效的监控策略，该策略会定期进行审核和更新，并在发生任何重大事件或变更后进行更新。随着工作负载和业务需求发生变化，您可以验证关键的应用程序运行状况指标是否仍然相关。
**常见反模式：**
+ 您仅收集默认指标。
+ 您设置了监控策略，但从不对其进行审核。
+ 部署重大更改时，您不讨论监控。
+ 您信任过时的指标来确定工作负载运行状况。
+ 由于指标和阈值过时，误报的警报让您的运营团队不堪重负。
+ 您对未受监控的应用程序组件缺乏可观测性。
+ 在监控中，您只关注低级技术指标，而不关注业务指标。
**建立这种最佳实践的好处：**当您定期审核监控时，您可以预测潜在的问题，并验证自己是否有能力发现这些问题。它还可让您找出之前的审核中可能错过的盲点，从而进一步提高您发现问题的能力。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
在 [operational readiness review (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 过程中审核监控指标和范围。按照一致的时间表定期进行运营准备情况审查，以评估您当前的工作负载与您配置的监控之间是否存在任何差距。定期开展运营性能审查和知识共享，有助于增强运营团队提高绩效的能力。验证现有的警报阈值是否仍然适合，并检查运营团队是否收到误报的警报，或者是否未监控应用程序的应受监控的各个方面。
[Resilience Analysis Framework](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html) 提供了有用的指导，有助于您驾驭整个过程。该框架的重点是确定潜在的故障模式，以及可用于减轻其影响的预防和纠正控制措施。这些知识有助于您确定要监控和发出警报的正确指标和事件。
### 实施步骤
1. 计划并执行工作负载控制面板常规检查。您可能对检查深度具有不同的安排。
1. 检查指标中的趋势。对比指标值与历史值，了解是否有趋势表明需要调查某些情况。这种情况的示例包括延迟增加、主要业务功能减少以及故障响应增加。
1. 检查指标中是否存在离群值和异常值，这些值可能会被平均值或中位数掩盖。查看时间范围内的最高值和最低值，并调查观测结果远超正常范围的原因。随着您持续消除这些原因，您可以收紧预期的指标范围，以提高工作负载性能的一致性。
1. 查找清晰的行为变化。指标数量或方向的立即更改可能表示应用程序已发生变化，或者出现了需要添加额外指标进行跟踪的外部因素。
1. 审核当前的监控策略是否仍然与应用程序保持相关。根据对先前事件的分析（或韧性分析框架），评测该应用程序中是否还有其它方面应纳入监控范围。
1. 查看您的真实用户监控（RUM）指标，以确定应用程序功能覆盖范围是否存在任何差距。
1. 审查您的更改管理流程。如有必要，请更新相关过程，来包括应在批准更改之前执行的监控分析步骤。
1. 实施监控审核，以此作为运营准备情况审查和错误更正流程的一部分。
## 资源
**相关最佳实践**
+ [REL06-BP01 为工作负载监控全部组件（生成）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP02 定义与计算指标（聚合）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_aggregation.html)
+ [REL06-BP07 对系统中的请求进行端到端跟踪监控](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html)
+ [REL12-BP02 执行事后分析](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_rca_resiliency.html)
+ [REL12-BP06 定期进行 GameDay 活动](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_game_days_resiliency.html)
**相关文档：**
+ [Why you should develop a correction of error (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
+ [使用 Amazon CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [构建控制面板以获取操作可见性](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/?did=ba_card&trk=ba_card)
+ [Advanced Multi-AZ Resilience Patterns - Gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability 讲习会](https://observability.workshop.aws/)
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Using Amazon CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [AWS Observability Best Practices](https://aws-observability.github.io/observability-best-practices/)
+ [Resilience Analysis Framework](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)
+ [Resilience Analysis Framework - Observability](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/observability.html)
+ [Operational Readiness Review - ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
# REL06-BP07 对系统中的请求进行端到端跟踪监控
跟踪各个服务组件的请求处理情况，这样产品团队便能够更轻松地分析和调试问题并提高性能。
**期望结果：**针对所有组件全面跟踪工作负载，实现轻松调试，进而通过简化发现错误根本原因的过程，缩短错误的[平均解决时间](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)（MTTR）和延迟。采用端到端的跟踪方式，有助于更快地发现受影响的组件，并详细深入地了解造成错误或延迟的根本原因。
**常见反模式：**
+ 只针对部分组件而不是全部组件进行跟踪。例如，如果不跟踪 AWS Lambda，团队可能无法清楚地了解高峰工作负载中冷启动所造成的延迟。
+ Synthetics 金丝雀或真实用户监控（RUM）未配置跟踪功能。没有金丝雀或 RUM，跟踪分析中会忽略客户端交互遥测数据，这样得出的性能概况就不够完整。
+ 混合工作负载包括云原生跟踪工具和第三方跟踪工具，但尚未采取措施来选择并完全集成单个跟踪解决方案。根据所选跟踪解决方案，应使用云原生跟踪 SDK 来检测非云原生组件，或者应将第三方工具配置为摄取云原生跟踪遥测数据。
**建立此最佳实践的好处：**当开发团队收到问题提醒时，能够查看系统组件交互情况的全貌，包括各个组件在日志记录、性能和故障方面的相关性。由于跟踪有助于直观且轻松地找出根本原因，因此调查根本原因所花费的时间得以减少。在解决问题时，团队如果能详细了解组件的交互情况，就可以更快地做出更好的决策。分析系统跟踪数据有助于改进多种决策，例如何时调用灾难恢复（DR）失效转移，或者在何处实施自我修复策略最合适等，最终势必能够提高客户对服务的满意度。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
团队在运行分布式应用程序时，能够借助跟踪工具来建立关联标识符、收集请求跟踪数据，以及构建互联组件的服务地图。请求跟踪中应该涵盖所有应用程序组件，包括服务客户端、中间件网关和事件总线、计算组件以及存储（包括键/值存储和数据库）。在端到端跟踪配置中，纳入 Synthetics 金丝雀和真实用户监控来衡量远程客户端交互情况和延迟，这样您就能够根据服务水平协议和目标准确地评估系统性能。
您可以使用 [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 和 [Amazon CloudWatch 应用程序监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)检测服务，在请求通过应用程序时提供请求的完整视图。X-Ray 会收集应用程序遥测，有助于跨有效负载、函数、跟踪、服务、API 对其进行可视化和筛选，并且可以通过无代码或低代码的方式系统组件启用。CloudWatch 应用程序监控包括 ServiceLens，可将跟踪与指标、日志和警报集成。CloudWatch 应用程序监控还包括用于监控端点和 API 的 Synthetics，以及用于检测 Web 应用程序客户端的真实用户监控。
## 实施步骤
+ 在所有支持的本机服务上使用 AWS X-Ray，例如 [Amazon S3、AWS Lambda 和 Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)。这些 AWS 服务可使用基础设施即代码、AWS SDK 或 AWS 管理控制台 来启用 X-Ray。
+ 检测应用程序（[适用于 OpenTelemetry 的 AWS Distro 和 X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)）或第三方收集代理。
+ 查看《[AWS X-Ray Developer Guide](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)》，了解编程语言特定的实施。这些文档部分详细介绍了如何检测 HTTP 请求、SQL 查询和应用程序编程语言特定的其他进程。
+ 使用适用于 [Amazon CloudWatch Synthetics 金丝雀](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 和 [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 的 X-Ray 追踪，对最终用户客户端通过下游 AWS 基础设施的请求路径进行分析。
+ 根据资源运行状况和金丝雀遥测数据来配置 CloudWatch 指标和警报，这样团队就能够快速收到问题提醒，然后使用 ServiceLens 深入探究跟踪数据和服务地图。
+ 如果使用第三方工具作为主要的追踪解决方案，则将 X-Ray 与 [Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/)、[New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/) 或 [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics) 等第三方追踪工具集成。
## 资源
**相关最佳实践：**
+ [REL06-BP01 为工作负载监控全部组件（生成）](rel_monitor_aws_resources_monitor_resources.md)
+ [REL11-BP01 监控工作负载的所有组件以检测故障](rel_withstand_component_failures_monitoring_health.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/CloudWatch-Application-Monitoring-Sections.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Integrating AWS X-Ray with other AWS services](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)
+ [AWS Distro for OpenTelemetry and AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)
+ [Amazon CloudWatch：使用综合监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon CloudWatch：使用 CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Set up Amazon CloudWatch synthetics canary and Amazon CloudWatch alarm](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html)
+ [Availability and Beyond: Understanding and Improving the Resilience of Distributed Systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US)
**相关视频：**
+ [AWS re:Invent 2022 – How to monitor applications across multiple accounts ](https://www.youtube.com/watch?v=kFGOkywu-rw)
+ [ How to Monitor your AWS Applications ](https://www.youtube.com/watch?v=UxWU9mrSbmA)
**相关工具：**
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [Amazon CloudWatch](https://aws.amazon.com/pm/cloudwatch/)
+ [Amazon Route 53](https://aws.amazon.com/route53/)
# REL 7. 如何设计工作负载以适应需求变化？
可扩展工作负载提供了自动添加或删除资源的弹性，因此资源在任何给定时间点都非常符合当前需求。
**Topics**
+ [REL07-BP01 在获取或扩展资源时利用自动化](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 在检测到对工作负载的破坏时获取资源](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 在检测到某个工作负载需要更多资源时获取资源](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 对工作负载进行负载测试](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 在获取或扩展资源时利用自动化
云端可靠性的基石是基础设施和资源的程序化定义、预置和管理。自动化有助于您简化资源预置，促进一致和安全的部署，并在整个基础设施中扩展资源。
**期望结果：**管理基础设施即代码（IaC）。您可以在版本控制系统（VCS）中定义和维护基础设施代码。您可以将预置 AWS 资源的过程委托给自动机制，并利用托管式服务，例如应用程序负载均衡器（ALB）、网络负载均衡器（NLB）和自动扩缩组。您可以使用持续集成/持续交付（CI/CD）管道来预置资源，以便代码更改自动启动资源更新，包括对自动扩缩配置的更新。
**常见反模式：**
+ 您使用命令行或在 AWS 管理控制台中（也称为*单击操作*）手动部署资源。
+ 您将应用程序组件或资源紧密耦合，从而创建了不灵活的架构。
+ 您实施的扩展策略不灵活，无法适应不断变化的业务需求、流量规律或新的资源类型。
+ 您手动估算容量来满足预期需求。
**建立这种最佳实践的好处**：基础设施即代码（IaC）支持以编程方式定义基础设施。这有助于您在与应用程序更改相同的软件开发生命周期中管理基础设施更改，从而提高一致性和可重复性，并降低手动、易出错任务的风险。通过使用自动交付管道实施 IaC，可以进一步简化预置和更新资源的流程。您无需手动干预，即可可靠、高效地部署基础设施更新。在扩展资源以满足不断变化的需求时，这种敏捷性尤其重要。
您可以结合使用 IaC 和交付管道来实现动态、自动的资源扩展。通过监控关键指标和应用预定义的扩展策略，自动扩缩可以根据需要自动预置或取消预置资源，从而提高性能和成本效益。这样可以减少因应用程序或工作负载要求发生变化而导致手动错误或延迟的可能性。
IaC、自动交付管道和自动扩缩相结合，有助于组织放心地预置、更新和扩展其环境。这种自动化对于维护响应迅速、富有韧性和高效管理的云基础设施至关重要。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要为 AWS 架构的 CI/CD 管道和基础设施即代码（IaC）设置自动化，请选择版本控制系统（例如 Git）来存储 IaC 模板和配置。这些模板可以使用诸如 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 之类的工具编写。首先，请在这些模板中定义基础设施组件（例如 AWS VPC、Amazon EC2 Auto Scaling 组和 Amazon RDS 数据库）。
接下来，将这些 IaC 模板与 CI/CD 管道集成，以实现部署过程的自动化。[AWS CodePipeline](https://aws.amazon.com/codepipeline/) 提供了无缝的 AWS 原生解决方案，您也可以使用其它第三方 CI/CD 解决方案。创建一个在版本控制存储库发生更改时激活的管道。将管道配置为包括以下各个阶段：整理和验证 IaC 模板、将基础设施部署到暂存环境、运行自动测试以及最终部署到生产环境。必要时纳入审批步骤，以保持对变更的控制。这种自动化的管道不仅加快了部署速度，而且促进了跨环境的一致性和可靠性。
在 IaC 中配置诸如 Amazon EC2 实例、Amazon ECS 任务和数据库副本等资源的自动扩缩，以根据需要提供自动横向扩展和横向缩减。这种方法通过根据需求动态调整资源，来增强应用程序可用性和性能并优化成本。有关支持的资源列表，请参阅 [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 和 [AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html)。
### 实施步骤
1. 创建并使用源代码存储库，来存储控制基础设施配置的代码。提交对此存储库的更改，来反映您要进行的任何持续更改。
1. 选择基础设施即代码解决方案（例如 AWS CloudFormation），以使您的基础设施保持最新状态并检测与预期状态的不一致性（偏差）。
1. 将 IaC 平台与 CI/CD 管道集成来实现部署自动化。
1. 确定并收集用于自动扩缩资源的适当指标。
1. 使用适用于工作负载组件的横向扩展和横向缩减策略，来配置资源的自动扩缩。考虑使用计划的扩展来实现可预测的使用规律。
1. 监控部署来检测故障和回归。在 CI/CD 平台中实施回滚机制，以便在必要时还原更改。
## 资源
**相关文档：**
+ [AWS Auto Scaling: How Scaling Plans Work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: products that can be used with auto scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Using a load balancer with an Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [What Is AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [什么是 AWS Auto Scaling？](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [What is Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [What is Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [什么是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [什么是网络负载均衡器？](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [什么是应用程序负载均衡器？](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Integrating Jenkins with AWS CodeBuild and AWS CodeDeploy](https://aws.amazon.com/blogs/devops/setting-up-a-ci-cd-pipeline-by-integrating-jenkins-with-aws-codebuild-and-aws-codedeploy/)
+ [Creating a four stage pipeline with AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-four-stage-pipeline.html)
**相关视频：**
+ [Back to Basics: Deploy Your Code to Amazon EC2](https://www.youtube.com/watch?v=f2wvEQ_sWS8)
+ [AWS Supports You \$1 Starting Your Infrastructure as Code Solution Using AWS CloudFormation Templates](https://www.youtube.com/watch?v=bgfx76jr7tA)
+ [Streamline Your Software Release Process Using AWS CodePipeline](https://www.youtube.com/watch?v=zMa5gTLrzmQ)
+ [Monitor AWS Resources Using Amazon CloudWatch Dashboards](https://www.youtube.com/watch?v=I7EFLChc07M)
+ [Create Cross Account & Cross Region CloudWatch Dashboards \$1 Amazon Web Services](https://www.youtube.com/watch?v=eIUZdaqColg)
# REL07-BP02 在检测到对工作负载的破坏时获取资源
如果可用性受到影响，在必要时被动扩展资源，从而还原工作负载的可用性。
首先，您必须配置运行状况检查和关于此类检查的标准，表示在什么时候可用性会因缺少资源而受到影响。然后，通知适当的人员手动扩展资源，或启动自动化以对其进行自动扩展。
可以根据工作负载手动调整资源规模（例如，通过 AWS 管理控制台 或 AWS CLI 更改自动扩缩组中 EC2 实例的数量，或者修改 DynamoDB 表的吞吐量）。但是，应尽量采用自动化技术（请参阅**在获取或扩展资源时利用自动化**）。
**期望结果：**在检测到故障或客户体验降级时，启动扩缩活动（自动或手动）来恢复可用性。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
对工作负载中的所有组件实施可观测性和监控，以监控客户体验并检测故障。定义用于扩展所需资源的手动或自动程序。有关更多信息，请参阅 [REL11-BP01 监控工作负载的所有组件以检测故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)。
### 实施步骤
+ 定义扩展所需资源的手动或自动程序。
+ 扩缩程序取决于工作负载中不同组件的设计方式。
+ 扩缩程序还因所使用的底层技术而异。
+ 使用 AWS Auto Scaling 的组件可以使用扩缩计划来配置一组用于扩展资源的指令。如果使用 AWS CloudFormation 或向 AWS 资源添加标签，则可以根据应用程序为不同的资源集设置扩缩计划。Auto Scaling 提供了针对每个资源的定制扩展策略建议。创建扩缩计划后，Auto Scaling 结合了动态扩缩和预测性扩缩方法来支持扩缩策略。有关更多详细信息，请参阅 [How scaling plans work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)。
+ Amazon EC2 Auto Scaling 可验证您具有正确数量的 Amazon EC2 实例来处理应用程序负载。您可创建 EC2 实例的集合，称为自动扩缩组。您可以指定每个自动扩缩组中的最小和最大实例数，Amazon EC2 Auto Scaling 会确保您的组永远不会低于或超过这些限制。有关更多详细信息，请参阅 [What is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ Amazon DynamoDB Auto Scaling 会根据实际的流量模式，使用 Application Auto Scaling 服务代表您动态调整预置的吞吐容量。这样表或全局二级索引可以增加预置读取和写入容量处理突增流量，不会受到限制。有关更多详细信息，请参阅[使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)。
## 资源
**相关最佳实践：**
+ [REL07-BP01 在获取或扩展资源时利用自动化](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 监控工作负载的所有组件以检测故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)
**相关文档：**
+ [AWS Auto Scaling: How Scaling Plans Work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 在检测到某个工作负载需要更多资源时获取资源
云计算最有价值的功能之一是能够动态预置资源。
在传统的本地计算环境中，您必须提前确定和预置足够的容量来满足峰值需求。这的确是个问题，因为很昂贵，如果您低估了工作负载的峰值容量需求，则会对可用性构成风险。
在云中，您不必这样做。相反，您可以根据需要预置计算、数据库和其它资源容量，以满足当前和预测的需求。Amazon EC2 Auto Scaling 和 Application Auto Scaling 等自动化解决方案可以根据您指定的指标在线为您提供资源。这可以使扩展过程变得更加轻松和可预测，还可以通过确保始终有足够的可用资源来显著提高工作负载的可靠性。
**期望结果：**您可以配置计算资源和其它资源的自动扩缩来满足需求。您在扩展策略中提供了充足的余量，可以在额外资源上线时应对流量爆增。
**常见反模式：**
+ 您预置固定数量的可扩展资源。
+ 您选择的扩展指标与实际需求不相关。
+ 您未能在扩展计划中提供足够的余量来应对需求爆增。
+ 您的扩展策略添加容量的时间过晚，这会导致容量耗尽和服务降级，同时使额外的资源上线。
+ 您未能正确地配置最小和最大资源计数，这会导致扩展失败。
**建立此最佳实践的好处：**拥有足够的资源来满足当前需求，对于提供工作负载的高可用性和遵守您定义的服务级别目标（SLO）至关重要。自动扩缩可让您提供工作负载所需的适量计算资源、数据库资源和其它资源，以满足当前和预测的需求。您无需确定峰值容量需求，也无需静态分配资源来满足此需求。相反，随着需求增长，您可以分配更多资源来满足需求，在需求下降后，您可以停用资源以降低成本。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
首先，确定工作负载组件是否适合自动扩缩。这些组件之所以称为*可水平扩展*，是因为它们提供的资源相同，行为也相同。水平可扩展组件的示例包括以类似方式配置的 EC2 实例、[Amazon Elastic Container Service（ECS）](https://aws.amazon.com/ecs/)任务以及在 [Amazon Elastic Kubernetes Service（EKS）](https://aws.amazon.com/eks/)上运行的容器组（pod）。这些计算资源通常位于负载均衡器后面，称为*副本*。
其它复制的资源可能包括数据库只读副本、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 表以及 [Amazon ElastiCache](https://aws.amazon.com/elasticache/)（Redis OSS）集群。有关支持的资源的完整列表，请参阅 [AWS services that you can use with Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/integrated-services-list.html)。
对于基于容器的架构，可能需要通过两种不同的方式进行扩展。首先，您可能需要扩展可提供水平可扩展服务的容器。其次，您可能需要扩展计算资源，以便为新容器腾出空间。每个层都有不同的自动扩缩机制。要扩展 ECS 任务，可以使用 [Application Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)。要扩展 Kubernetes 容器组（pod），可以使用 [Pod 水平自动扩缩控制器（HPA）](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)或 [Kubernetes Event-driven Autoscaling (KEDA)](https://keda.sh/)。要扩展计算资源，对于 ECS，可以使用[容量提供程序](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html)，或者对于 Kubernetes，可以使用 [Karpenter](https://karpenter.sh) 或[集群自动扩缩器](https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/)。
接下来，选择您将如何执行自动扩缩。有三个主要选项：基于指标的扩展、计划扩展和预测式扩展。
**基于指标的扩展**
基于指标的扩展根据一个或多个*扩展指标* 的值来预置资源。扩展指标是与工作负载的需求相对应的指标。确定适当扩展指标的一个好方法是在非生产环境中执行负载测试。在负载测试期间，请将可扩展资源的数量保持为固定，并缓慢增加需求（例如，吞吐量、并发性或模拟用户数）。然后，寻找随着需求增长而增加（或减少）的指标，以及相反，即随着需求下降而减少（或增加）的指标。典型的扩展指标包括 CPU 利用率、工作队列深度（例如 [Amazon SQS](https://aws.amazon.com/sqs/) 队列）、活跃用户数量和网络吞吐量。
**注意**
AWS 观察到，对于大多数应用程序，内存利用率会随着应用程序预热而增加，然后达到稳定的值。当需求减少时，内存利用率通常保持较高水平，而不是并行下降。因为内存利用率与两个方向的需求不符（即随需求而增长和下降），因此在选择此指标进行自动扩缩之前，请慎重考虑。
基于指标的扩展是一种*潜在操作*。利用率指标可能需要几分钟才能传播到自动扩缩机制，而这些机制通常要等到明确的需求增加信号后才会做出反应。然后，当自动扩缩器创建新资源时，这些资源可能需要更多时间才能全面投入使用。因此，重要的是不要将扩展指标目标设置为过于接近完全利用率（例如，90% 的 CPU 利用率）。这样做有可能在额外容量上线之前耗尽现有资源容量。为了获得最佳可用性，典型的资源利用率目标可介于 50-70% 之间，具体取决于需求规律以及预置额外资源所需的时间。
**计划扩展**
计划扩展会根据日历或一天中的时间预置或移除资源。它通常用于需求可预测的工作负载，例如工作日工作时间或销售活动期间的峰值利用率。[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) 和 [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) 都支持计划扩展。KEDA 的 [cron scaler](https://keda.sh/docs/latest/scalers/cron/) 支持 Kubernetes 容器组（pod）的计划扩展。
**预测式扩展**
预测式扩展使用机器学习来根据预期的需求自动扩缩资源。预测式扩展分析您提供的利用率指标的历史值，并持续预测其未来值。然后，使用预测值来纵向扩展或缩减资源。[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) 可以执行预测式扩展。
### 实施步骤
1. 确定工作负载组件是否适合自动扩缩。
1. 确定哪种扩展机制最适合工作负载：基于指标的扩展、计划扩展或预测式扩展。
1. 为组件选择适当的自动扩缩机制。对于 Amazon EC2 实例，请使用 Amazon EC2 Auto Scaling。对于其它 AWS 服务，请使用 Application Auto Scaling。对于 Kubernetes 容器组（pod）（例如在 Amazon EKS 集群中运行的容器），可以考虑水平容器组（pod）自动扩缩器（HPA）或 Kubernetes 事件驱动的自动扩缩（KEDA）。对于 Kubernetes 或 EKS 节点，可以考虑 Karpenter 和集群自动扩缩器（CAS）。
1. 对于指标或计划扩展，请进行负载测试，以确定工作负载的相应扩展指标和目标值。对于计划扩展，请确定在您选择的日期和时间所需的资源数量。确定为应对预期的峰值流量所需的最大资源数量。
1. 根据上面收集的信息配置自动扩缩器。有关详细信息，请参阅自动扩缩服务的文档。验证最大和最小扩展限制是否配置正确。
1. 验证扩展配置是否按预期发挥作用。在非生产环境中执行负载测试，观察系统的反应，并根据需要进行调整。在生产环境中启用自动扩缩时，请配置适当的警报来向您通知任何意外行为。
## 资源
**相关文档：**
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Prescriptive Guidance: Load testing applications](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/)
+ [AWS Marketplace: products that can be used with auto scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Predictive Scaling for EC2, Powered by Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Scheduled Scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
# REL07-BP04 对工作负载进行负载测试
采用负载测试方法来衡量扩展活动能否满足工作负载要求。
持续开展负载测试，这一点很重要。负载测试用于发现工作负载的断点并测试工作负载的性能。利用 AWS，您可以轻松设置能够模拟生产工作负载规模的临时测试环境。在云中，您可以根据需要创建一套生产规模等级的测试环境，完成测试，然后停用资源。由于测试环境只需在运行时付费，您模拟真实环境的成本仅为本地测试成本的一小部分。
生产中的负载测试还应该被视为 GameDay 活动的一部分，因为在客户使用量降低的那几个小时内，在场的所有员工都忙于解读结果与处理任何出现的问题，生产系统承受着很大的压力。
**常见反模式：**
+ 对与生产采用不同配置的部署执行负载测试。
+ 仅对单个工作负载分段（而非整个工作负载）执行负载测试。
+ 使用请求子集，而不是具有代表性的实际请求集执行负载测试。
+ 对超出预期负载的较小安全系数执行负载测试。
**建立此最佳实践的好处：**您知道架构中哪些组件会在负载下失败，而且能够确定要监控哪些可指示您即将达到该负载的指标，从而及时解决问题，防止故障影响。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
+ 执行负载测试，确定工作负载的哪些方面表明您必须添加或移除容量。负载测试应具有您在生产中接收的流量类似的代表性流量。增加负载，同时监视所有已检测指标，以便确定哪种指标指示何时必须添加或移除资源。
+ [AWS 上的分布式负载测试：模拟数千个连接的用户](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ 确定请求组合。您可能拥有不同的请求组合，因此应当在确定流量组合时查看不同的时间范围。
+ 实施负载驱动程序。您可以使用自定义代码、开源或商用软件来实施负载驱动程序。
+ 最初使用小容量进行负载测试。通过将负载降低到较小容量（可能小到一个实例或容器），可能会有立竿见影的效果。
+ 针对更大的容量进行负载测试。分布式负载的效果会有所不同，因此您必须对尽量接近生产环境的目标进行测试。
## 资源
**相关文档：**
+ [AWS 上的分布式负载测试：模拟数千个连接的用户](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [加载测试应用程序](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)
**相关视频：**
+ [AWS Summit ANZ 2023: Accelerate with confidence through AWS Distributed Load Testing](https://www.youtube.com/watch?v=4J6lVqa6Yh8)
# REL 8. 您如何实施更改？
要部署新功能，必须对更改加以控制，以确保工作负载和操作环境正在运行已知的软件，并以可预测的方式进行修补和替换。如果这些更改不受控制，那么就很难预测这些更改的影响，也很难解决由此产生的问题。
**Topics**
+ [REL08-BP01 对部署等标准活动使用运行手册](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 将功能测试作为部署的一部分进行集成](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 将韧性测试作为部署的一部分进行集成](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 使用不可变基础设施进行部署](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 使用自动化功能部署更改](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 对部署等标准活动使用运行手册
运行手册是用来实现特定结果的预定义程序。使用运行手册执行标准活动，无论这些活动是手动还是自动执行。示例包括部署工作负载，对其进行修补或修改 DNS。
例如，实施流程以[确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)。确保您可以为客户进行部署回滚而不会出现中断，这是保证服务可靠的关键。
针对运行手册程序，从一个有效的手动流程开始，用代码进行实施，并在适当的情况下调用流程自动运行。
即使是高度自动化的复杂工作负载，运行手册仍可用于[开展 GameDay 活动](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays)或满足严格的报告和审核要求。
请注意，行动手册可用于对特定事件做出响应，运行手册则用来达成特定的结果。通常，运行手册适用于例行活动，而行动手册则用于对非例行事件做出响应。
**常见反模式：**
+ 对生产中的配置执行计划外更改。
+ 为加快部署速度而跳过计划中的步骤，导致部署失败。
+ 在未测试反向更改的情况下做出更改。
**建立此最佳实践的好处：**有效的更改计划有助于成功执行更改，因为您知道所有受影响的系统。在测试环境中验证更改能够增强您的信心。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
+ 通过在运行手册中记录程序，实现对为人熟知的事件的一致且及时的响应。
+ 使用基础设施即代码的原则定义基础设施。通过使用 AWS CloudFormation（或受信任的第三方）来定义基础设施，您可以使用版本控制软件管理并跟踪更改。
+ 使用 AWS CloudFormation（或受信任的第三方提供商）定义基础设施。
+ [什么是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ 使用良好的软件设计原则创建单个解耦模板。
+ 确定实施的权限、模板和责任方。
+ [使用 AWS Identity and Access Management 控制访问权限](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ 使用基于 Git 等流行技术的托管源代码管理系统，来存储源代码和基础设施即代码（IaC）配置。
## 资源
**相关文档：**
+ [APN 合作伙伴：可帮助创建自动化部署解决方案的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace：可用于自动实施部署的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [什么是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
**相关示例：**
+ [根据行动手册和运行手册自动完成操作](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 将功能测试作为部署的一部分进行集成
使用单元测试和集成测试等技术来验证所需功能。
单元测试是测试代码的最小功能单元来验证其行为的过程。集成测试旨在验证每个应用程序功能是否符合软件要求。虽然单元测试侧重于以隔离方式测试应用程序的一部分，但集成测试会考虑副作用（例如，通过变异操作更改数据所带来的影响）。无论是哪种情况，都应将测试集成到部署管道中，若未能满足成功条件，则相关管道会中止或回滚。这些测试在预生产环境中运行，该环境会在管道中的生产开始前被暂存。
如果这些测试作为构建和部署措施的一部分自动运行，则您可以获得最佳的结果。例如，使用 AWS CodePipeline，开发人员将更改提交到源代码存储库，而 CodePipeline 会自动在其中检测这些更改。构建应用程序，并运行单元测试。在单元测试获得通过之后，将构建的代码部署到暂存服务器来进行测试。CodePipeline 会从暂存服务器运行更多测试，例如集成或负载测试。在成功完成此类测试以后，CodePipeline 会将经过测试并获得批准的代码部署到生产实例。
**期望结果：**您使用自动化功能来执行单元测试和集成测试，以验证您的代码是否按预期运行。这些测试集成到部署过程中，而测试失败会中止部署。
**常见反模式：**
+ 您在部署过程中忽略或绕过测试失败和测试计划，以加快部署时间表。
+ 在部署管道之外手动执行测试。
+ 您跳过自动化流程中的测试步骤，而采用手动应急工作流程。
+ 您在与生产环境不太相似的环境中运行自动测试。
+ 您构建的测试套件不够灵活，难以随应用程序发展来进行维护、更新或扩展。
**建立这种最佳实践的好处：**在部署过程中进行自动测试可以及早发现问题，从而降低发布到生产环境时出现错误或意外行为的风险。单元测试可验证代码是否按预期运行，以及 API 合约是否得到遵守。集成测试可验证系统是否按照指定的要求运行。这些类型的测试可验证诸如用户界面、API、数据库和源代码等组件是否按预期正常运行。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
采用测试驱动型开发（TDD）方法编写软件，从而通过开发测试用例来指定和验证代码。首先，为每个函数创建测试用例。如果测试失败，则编写新的代码来通过测试。这种方法有助于您验证每个函数的预期结果。在将代码提交到源代码存储库之前，请运行单元测试并验证测试获得通过。
执行单元测试和集成测试，作为 CI/CD 管道的构建、测试和部署阶段的一部分。自动执行测试，并在准备好部署新版本的应用程序时自动启动测试。若未满足成功条件，则相关管道会中止或回滚。
如果应用程序是 Web 或移动应用程序，请在多个桌面浏览器或实际设备上执行自动的集成测试。这种方法对于验证移动应用程序在各种设备上的兼容性和功能性特别有用。
### 实施步骤
1. 在编写功能代码（*测试驱动型开发* 或 TDD）之前，先编写单元测试。制定代码指南，使编写和运行单元测试成为非功能性编码要求。
1. 创建一套自动化集成测试，其中涵盖已确定的可测试功能。这些测试应模拟用户互动并验证预期结果。
1. 创建运行集成测试所需的测试环境。这可能包括与生产环境非常相似的暂存环境或预生产环境。
1. 使用 AWS CodePipeline 控制台或 AWS Command Line Interface（CLI）设置源代码以及构建、测试和部署各个阶段。
1. 在代码构建和测试完毕后部署应用程序。AWS CodeDeploy 可以将其部署到您的暂存（测试）环境和生产环境。这些环境可能包括 Amazon EC2 实例、AWS Lambda 函数或本地服务器。应使用相同的部署机制将应用程序部署到所有环境。
1. 监控管道的进度以及每个阶段的状态。使用质量检查，根据测试的状态来阻止管道。此外，您可以接收有关任何管道阶段故障或管道完成的通知。
1. 持续监控测试结果，并查找规律、回归或需要更多关注的领域。使用这些信息来改进测试套件，确定应用程序中需要更稳健测试的领域，并优化部署过程。
## 资源
**相关最佳实践：**
+ [REL07-BP04 对工作负载进行负载测试](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_load_tested_adapt.html)
+ [REL08-BP03 将韧性测试作为部署的一部分进行集成](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_resiliency_testing.html)
+ [REL12-BP04 使用混沌工程测试韧性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html)
**相关文档：**
+ [AWS Prescriptive Guidance: Test automation](https://docs.aws.amazon.com/prescriptive-guidance/latest/performance-engineering-aws/test-automation.html)
+ [持续交付和持续集成](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Indicators for functional testing](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/indicators-for-functional-testing.html)
+ [Monitoring pipelines](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html)
+ [Use AWS CodePipeline with AWS CodeBuild to test code and run builds](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS Device Farm](https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-DeviceFarm.html)
# REL08-BP03 将韧性测试作为部署的一部分进行集成
集成韧性测试功能，通过在系统中特意引入故障来衡量系统在遇到破坏性情景时的功能。韧性测试不同于通常集成在部署周期中的单元和功能测试，因为它们侧重于识别系统中的意外故障。虽然在预生产环境中集成韧性测试是安全的，但您要设定一个目标，将这些测试作为 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays)的一部分在生产环境中实施。
**期望结果**：韧性测试有助于建立信心，确信系统能够承受生产环境中的性能降级。通过实验来找出可能导致故障的薄弱环节，这可以帮助您改进系统，从而自动有效地减少故障和性能降级的情况。
**常见反模式：**
+ 部署流程中缺乏可观测性和监控能力
+ 依靠人工来解决系统故障
+ 糟糕的质量分析机制
+ 只看到系统中的已知问题，缺少通过实验来发现未知问题的手段
+ 识别故障，但没有解决
+ 没有关于调查发现和运行手册的文档
**建立最佳实践的好处：**部署中集成的韧性测试有助于识别系统中的未知问题，以防因忽视这些问题导致生产中断。识别系统中的这些未知问题可以协助您记录调查发现，将测试集成到 CI/CD 流程中，并制定运行手册，从而通过高效、可重复的机制简化缓解措施。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
在系统部署中，可以集成的最常见的韧性测试形式是灾难恢复和混沌工程。
+ 对于任何重大部署，都要包括对灾难恢复计划和标准操作程序（SOP）的更新。
+ 将可靠性测试集成到自动部署管道中。诸如 [AWS Resilience Hub](https://aws.amazon.com/resilience-hub/) 的服务可以[集成到 CI/CD 管道中](https://aws.amazon.com/blogs/architecture/continually-assessing-application-resilience-with-aws-resilience-hub-and-aws-codepipeline/)，用于建立持续的韧性评测，这些评测将作为每次部署的一部分自动进行评估。
+ 在 AWS Resilience Hub 中定义应用程序。韧性评测会生成代码片段，帮助您以 AWS Systems Manager 文档的形式为应用程序创建恢复程序，并提供推荐的 Amazon CloudWatch 监控和警报列表。
+ 更新灾难恢复计划和标准操作程序后，完成灾难恢复测试以验证它们是否有效。灾难恢复测试可帮助您确定，在事件发生后是否可以恢复系统并恢复正常运行。您可以模拟各种灾难恢复策略，确定计划是否足以满足您的正常运行时间要求。常见的灾难恢复策略包括备份和恢复、指示灯、冷备用、温备用、热备用和主动-主动模式，这些策略的成本和复杂性各不相同。在执行灾难恢复测试之前，建议先定义恢复时间目标（RTO）和恢复点目标（RPO），简化模拟策略的选择。AWS 提供 [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 等灾难恢复工具，可帮助您开始规划和测试。
+ 混沌工程实验会在系统中引入中断，例如网络中断和服务故障。通过模拟受控的故障，您可以发现系统的漏洞，同时控制注入故障的影响。与其他策略一样，使用诸如 [AWS Fault Injection Service](https://aws.amazon.com/fis/) 的服务在非生产环境中运行受控故障模拟，以便在生产环境中部署之前增强信心。
## 资源
**相关文档：**
+ [Experiment with failure using resilience testing to build recovery preparedness](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/qa.nt.6-experiment-with-failure-using-resilience-testing-to-build-recovery-preparedness.html)
+ [Continually assessing application resilience with AWS Resilience Hub and AWS CodePipeline](https://aws.amazon.com/blogs/architecture/continually-assessing-application-resilience-with-aws-resilience-hub-and-aws-codepipeline/)
+ [Disaster recovery (DR) architecture on AWS, part 1: Strategies for recovery in the cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [Verify the resilience of your workloads using Chaos Engineering](https://aws.amazon.com/blogs/architecture/verify-the-resilience-of-your-workloads-using-chaos-engineering/)
+ [混沌工程原则](https://principlesofchaos.org/)
+ [Chaos Engineering 讲习会](https://disaster-recovery.workshop.aws/en/intro/concepts/chaos-engineering.html)
**相关视频：**
+ [AWS re:Invent 2020: Testing Resilience using Chaos Engineering](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [Improve Application Resilience with AWS Fault Injection Service](https://www.youtube.com/watch?v=N0aZZVVZiUw)
+ [Prepare & Protect Your Applications From Disruption With AWS Resilience Hub](https://www.youtube.com/watch?v=xa4BVl4N1Gw)
# REL08-BP04 使用不可变基础设施进行部署
不可变基础设施模式要求在生产工作负载上不会出现就地更新、安全补丁或配置更改。需要更改时，会在新的基础设施上构建架构，并将其部署到生产环境中。
遵循不可变基础设施部署策略，以提高工作负载部署的可靠性、一致性和可重复性。
**期望结果：**使用不可变基础设施，就禁止为了在工作负载中运行基础设施资源而进行[就地修改](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html#in-place-deployments)。相反，当需要更改时，会将一组包含所有必要更改的新基础设施资源与现有资源并行部署。会自动验证此部署，如果成功，流量将逐渐转移到新的资源集。
此部署策略适用于软件更新、安全补丁、基础设施更改、配置更新和应用程序更新等。
**常见反模式：**
+ 对正在运行的基础设施资源实施就地更改。
**建立此最佳实践的好处：**
+ **提高环境间的一致性：**由于环境间的基础设施资源没有差异，可以提高一致性并简化测试。
+ **减小配置偏差：**通过使用已知且版本受控的配置替换基础设施资源，基础设施被设置为已知经过测试的可信状态，避免配置偏差。
+ **采用可靠的原子部署：**部署要么成功完成，要么没有任何更改，从而提高部署过程的一致性和可靠性。
+ **简化部署：**由于无需支持升级，部署得到简化。升级即意味着新的部署。
+ **采用快速回滚和恢复流程实现更安全的部署：**由于之前运行的版本未发生更改，部署变得更安全。您可以在检测到错误时进行回滚。
+ **增强安全态势：**通过不允许更改基础设施，可以禁用远程访问机制（例如 SSH）。这样做可以减少攻击向量，改善组织的安全态势。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
** – 自动化**
在定义不可变基础设施部署策略时，建议尽可能使用[自动化](https://aws.amazon.com/iam/)功能来提高可重复性，并最大限度地减少出现人为错误的可能性。有关更多详细信息，请参阅 [REL08-BP05 使用自动化功能部署更改](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html)和[自动实现无需干预的安全部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)。
借助[基础设施即代码（IaC）](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)，基础设施预置、编排和部署步骤以编程、描述性和声明性的方式进行定义，并存储在源代码控制系统中。利用基础设施即代码可以更轻松地自动化基础设施部署，并有助于实现基础设施的不可变性。
**部署模式**
当需要更改工作负载时，不可变基础设施部署策略要求部署一组新的基础设施资源，包括所有必要的更改。这组新资源必须遵循可最大限度地减少对用户影响的推出模式，这一点非常重要。此部署有两种主要策略：
[https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html)：将少量客户引导到新版本的做法，通常在单个服务实例（金丝雀）上运行。然后，您可以深入检查生成的任何行为更改或错误。如果遇到了严重问题，您可以将金丝雀中的流量删除，并将用户发回到以前的版本。如果部署成功，您可以继续以期望的速度进行部署，同时监控更改以便发现错误，直到所有部署完成。AWS CodeDeploy 的[部署配置](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)可以配置为允许金丝雀部署。
[https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html)：与金丝雀部署类似，只是会并行部署一整套应用程序。您可以在两个堆栈（蓝和绿）之间轮流部署。同样，您可以将流量发送到新版本中，如果发现部署中存在问题，可以对其进行故障恢复，然后送回旧版本中。通常来说，所有流量会被一次性切换，但您也可以通过 Amazon Route 53 的加权 DNS 路由功能向每个版本发送部分流量，加快采用新版本的速度。AWS CodeDeploy 和 [AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2020-05-18-ts-deploy.html) 的部署配置可以配置为允许蓝绿部署。
![\[图中显示了使用 AWS Elastic Beanstalk 和 Amazon Route 53 进行蓝绿部署\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/blue-green-deployment.png)
**偏差检测**
*偏差*定义为导致基础设施资源的状态或配置与预期不同的任何更改。任何类型非受管配置更改都与不可变基础设施的概念背道而驰，因此应加以检测和修复，以便成功实施不可变基础设施。
### 实施步骤
+ 禁止就地修改正在运行的基础设施资源。
+ 您可以使用 [AWS Identity and Access Management（IAM）](https://aws.amazon.com/iam/)来指定可以访问 AWS 中服务和资源的对象，集中管理精细权限，并分析访问权限来细化跨 AWS 的权限。
+ 自动部署基础设施资源，以提高可重复性并最大限度地减少出现人为错误的可能性。
+ 正如《[AWS DevOps 简介](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)》白皮书中所述，自动化是 AWS 服务的基石，并且在所有服务、功能和产品中均得到内部支持。
+ *[预烘焙](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/prebaking-vs.-bootstrapping-amis.html)*亚马逊机器映像（AMI）可以加快启动速度。[EC2 Image Builder](https://aws.amazon.com/image-builder/) 是一项完全托管的 AWS 服务，可帮助您自动创建、维护、验证、共享和部署自定义、安全且最新的 Linux 或 Windows 自定义 AMI。
+ 一些支持自动化的服务包括：
+ [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) 是一项服务，用于在熟悉的服务器（例如 Apache、NGINX、Passenger 和 IIS）上部署和扩展使用 Java、.NET、PHP、Node.js、Python、Ruby、GO 和 Docker 开发的 Web 应用程序。
+ [AWS Proton](https://aws.amazon.com/proton/) 让平台团队能够连接和协调开发团队进行基础设施预置、代码部署、监控和更新所需的所有不同工具。AWS Proton 可实现自动化基础设施即代码预置，以及无服务器和基于容器的应用程序的部署。
+ 利用基础设施即代码可以轻松实现基础设施部署的自动化，并有助于实现基础设施的不可变性。AWS 提供的服务可用于以编程、描述性和声明性的方式创建、部署和维护基础设施。
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 帮助开发人员以有序且可预测的方式创建 AWS 资源。资源使用 JSON 或 YAML 格式写入文本文件。模板需要特定的语法和结构，具体取决于创建和管理的资源类型。可以使用任何代码编辑器以 JSON 或 YAML 格式创作资源，将其签入版本控制系统，然后 CloudFormation 会以安全、可重复的方式构建指定的服务。
+ [AWS Serverless Application Model（AWS SAM）](https://aws.amazon.com/serverless/sam/) 是一个开源框架，可用于在 AWS 上构建无服务器应用程序。AWS SAM 与其他 AWS 服务集成，是 CloudFormation 的扩展。
+ [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) 是一个开源软件开发框架，可使用熟悉的编程语言对云应用程序资源进行建模和预置。您可以使用 AWS CDK 通过 TypeScript、Python、Java 和 .NET 对应用程序基础设施进行建模。AWS CDK 在后台使用 CloudFormation，以安全、可重复的方式预置资源。
+ [AWS 云端控制 API](https://aws.amazon.com/cloudcontrolapi/) 引入了一组通用的创建、读取、更新、删除和列出（CRUDL）API，帮助开发人员以简单一致的方式管理其云基础设施。Cloud Control API 通用 API 允许开发人员统一管理 AWS 和第三方服务的生命周期。
+ 实施能够最大限度减少对用户的影响的部署模式。
+ 金丝雀部署：
+ [设置 API Gateway 金丝雀版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [使用 AWS App Mesh 为 Amazon ECS 创建具有金丝雀部署的管道](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/)
+ 蓝绿部署：《[Blue/Green Deployments on AWS](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html)》白皮书介绍了实施蓝绿部署策略的[示例技术](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/implementation-techniques.html)。
+ 检测配置或状态偏差。有关更多详细信息，请参阅[检测堆栈和资源的非托管配置更改](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)。
## 资源
**相关最佳实践：**
+ [REL08-BP05 使用自动化功能部署更改](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html)
**相关文档：**
+ [自动实现无需干预的安全部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Leveraging AWS CloudFormation to create an immutable infrastructure at Nubank ](https://aws.amazon.com/blogs/mt/leveraging-immutable-infrastructure-nubank/)
+ [基础设施即代码](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ [Implementing an alarm to automatically detect drift in AWS CloudFormation stacks](https://docs.aws.amazon.com/blogs/mt/implementing-an-alarm-to-automatically-detect-drift-in-aws-cloudformation-stacks/)
**相关视频：**
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability](https://www.youtube.com/watch?v=jUSYnRztttY)
# REL08-BP05 使用自动化功能部署更改
自动执行部署与修补来消除负面影响。
对许多组织来说，对生产系统进行变更是风险最大的工作之一。除了软件解决的业务问题外，我们认为部署也是亟待解决的首要问题。如今，这意味着根据实际情况在操作中使用自动化，包括测试和部署更改、添加或删除容量以及迁移数据。
**期望结果：**通过广泛的预生产测试、自动回滚和错开生产部署，将自动化部署安全性融入发布流程。这种自动化尽可能地减少了部署失败对生产造成的潜在影响，开发人员不再需要主动关注部署到生产的情况。
**常见反模式：**
+ 手动执行更改。
+ 跳过自动化流程中的步骤，采用手动应急工作流。
+ 不遵循既定的计划和流程，急于求成。
+ 在不预留烘焙时间的情况下，快速执行了后续部署。
**建立此最佳实践的好处：**当使用自动化来部署所有更改时，可以消除引入人为错误的可能性，并提供在更改生产环境之前进行测试的能力。在生产推送之前执行此流程，以便验证您的计划是否能完成。此外，自动回滚到发布流程可以识别生产问题，并将您的工作负载恢复到以前的正常工作运行状态。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
实现部署管道的自动化。借助部署管道，您可以调用自动化测试和异常检测，并且能够在生产部署前的某个步骤停止管道，或自动回滚更改。其中必不可少的是采用[持续集成和持续交付/部署](https://en.wikipedia.org/wiki/CI/CD)（CI/CD）文化，这样一来，提交或代码更改会经过各种自动化阶段（完成构建和测试，并最终部署至生产环境中）。
虽然传统观点认为，您应该让人来处理循环中最困难的操作程序，但出于相同的原因，我们建议您将最困难的程序自动化。
### 实施步骤
您可以按照以下步骤实现自动化部署，从而消除手动操作：
+ **设置代码存储库以安全地存储您的代码：**使用基于 Git 等流行技术的托管源代码管理系统，来存储源代码和基础设施即代码（IaC）配置。
+ **配置持续集成服务来编译源代码、运行测试和创建部署构件：**要为此目的设置构建项目，请参阅 [Getting started with AWS CodeBuild using the console](https://docs.aws.amazon.com/codebuild/latest/userguide/getting-started.html)。
+ **设置部署服务来自动执行应用程序部署并处理复杂的应用程序更新，无需依赖容易出错的人工部署过程：**[AWS CodeDeploy](https://aws.amazon.com/codedeploy/) 可自动将软件部署到各种计算服务，例如 Amazon EC2、[AWS Fargate](https://aws.amazon.com/fargate/)、[AWS Lambda](https://aws.amazon.com/lambda) 和本地服务器。要配置这些步骤，请参阅 [Getting started with CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-codedeploy.html)。
+ **设置持续交付服务，实现发布管道的自动化，从而带来更快、更可靠的应用程序和基础设施更新：**请考虑使用 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-codepipeline.html) 来帮助您实现发布管道的自动化。有关更多详细信息，请参阅 [CodePipeline tutorials](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials.html)。
## 资源
**相关最佳实践：**
+ [OPS05-BP04 使用构建和部署管理系统](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_build_mgmt_sys.html)
+ [OPS05-BP10 完全自动化集成和部署](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_auto_integ_deploy.html)
+ [OPS06-BP02 测试部署](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_mit_deploy_risks_test_val_chg.html)
+ [OPS06-BP04 自动测试和回滚](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_mit_deploy_risks_auto_testing_and_rollback.html)
**相关文档：**
+ [Continuous Delivery of Nested AWS CloudFormation Stacks Using AWS CodePipeline](https://aws.amazon.com/blogs/devops/continuous-delivery-of-nested-aws-cloudformation-stacks-using-aws-codepipeline)
+ [APN 合作伙伴：可帮助创建自动化部署解决方案的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace：可用于自动实施部署的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Automate chat messages with webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [Amazon Builders' Library：确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library：采用持续交付，加速交付进度](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [什么是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [What Is CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [What is Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [What is Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**相关视频：**
+ [AWS Summit 2019: CI/CD on AWS](https://youtu.be/tQcF6SqWCoY)