本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 第四阶段：运营
完成[第三阶段：评估与测试](stage-3.md)后，即可将应用程序部署到生产环境。在*运营*阶段，您可以将应用程序部署到生产环境并管理客户的体验。 应用程序的设计与实施决定了其许多韧性成果，但本阶段的重点是您的系统用来维持和提升韧性的运营实践。建立卓越运营文化有助于在这些实践中建立标准并保持一致性。
## 可观测性
了解客户体验最重要的部分是通过监控和告警。您需要对应用程序进行检测以了解其状态，并且需要不同的视角，这意味着您需要从服务器端和客户端（通常使用金丝雀）进行衡量。您的指标应包括有关应用程序与其依赖关系交互的数据，以及[与故障隔离边界一致的维度](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/multi-az-observability.html)。您还应该生成日志，以提供有关应用程序执行的每个工作单元的其他详细信息。您可以考虑使用 [Amazon CloudWatch 嵌入式指标格式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html)等解决方案来合并指标和日志。您可能会发现对更高可观测性的需求永无止境，因此请考虑实施所需检测级别所需的成本、工作量和复杂性权衡取舍。
以下链接提供了检测应用程序和创建告警的最佳实践：
+ [Monitoring production services at Amazon](https://youtu.be/hnPcf_Czbvw)（AWS re:Invent 2020 演讲）
+ [Amazon Builders' Library: Operational Excellence at Amazon](https://youtu.be/7MrD4VSLC_w)（AWS re:Invent 2021 演讲）
+ [Observability best practices at Amazon](https://youtu.be/zZPzXEBW4P8)（AWS re:Invent 2022 演讲）
+ [检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)（Amazon Builders' Library 文章）
+ [Building dashboards for operational visibility](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)（Amazon Builders' Library 文章）
## 事件管理
当您的告警（或者更糟糕的是，您的客户）告知您出现问题时，您应该有一个事件管理流程来处理损害。该流程应包括：安排值班的运营人员、上报问题，以及制定运行手册，以采用一致的排查方法，帮助消除人为错误。但是，损害通常并非孤立发生；一个应用程序可能会影响依赖它的多个其他应用程序。通过了解所有受影响的应用程序并将召集多个团队的运营人员一起参加一次电话会议，您可以快速解决问题。但是，根据您组织的规模和结构，此流程可能需要一个集中式运营团队。
除了设置事件管理流程外，您还应该通过控制面板定期查看指标。定期查看可帮助您了解客户体验和应用程序性能的长期趋势，从而在造成重大生产影响之前识别问题和瓶颈。以一致、标准化的方式查看指标可以带来显著收益，但需要获得自上而下的支持和投入时间。
以下链接提供有关构建控制面板和运营指标查看的最佳实践：
+ [Building dashboards for operational visibility](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)（Amazon Builders' Library 文章）
+ [Amazon's approach to failing successfully](https://youtu.be/yQiRli2ZPxU)（AWS re:Invent 2019 演讲）
## 持续韧性
在[第二阶段：设计与实施](stage-2.md)和[第三阶段：评估与测试](stage-3.md)期间，您在将应用程序部署到生产环境之前启动了审查和测试活动。在*运营*阶段，您应该继续迭代生产中的这些活动。您应该通过 [AWS Well-Architected Framework 审查](https://aws.amazon.com/architecture/well-architected/)、[运营准备情况审查（ORR）](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)和[韧性分析框架](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)，定期审查应用程序的韧性状况。这有助于确保您的应用程序不会偏离既定的基准和标准，并使您随时了解新的或更新的指引。这些持续的韧性活动可以帮助您发现以前未预见的中断，并帮助您制定新的缓解措施。
在预生产环境中成功运行[实际试用](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.gameday.en.html)和[混沌工程](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/)实验之后，您可能还需要考虑在生产环境中运行这些实验。实际试用模拟您已经建立韧性机制来缓解的已知事件。例如，实际试用可模拟 AWS 区域服务损害，并实施多区域失效转移。尽管实施这些活动可能需要投入大量精力，但这两种做法都能增强您对系统韧性的信心，确保其能承受设计时预期的故障模式。
通过运行应用程序、应对运营事件、查看指标和测试应用程序，您将获得大量响应与学习的机会。