本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 卓越运营支柱
<a name="operational-excellence"></a>

Well-Architect AWS ed Framework的[卓越运营](https://docs.aws.amazon.com/wellarchitected/latest/framework/operational-excellence.html)支柱侧重于运行和监控系统，以及不断改进流程和程序以实现业务价值。卓越运营支柱包括支持开发和有效运行工作负载的能力，以及深入了解其运营的能力。

您可以通过自我修复工作负载降低运营复杂性，这些工作负载无需人工干预即可检测和修复大多数问题。要努力实现这一目标，请遵循本节中描述的最佳实践。[使用适用于 InfluxDB 的 Amazon Timestream 的亚马逊 CloudWatch指标、InfluxDB 原生指标终端节点 APIs，以及在工作负载偏离预期行为时做出响应的机制。](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)

本次对卓越运营支柱的讨论侧重于以下关键领域：
+ 基础设施即代码（IaC）
+ 变更管理
+ 韧性策略
+ 事件管理
+ 用于审计目的的日志和监控

## 使用 IaC 方法自动部署
<a name="iac"></a>

使用 iaC 在 InfluxDB 的 Timestream 上自动部署的最佳实践包括以下内容：
+ 尽可能使用 iaC 为 InfluxDB 部署 Timestream。为了实现一致的环境配置，请使用[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)模板或 [HashiCorp Terraform](https://aws.amazon.com/blogs/apn/terraform-beyond-the-basics-with-aws/) 为您的实例创建所有必需的资源。[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)
+ 自动执行 InfluxDB 操作过程的时间流，例如调整实例大小。
+ 使用标签向时间流中添加InfluxDB资源的元数据，并根据标签跟踪使用情况。有关更多信息，请参阅为 InfluxD [B 标记亚马逊 Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/tagging-keyspaces-influxdb.html)。

## 频繁进行可逆的小规模更改
<a name="change-management"></a>

以下建议侧重于小的、可逆的更改，以最大限度地降低复杂性并降低工作负载中断的可能性：
+ 将 IaC 模板和脚本存储在源代码控制服务中，例如或。 GitHub GitLab不要在源代码管理中存储 AWS 凭据。
+ 要求 IaC 部署才能使用持续集成和持续交付（CI/CD）服务，例如 [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 或 [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)。这些服务会在包含临时InfluxDB实例的非生产环境中编译、测试和部署代码，然后再影响您的生产InfluxDB实例。
+ 在将基础设施和应用程序查询部署到生产环境之前，先在较低的环境中对其进行测试。这样可以最大限度地减少中断的可能性，并有助于确保它们在您的工作负载和规模下表现良好。

## 预测故障
<a name="resilience"></a>

自我修复的基础设施通过预测故障并尝试在没有干预的情况下解决任何问题来体现卓越运营。以下建议可帮助您使用适用于 InfluxDB 的 Timestream 实现这一成熟度：
+ 使用指标监控您的内存、CPU 和存储使用情况。可将 CloudWatch 设置为在使用模式发生更改或接近部署容量时向您发送通知。这样，您就可以保持系统的性能和可用性。
+ 当您接近资源限制时，可以扩展数据库实例。存储和内存中应含有一些缓冲区，以适应应用程序的意外增大需求。
+ 如果您的数据库工作负载需要 I/O 超出预配置的范围，则故障转移或数据库故障后的恢复速度会很慢。增加I/O capacity of a DB instance, migrate to a different DB instance that has higher I/O容量。
+ 如果您的客户端应用程序正在缓存数据库实例的 DNS 数据，请将 time-to-live (TTL) 值设置为小于 30 秒。数据库实例的底层 IP 地址在故障转移后可能会发生变化。长时间缓存 DNS 数据可能会导致连接失败。您的应用程序可能会尝试连接到不再使用的 IP 地址。
+ 如果您的应用程序需要在完全 AWS 区域 中断后存活下来，请考虑设置复制或写入其他区域，作为灾难恢复 (DR) 计划的一部分。了解设置复制时的限制。有关复制的更多信息，请参阅 [InfluxDB 文档](https://docs.influxdata.com/influxdb/cloud/write-data/replication/replicate-data/)。

## 从所有操作故障中吸取教训
<a name="incident-management"></a>

自我修复基础架构是一项长期的工作，当出现罕见问题或响应效果不如你想要的有效时，你需要反复开发这个基础架构。要专注于实现自我修复基础架构，请采用以下做法：
+ 从所有故障中吸取教训，推动改进。
+ 在团队和组织内部分享经验教训。如果组织内的多个团队使用 Timestream for InfluxDB，请创建一个公共聊天室或用户组来分享经验教训和最佳实践。

## 使用日志记录功能来监控未经授权或异常的活动
<a name="logging-monitoring"></a>

要观察异常的性能和活动模式，请考虑以下做法：
+ 启用[日志传输](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influx-managing-view-influx-logs.html)，将 InfluxDB 日志存储在亚马逊[简单存储服务 (Amazon S3) Service 中。](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)InfluxDB 日志记录的信息可以帮助检查以下内容：
  + [数据平面 API 事件](https://docs.influxdata.com/influxdb/v2/reference/api/)
  + 响应时间
  + 压实细节
  + 系统遇到的任何严重错误或警告

  查看日志中是否存在未经授权的访问或异常情况。总体而言，日志记录为故障排除提供了诊断信息。
+ InfluxDB 的 Timestream 支持使用记录控制平面操作。 AWS CloudTrail有关更多信息，请参阅使用[记录 InfluxDB API 调用的时间流](https://docs.aws.amazon.com/timestream/latest/developerguide/logging-using-cloudtrail-influxdb.html)。 AWS CloudTrail
+ **你可以在 t **imeStream/InfluxDB > < Namespace >** 中监控`CPUUtilization``MemoryUtilization`、和`DiskUtilization`指标。** CloudWatch

有关更多信息，请参阅 [InfluxDB 的时间流](https://docs.aws.amazon.com/timestream/latest/developerguide/monitoring-influxdb.html)文档。