AWS W-A Framework 運用上の優秀性の柱をマインドマップ化してみた

コンバンハ、千葉（幸）です。

AWS Well-Architected フレームワークの運用上の優秀性の柱をマインドマップ化してみました。

マインドマップ

• 手元でツリーの開閉、拡大・縮小ができます
• 右上のアイコンから全画面表示ができます

このマップについて

上記のマップは以下のドキュメントのアウトラインを表したものです。

（PDF版）

ドキュメントの構成について

• 設計原則と定義が冒頭で示される
  • 設計原則はドキュメントのエッセンスを要約したもの
  • 定義は領域（分野とも訳される）と場合によってはその他の事項が示される
• 各領域のベストプラクティスが本文で記載されている
• 各領域は複数の階層からなる
• ドキュメントの記載の多くは AWS Well-Architected Tool の「質問」とチェック項目に対応する

マップの凡例について

• 赤塗りつぶしは AWS Well-Architected Tool の「質問」に相当する
• 黄色塗りつぶしは「領域」あるいはその一階層下の中項目を表す
• グレーアウトの箇所は AWS Well-Architected Tool に該当しないことを表す

詳細は以下エントリを参照してください。

本エントリのマップでは、上記エントリのマップより一階層下げた部分まで記載しています。

補足

マップ中央の直下の階層は各「領域（分野）」としており、以下のような順番で昇順となっています。

AWS Well-Architected フレームワーク 運用上の優秀性の柱

概要を記載します。便宜上、「領域（分野）」に番号を振っています。

設計原則

• 運用をコードとして運用
• 定期的に、小規模な、元に戻すことができる変更を適用する
• 運用手順を定期的に改善する
• 障害を予想する
• あらゆる運用上の障害から学ぶ

領域1. 組織

• OPS 1. 組織の優先順位
  • 外部顧客のニーズを評価する
  • 内部顧客のニーズを評価する
  • ガバナンス要件を評価する
  • 外部のコンプライアンス要件を評価する
  • 脅威の状況を評価する
  • トレードオフを評価する
  • メリットとリスクを管理する
• 運用モデル
  • 運用モデル2 x 2 の表現
    • 完全に分離された運用モデル
    • 分離されたAEOと一元化されたガバナンスを備えたIEO
    • 分離されたAEOおよび一元化されたガバナンスとサービスプロバイダを備えたIEO
    • 分離されたAEOと一元化されていないガバナンスを備えたIEO
  • OPS 2. 関係性と所有権
    • リソースに特定された所有権が存在する
    • プロセスと手順に特定された所有者が存在する
    • パフォーマンスに責任を持つ所有者が運用アクティビティに存在する
    • チームメンバーが自らの責任範囲を把握する
    • 責任と所有権を特定するためのメカニズムが存在する
    • 追加、変更、例外をリクエストするメカニズムが存在する
    • チーム間の責任は事前定義済みまたは交渉済みである
• OPS 3. 組織カルチャー
  • エグゼクティブスポンサー
  • チームメンバーに、結果とリスクがあるときにアクションを実行する権限が付与されている
  • エスカレーションが推奨されている
  • コミュニケーションが、タイムリーで明確かつ実用的なものである
  • 実験が推奨されている
  • チームメンバーがスキルセットを維持、強化することができ、それを推奨されている
  • チームに適正なリソースを提供する
  • チーム内やチーム間でさまざまな意見が推奨され、求められる

領域2. 準備

• OPS 4. テレメトリを設計する
  • アプリケーションテレメトリーを実装する
  • ワークロードテレメトリーを実装して設定する
  • ユーザーアクティビティテレメトリーを実装する
  • 依存関係のテレメトリーを実装する
  • トランザクショントレーサビリティを実装する
• OPS 5. 運用のための設計
  • バージョン管理を使用する
  • 変更をテストし、検証する
  • 設定管理システムを使用する
  • 構築およびデプロイ管理システムを使用する
  • パッチ管理を実行する
  • 設計標準を共有する
  • コード品質の向上のためにプラクティスを実装する
  • 小規模かつ可逆的な変更を頻繁に行う
  • 統合とデプロイを完全自動化する
• OPS 6. デプロイのリスクを緩和する
  • 変更の失敗に備える
  • 変更をテストし、検証する
  • デプロイ管理システムを使用する
  • 限定的なデプロイを使用してテストする
  • 並列環境でデプロイする
  • 小規模で可逆的な変更を頻繁にデプロイする
  • 統合とデプロイを完全自動化する
  • テストとロールバックを自動化する
• OPS 7. 運用準備状況
  • 従業員の対応力を確保する
  • 運用準備状況の継続的な確認を実現する
  • ランブックを使用して手順を実行する
  • プレイブックを使用して問題を特定する
  • システムや変更をデプロイするために十分な情報に基づいて決定を下す

領域3. 運用

• OPS 8. ワークロードの状態の把握
  • 主要業績評価指標（KPI）を特定する
  • ワークロードのメトリクスを定義する
  • ワークロードメトリクスを収集および分析する
  • ワークロードメトリクスの基準値を設定する
  • ワークロードの予想されるアクティビティのパターンについて学ぶ
  • ワークロードの結果にリスクがある場合に警告する
  • ワークロードの異常が検出された場合に警告する
  • KPIとメトリクスの成果の達成度と有効性を検証する
• OPS 9. 運用状態の把握
  • 主要業績評価指標（KPI）を特定する
  • 運用メトリクスを定義する
  • 運用メトリクスを収集し、分析する
  • 運用メトリクスの基準値を設定する
  • 運用に対して予想されるアクティビティのパターンについて学ぶ
  • ワークロードの結果にリスクがある場合に警告する
  • 運用の異常が検出された場合に警告する
  • KPIとメトリクスの成果の達成度と有効性を検証する
• OPS 10. イベントへの対応
  • イベント、インシデント、問題を管理するためのプロセスを使用する
  • アラートごとのプロセスを使用する
  • ビジネスへの影響に基づいて運用上のイベントの優先度を決定する
  • エスカレーション経路を決定する
  • プッシュ通知を有効にする
  • ダッシュボードでステータスを知らせる
  • イベントへの対応を自動化する

領域4. 進化

• OPS 11. 学習、共有、改善
  • 継続的改善のプロセスを持つ
  • インシデント後の分析を実行する
  • フィードバックループを実装する
  • ナレッジマネジメントを実行する
  • 改善の推進要因を定義する
  • インサイトを検証する
  • 運用メトリクスのレビューを実行する
  • 教訓を文書化して共有する
  • 改善を行うための時間を割り当てる

参考