1. 準備
1.1. OPS 4. テレメトリを設計する
1.1.1. アプリケーションテレメトリーを実装する
1.1.1.1. CloudWatch、カスタムメトリクス、EventBridge
1.1.2. ワークロードテレメトリーを実装して設定する
1.1.2.1. CloudWatch、ログとメトリクスの集約
1.1.3. ユーザーアクティビティテレメトリーを実装する
1.1.3.1. アプリケーションコードのインストルメント化
1.1.4. 依存関係のテレメトリーを実装する
1.1.4.1. リソースのステータス（到達可能性や応答時間）に関する情報の出力を実装
1.1.5. トランザクショントレーサビリティを実装する
1.1.5.1. X-Ray
1.2. OPS 5. 運用のための設計
1.2.1. バージョン管理を使用する
1.2.1.1. CodeCommit、CloudFormation
1.2.2. 変更をテストし、検証する
1.2.2.1. テストの自動化
1.2.2.2. CloudFormationによる並列環境の作成
1.2.3. 構成管理システムを使用する
1.2.3.1. 手動プロセスによるエラーを回避
1.2.4. 構築およびデプロイ管理システムを使用する
1.2.4.1. 開発者用ツール – アマゾン ウェブ サービス (AWS)
1.2.4.2. Codeシリーズ
1.2.5. パッチ管理を実行する
1.2.5.1. マシンイメージ
1.2.5.1.1. EC2 Image Builder
1.2.5.2. コンテナイージ
1.2.5.2.1. ECR、ECS、EKS
1.2.5.3. Lambdaカスタムランタイム
1.2.5.3.1. バージョンかんり
1.2.5.4. Systems Manager パッチマネージャー、メンテナンスウインドウ
1.2.6. 設計標準を共有する
1.2.6.1. AWSリソースのアカウント間共有
1.2.6.2. クロスアカウント通知
1.2.7. コード品質の向上のためにプラクティスを実装する
1.2.7.1. テスト駆動開発、コードレビュー、標準の採用
1.2.8. 複数の環境を使用する
1.2.9. 小規模かつ可逆的な変更を頻繁に行う
1.2.10. 統合とデプロイを完全自動化する
1.2.10.1. タグ付け戦略
1.2.10.2. AWSリソースグループ
1.3. OPS 6. デプロイのリスクを緩和する
1.3.1. 変更の失敗に備える
1.3.1.1. 計画の策定
1.3.2. 変更をテストし、検証する
1.3.2.1. CloudFormationによる並列環境
1.3.3. デプロイ管理システムを使用する
1.3.3.1. 開発者用ツール – アマゾン ウェブ サービス (AWS)
1.3.3.2. Codeシリーズ
1.3.3.3. Systems Manager 変更カレンダー、メンテナンスウインドウ
1.3.4. 限定的なデプロイを使用してテストする
1.3.4.1. カナリアテスト、ワンボックスデプロイ
1.3.5. 並列環境でデプロイする
1.3.5.1. ロールバックによる回復時間の最小化
1.3.6. 小規模で可逆的な変更を頻繁にデプロイする
1.3.7. 統合とデプロイを完全自動化する
1.3.8. テストとロールバックを自動化する
1.4. OPS 7. 運用準備状況
1.4.1. 従業員の対応力を確保する
1.4.1.1. 各種トレーニング
1.4.2. 運用準備状況の継続的な確認を実現する
1.4.2.1. AWS Config
1.4.2.2. Config Rules、SecurityHub
1.4.3. ランブックを使用して手順を実行する
1.4.3.1. 特定の結果を達成するための文書化された手順
1.4.4. プレイブックを使用して問題を特定する
1.4.4.1. 問題を調査するための文書化されたプロセス
1.4.4.2. リソースタグ、リソースグループ
1.4.4.3. Systems Manager、AWS Lambda
1.4.4.4. Step Functions、EventBridge
1.4.5. システムや変更をデプロイするために十分な情報に基づいて決定を下す
1.4.5.1. 事前評価による障害の予測、手順の作成
2. 組織
2.1. OPS 1. 組織の優先順位
2.1.1. 外部顧客のニーズを評価する
2.1.1.1. 外部の顧客ニーズのどこに注力するか
2.1.2. 内部顧客のニーズを評価する
2.1.2.1. 内部の顧客のニーズのどこに注力するか
2.1.3. ガバナンス要件を評価する
2.1.3.1. 組織のポリシー、標準、用件などの内部要因を評価
2.1.4. 外部のコンプライアンス要件を評価する
2.1.4.1. AWS クラウドコンプライアンス | AWS
2.1.5. 脅威の状況を評価する
2.1.5.1. AWS Well-Architected – 安全で効率的なクラウドアプリケーション
2.1.5.2. AWS Well-Architected Tool（アーキテクチャのレビューとベストプラクティス比較）| AWS
2.1.5.3. サポートのプログラム | パートナー、イベント管理、サードパーティアプリ | AWS サポート
2.1.5.4. AWS Trusted Advisor
2.1.5.5. サポートのプラン比較 | 開発者、ビジネス、エンタープライズ | AWS サポート
2.1.6. トレードオフを評価する
2.1.6.1. AWS サポート - ナレッジセンター
2.1.6.2. ディカッションフォーラム、サポートセンター
2.1.7. メリットとリスクを管理する
2.2. 運用モデル
2.2.1. 運用モデル2 x 2 の表現
2.2.1.1. 完全に分離された運用モデル
2.2.1.2. 分離されたAEOと一元化されたガバナンスを備えたIEO
2.2.1.3. 分離されたAEOおよび一元化されたガバナンスとサービスプロバイダを備えたIEO
2.2.1.4. 分離されたAEOと一元化されていないガバナンスを備えたIEO
2.2.2. OPS 2. 関係性と所有権
2.2.2.1. リソースに特定された所有権が存在する
2.2.2.1.1. アプリケーション、ワークロード、プラットフォーム、インフラストラクチャコンポーネントの所有者
2.2.2.1.2. コンポーネントのビジネス価値、ビジネス成果のサポート
2.2.2.2. プロセスと手順に特定された所有者が存在する
2.2.2.2.1. プロセスと手順の定義の所有者の確立
2.2.2.3. パフォーマンスに責任を持つ所有者が運用アクティビティに存在する
2.2.2.3.1. 特定のアクティビティを実行する責任を持つユーザーとその責任が存在する理由を理解
2.2.2.4. チームメンバーが自らの責任範囲を把握する
2.2.2.4.1. タスクの優先づけ
2.2.2.5. 責任と所有権を特定するためのメカニズムが存在する
2.2.2.5.1. エスカレーションパスの定義
2.2.2.6. 追加、変更、例外をリクエストするメカニズムが存在する
2.2.2.7. チーム間の責任は事前定義済みまたは交渉済みである
2.2.2.7.1. 応答時間、サービスレベル目標、サービスレベルアグリーメントなど
2.3. OPS 3. 組織カルチャー
2.3.1. エグゼクティブスポンサー
2.3.1.1. シニアリーダーシップ
2.3.1.2. ベストプラクティスの採用と組織の進化の協賛者、支持者、推進者
2.3.2. チームメンバーに、結果とリスクがあるときにアクションを実行する権限が付与されている
2.3.2.1. ガイダンスと範囲を定期
2.3.3. エスカレーションが推奨されている
2.3.3.1. 意思決定者や利害関係者に懸念をエスカレート
2.3.4. コミュニケーションが、タイムリーで明確かつ実用的なものである
2.3.4.1. Systems Manager 変更カレンダー、メンテナンスウインドウ
2.3.5. 実験が推奨されている
2.3.5.1. 実験は学習を加速し、チームメンバーの関心と関与を維持
2.3.6. チームメンバーがスキルセットを維持、強化することができ、それを推奨されている
2.3.6.1. アマゾン ウェブ サービス（AWS）の開始方法 | AWS
2.3.6.2. The Amazon Builders' Library
2.3.6.3. AWS トレーニングと認定 – インストラクター主導形式の AWS クラウドトレーニングクラス | AWS
2.3.7. チームに適正なリソースを提供する
2.3.7.1. 過剰なタスクはヒューマンエラーを誘因
2.3.8. チーム内やチーム間でさまざまな意見が推奨され、求められる
2.3.8.1. 複数の独自の視点
3. 進化
3.1. OPS 11. 学習、共有、改善
3.1.1. 継続的改善のプロセスを持つ
3.1.1.1. 優先順位
3.1.2. インシデント後の分析を実行する
3.1.2.1. 原因と予防措置
3.1.3. フィードバックループを実装する
3.1.3.1. 手順とワークロードに含める
3.1.4. ナレッジマネジメントを実行する
3.1.4.1. 最新ナレッジの維持
3.1.5. 改善の推進要因を定義する
3.1.5.1. Trailによる追跡
3.1.5.2. S3へのログの集約、Glue、Athena、QuickSight
3.1.6. インサイトを検証する
3.1.6.1. 部門の枠を超えて分析結果と回答を確認
3.1.7. 運用メトリクスのレビューを実行する
3.1.7.1. ビジネスの様々な領域からの参加
3.1.8. 教訓を文書化して共有する
3.1.8.1. チーム間の共有
3.1.8.2. IAMでのアクセス許可、CodeCommit、Lamda関数やAMIの共有
3.1.9. 改善を行うための時間を割り当てる
3.1.9.1. プロセス内に時間とリソースを割り当てる
4. 運用
4.1. OPS 8. ワークロードの状態の把握
4.1.1. 主要業績評価指標（KPI）を特定する
4.1.2. ワークロードのメトリクスを定義する
4.1.2.1. CloudWatch Application Insights
4.1.2.2. Container Insights
4.1.3. ワークロードメトリクスを収集および分析する
4.1.3.1. Personal Health Dashboard
4.1.3.2. S3へのログの集約、Glue、Athena、QuickSight
4.1.3.3. 集中ロギング | 実装 | AWS ソリューション
4.1.4. ワークロードメトリクスの基準値を設定する
4.1.4.1. ベースラインの確立、改善、調査、介入の閾値を特定
4.1.5. ワークロードの予想されるアクティビティのパターンについて学ぶ
4.1.5.1. Using CloudWatch Anomaly Detection - Amazon CloudWatchUsing CloudWatch Anomaly Detection - Amazon CloudWatch
4.1.6. ワークロードの結果にリスクがある場合に警告する
4.1.6.1. CloudWatch Logs Insights
4.1.7. ワークロードの異常が検出された場合に警告する
4.1.7.1. CloudWatch Anomaly Detection
4.1.8. KPIとメトリクスの成果の達成度と有効性を検証する
4.2. OPS 9. 運用状態の把握
4.2.1. 主要業績評価指標（KPI）を特定する
4.2.2. 運用メトリクスを定義する
4.2.2.1. MTTD、MTTR
4.2.3. 運用メトリクスを収集し、分析する
4.2.3.1. S3へのログの集約、Glue、Athena、QuickSight
4.2.4. 運用メトリクスの基準値を設定する
4.2.4.1. ベースラインの確立
4.2.5. 運用に対して予想されるアクティビティのパターンについて学ぶ
4.2.6. ワークロードの結果にリスクがある場合に警告する
4.2.6.1. CloudWatch Logs Insights
4.2.7. 運用の異常が検出された場合に警告する
4.2.7.1. CloudWatch Anomaly Detection
4.2.8. KPIとメトリクスの成果の達成度と有効性を検証する
4.3. OPS 10. イベントへの対応
4.3.1. イベント、インシデント、問題を管理するためのプロセスを使用する
4.3.1.1. Systems Manager OpsCenter
4.3.2. アラートごとのプロセスを使用する
4.3.2.1. ランブックまたはプレイブック
4.3.3. ビジネスへの影響に基づいて運用上のイベントの優先度を決定する
4.3.4. エスカレーション経路を決定する
4.3.4.1. ランブックまたはプレイブックでの定義
4.3.5. プッシュ通知を有効にする
4.3.5.1. 電子メール、SMSなど
4.3.6. ダッシュボードでステータスを知らせる
4.3.6.1. CloudWatch ダッシュボード
4.3.6.2. QuickSight
4.3.7. イベントへの対応を自動化する
4.3.7.1. CloudWatch イベント
4.3.7.2. CloudWatch アラーム
4.3.7.2.1. EC2アクション
4.3.7.2.2. Auto Scalingアクション
4.3.7.2.3. SNSトピック