本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 卓越營運支柱
<a name="operational-excellence"></a>

 AWS Well-Architected Framework 的[卓越營運](https://docs.aws.amazon.com/wellarchitected/latest/framework/operational-excellence.html)支柱著重於執行和監控系統，並持續改善流程和程序以提供商業價值。卓越營運支柱包括能夠有效支援開發和執行工作負載，以及深入了解其操作。

您可以透過自我修復工作負載來降低操作複雜性，無需人工介入即可偵測和修復大多數問題。若要實現此目標，請遵循本節所述的最佳實務。將 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 指標用於 Amazon Timestream for InfluxDB、InfluxDB 原生指標端點、APIs和機制，以便在工作負載偏離預期行為時做出回應。

此卓越營運支柱的討論著重於下列關鍵領域：
+ 基礎設施即程式碼 (IaC)
+ 變更管理
+ 彈性策略
+ 事件管理
+ 記錄和監控以進行稽核

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

使用 IaC 在 Timestream for InfluxDB 上自動化部署的最佳實務包括：
+ 盡可能套用 IaC 來部署 InfluxDB 的 Timestream。若要取得一致的環境組態，請使用 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 範本、 [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)或 [HashiCorp Terraform](https://aws.amazon.com/blogs/apn/terraform-beyond-the-basics-with-aws/) 為您的執行個體建立所有必要的資源。
+ 自動化 InfluxDB 操作程序的 Timestream，例如調整執行個體的大小。
+ 使用標籤將中繼資料新增至 Timestream for InfluxDB 資源，並根據標籤追蹤用量。如需詳細資訊，請參閱[標記 Amazon Timestream for InfluxDB](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>

自我修復基礎設施透過預測故障並嘗試在不介入的情況下解決任何問題，來示範卓越營運。下列建議可協助您使用 Timestream for InfluxDB 來實現該成熟度：
+ 使用指標來監控您的記憶體、CPU 和儲存體用量。您可以設定 CloudWatch，以便在使用模式變更或接近部署容量時通知您。如此一來，您就可以維護系統效能和可用性。
+ 當您接近資源限制時擴展資料庫執行個體。您應該在儲存體和記憶體中具有一些緩衝，以容納應用程式需求中未知的增加。
+ 如果資料庫工作負載所需的 I/O 較您佈建得多，容錯移轉或資料庫失敗之後的復原將會很緩慢。若要增加資料庫執行個體的 I/O 容量，請遷移至具有較高 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 Simple Storage Service (Amazon S3)](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 呼叫的時間串流 AWS CloudTrail](https://docs.aws.amazon.com/timestream/latest/developerguide/logging-using-cloudtrail-influxdb.html)。
+ 您可以從 CloudWatch 中的 **Timestream/InfluxDB >** <**Namespace**> 監控 `CPUUtilization``MemoryUtilization`、 和 `DiskUtilization`指標。

如需詳細資訊，請參閱 [Timestream for InfluxDB 文件](https://docs.aws.amazon.com/timestream/latest/developerguide/monitoring-influxdb.html)。