© 2020, Amazon Web Services, Inc. or its affiliates オペレーションの優先順位 優先順位はどのように決定すればよいでしょうか? OPS 1 運用モデル ビジネスの成果をサポートするために、組織をどのように構築しますか? OPS 2 組織カルチャー 組織の文化はビジネスの成果をどのようにサポートしますか? OPS 3  チームは ビジネスの成功を実現する優先順位を設定するために ワークロード全体 その役割 共有されるビジネス目標に関する理解を共有する必要があります 優先順位を明確に定義することで 努力を通じて得られるメリットが最大限に活かされます ビジネス 開発 運用チームなど 主要な利害関係者が関わる社内外の顧客のニーズを評価し 重点領域を決定します 顧客ニーズを評価することにより ビジネス成果を達成するために必要なサポートについて十分に理解できるようになります 組織のガバナンスによって定義されたガイドラインや義務 および特定の重点領域の必須化や重視が必要となる可能性のある規制コンプライアンス要件や業界標準などの外部要因をしっかりと認識します 内部ガバナンスおよび外部コンプライアンス要件への変更を識別するメカニズムがあることを検証します 要件が特定されていない場合は 必ずこの決定にデューデリジェンスが適用されていることを確認します ニーズの変化に応じて更新できるように 優先順位を定期的に確認します ビジネスに対する脅威 たとえば ビジネスリスクと負債や情報セキュリティの脅威 を評価し この情報をリスクレジストリに保持します リスクの影響を評価し 競合する利益のトレードオフや代替アプローチを評価します たとえば 新しい機能の市場投入までの時間を短縮することは コストの最適化よりも重視されます または 非リレーショナルデータ用にリレーショナルデータベースを選択すれば リファクタリングなしで システムの移行が簡素化されます メリットとリスクを管理し 重点領域を決定する際に十分な情報に基づいて意思決定を下せるようにします 一部のリスクや選択肢は 一定期間許容される可能性があり 関連するリスクを軽減できる場合もあれば リスクが残るのを容認できない場合もあります その場合 リスクに対処するための措置を講じることになります チームはビジネスの成果を達成するうえでの役割を理解する必要があります チームは他のチームが成功するためのそれぞれの役割を理解し 自分たちのチームが成功するための他のチームの役割を理解し 目標を共有する必要があります 責任 所有権 意思決定方法 意思決定を行う権限を持つユーザーを理解することは 労力を集中的に投入し チームの利点を最大化するのに役立ちます チームのニーズは サポートする顧客 組織 チームの構成 およびワークロードの特性によって形成されます 1 つの運用モデルで組織内のすべてのチームとそのワークロードをサポートできると思うのは不合理です アプリケーション ワークロード プラットフォーム インフラストラクチャの各コンポーネントの所有者が特定されていること および各プロセスと手順の定義を担当する所有者 およびそのパフォーマンスに責任を持つ所有者が特定されていることを確認します 各コンポーネント プロセス 手順のビジネス価値 それらのリソースが配置されている理由やアクティビティが実行されている理由 所有権が存在する理由を理解することで チームメンバーのアクションが明らかになります チームメンバーの責任を明確に定義することで 当該メンバーが適切に行動し 責任と所有権を識別するメカニズムを持つことができます イノベーションを制約しないように 追加 変更 例外をリクエストするメカニズムを備えます チームがどのように連携して相互にサポートするのか また ビジネスの成果について チーム間の合意を定義します チームメンバーにサポートを提供することで チームメンバーがより効果的に行動し ビジネスの成果をサポートできるようにします 業務を委嘱された上級リーダーは 目標値を設定し 成功を測定する必要があります 上級リーダーは ベストプラクティスの採用と組織の進化の協賛者 支持者 および推進者である必要があります 影響を最小限に抑えるために 結果にリスクがある場合は措置を講じるようにチームメンバーの意識を高めるとともに リスクに対処し インシデントを回避できるようにするため リスクがあるとチームメンバーが考える場合は 意思決定者や利害関係者にエスカレーションすることを推奨します チームメンバーがタイムリーで適切な措置を講じることができるように 既知のリスクと計画されたイベントについて 適時かつ明確で実用的なコミュニケーションを行います 学習を加速するための実験を奨励し チームメンバーが関心と当事者意識を持ち続けるようにします チームは 新しいテクノロジーを採用し 需要と責任の変化をサポートするために スキルセットを強化する必要があります 専ら学習のために設けられた時間を提供することで これをサポートし 奨励します チームメンバーが成功し ビジネスの成果をサポートするためにスケールできるように ツールとチームメンバーの両方のリソースを持っていることを確認します 組織間の多様性を活用して 複数のユニークな視点を追求します この視点を使用して イノベーションを高め 想定に挑み 確証バイアスに傾くリスクを軽減します チーム内のインクルージョン 多様性 アクセシビリティを向上させ 有益な視点を得ます … 組織 ワークロードに関する知見を得るための設計をする どのようにワークロードを設計して、その状態を理解できるようにするのですか? OPS 4 開発と統合 どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか? OPS 5 デプロイのリスクの軽減 どのようにデプロイのリスクを軽減しますか? OPS 6 運用準備状況 ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか? OPS 7  運用上の優秀性を準備するには ワークロードと期待される動作を理解する必要があります そうすることでワークロードの状況を把握し ワークロードをサポートする手順を構築するように設計できます ワークロードを設計する際には 可観測性と問題調査への対応においてすべてのコンポーネントにわたって内部状態 メトリクス ログ イベント トレースなど を理解するために必要な情報が送出されるようにします ワークロードの稼働状態を監視し 結果にリスクがあった場合にそれを特定し 効果的な対応を可能にするために必要なテレメトリの開発を繰り返します ワークロードを計測する際は フィルターを使用して時間の経過とともに最も有用な情報を選択できるので 状況認識を可能にする幅広い情報 状態の変化 ユーザーのアクティビティ 権限アクセス 使用量のカウンターなど を取得します リファクタリング 品質についてのすばやいフィードバック バグ修正を可能にし 本番環境への変更のフローを改善するアプローチを採用します これらは 本番環境移行時における有益な変更を促進し デプロイされた問題を制限するとともに お客様の環境において デプロイメントアクティビティを通じて生じた問題 または検出された問題をすばやく特定し 修正できるようにします 品質に関する迅速なフィードバックを提供し 望ましい結果をもたらさない変更から迅速に復旧できるようにするアプローチを採用します これらを実践することにより 変更のデプロイメントによって生じる問題の影響が軽減されます 変更が失敗した場合の計画を立てて 必要な場合は迅速に対応し 変更をテストして検証できるようにします 環境で計画されたアクティビティに注意して 計画されたアクティビティに影響する変更のリスクを管理できるようにします 頻繁で小さく可逆的な変更に重点を置いて 変更の範囲を制限します これにより トラブルシューティングが容易になり 修復がすばやくできるようになります また 変更をロールバックすることもできます また より頻繁に重要な変更の恩恵を受けることができることを意味します ワークロード プロセス 手順 および従業員の運用準備状況を評価し ワークロードに関連する運用上のリスクを理解します 一貫性のあるプロセス 手作業または自動化によるチェックリストを含む を使用して いつワークロードまたは変更を本稼働する準備ができるかを知る必要があります また これにより 対処する計画を立てる必要がある領域を見つけることもできます 日常的な活動を文書化したランブックと 問題解決のためにプロセスを導くプレイブックを備えます メリットとリスクを理解し 十分な情報に基づく決定を下して 変更が本稼働環境に入ることを可能にします … 準備 ワークロードの状態 ワークロードの正常性をどのように把握しますか? OPS 8 運用の正常性 オペレーションの正常性をどのように把握しますか? OPS 9 イベントへの対応 ワークロードと運用イベントはどのように管理しますか? OPS 10  ワークロードの運用の成功は ビジネスの成果と顧客の成果の達成度によって評価されます 予想される成果を定義し 成功を評価する方法を決定します また ワークロードおよび運用が成功したかどうかを判断するための計算で使用するメトリクスを特定します 運用状態には ワークロードの状態と そのワークロードのサポートにおいて実行されるオペレーション活動の状態と成功 デプロイとインシデント対応など の両方を含みます 改善 調査 介入のためのメトリクスのベースラインを確立し メトリクスを収集して分析し オペレーションの成功と経時的な変化について理解していることを検証します 収集したメトリクスを使用して 顧客とビジネスのニーズを満たしているかどうかを確認し 改善の余地がある分野を特定します 運用上の優秀性を実現するには 運用上のイベントを効率的かつ効果的に管理する必要があります 計画的および予期しない運用イベントの両方に適用されます 十分に把握しているイベントには既定のランブックを使用し 問題の調査および解決にはプレイブックを使用します ビジネスと顧客への影響に基づいてイベントへの応答に優先順位を付けます イベントへの応答でアラートが発生する場合 実行する関連プロセスがあり 所有者が具体的に指名されていることを確認します イベントを解決する担当者を事前に決めておき 緊急性および影響に基づき 必要に応じて他の担当者を関与させるためにエスカレーションするトリガーを含めます 以前に処理したことがないイベント応答によってビジネスに影響が及ぶ場合は アクションの方針を決定する権限を持つ担当者を特定し 関与させます 対象 顧客 ビジネス 開発者 運用など に合わせたダッシュボードと通知によってワークロードの運用状況が伝えられるため 適切なアクションの実行や予測の管理 通常の運用が再開される時期の把握を行うことができます … 運用 オペレーションの進化 オペレーションを進化させる方法 OPS 11  運用上の優秀性を維持するには 学び 共有し 継続的に改善する必要があります 継続的かつ段階的な改善を行うために専用の作業サイクルを作成します 顧客に影響を与えるすべてのイベントについて インシデント後の分析を実行します 反復を制限または防止する要因と予防措置を特定します 必要に応じて 影響を受けたコミュニティと貢献要因を伝達します ワークロードと運用手順の両方について 改善の機会 機能のリクエスト 問題の修正 コンプライアンス要件など を定期的に評価し 優先順位を付けます 手順にフィードバックループを取り入れ 改善が必要な分野をすばやく特定し 実際に運用して教訓を学びます チーム間で学んだ教訓を共有し その教訓の利点を活用します 学んだ教訓に見られる傾向を分析し 運用のメトリクスに関してチーム間で遡及的分析を行い 改善の機会とその方法を特定します 改善をもたらす変更を実施し 結果を評価して成功の判断を行います … 進化 開発をサポートし、ワークロードを効率的に実行し、運用に関する洞察を得て、ビジネス価値をもたらすためのサポートプロセスと手順を継続的に改善する能力。 運用上の優秀性 運用のセキュリティを確保する ワークロードを安全に運用するには、どうすればよいですか? SEC 1 ワークロードを安全に運用するには セキュリティのすべての領域に包括的なベストプラクティスを適用する必要があります 組織レベルおよびワークロードレベルにおいて 運用上の優秀性で定義した要件とプロセスを抽出し それらをすべての領域に適用します … セキュリティ 認証 ユーザー ID とマシン ID はどのように管理したらよいでしょうか? SEC 2 認証とアクセスコントロール 人とマシンのアクセス許可はどのように管理すればよいでしょうか? SEC 3 アイデンティティとアクセスの管理は情報セキュリティプログラムの重要な要素です これにより お客様が意図した方法で承認 認証されたユーザーおよびコンポーネントのみがリソースにアクセスできるようになります たとえば プリンシパル つまり お客様のアカウントに対してアクションをとるアカウント ユーザー ロール サービス を定義し これらのプリンシパルに合わせたポリシーを構築し 強力な認証情報管理を実装できます これらの権限管理機能は認証と承認の中枢となっています … Identity & Access Management セキュリティイベント セキュリティイベントをどのように検出し、調査していますか？ SEC 4 発見的統制により セキュリティの潜在的な脅威やインシデントを特定できます これはガバナンスフレームワークの最重要機能であり 品質管理プロセス 法的義務またはコンプライアンス義務 脅威の特定とその対応のサポートのために この機能を使用できます さまざまな種類の発見的統制があります 例えば アセットとそれらの詳細な属性のインベントリを実行することで より効果的に意思決定やライフサイクル管理を行い 運用の基準を確立できます また 内部監査という 情報システムに関連するコントロールの検査を行って ポリシーと要件に準拠し 定義した条件に基づいて正確に自動化されたアラート通知を設定できます これらのコントロールは 組織が異常なアクティビティの範囲を特定し把握するのに役立つ重要な対応機能です … 検出 ネットワーク保護 ネットワークリソースをどのように保護しますか? SEC 5 コンピューティング保護 コンピューティングリソースをどのように保護していますか? SEC 6 インフラストラクチャ保護には ベストプラクティスと組織の義務または規制上の義務に準拠するために必要な 深層防御などの制御手段が含まれています これらの手段を用いることは クラウドやオンプレミスの環境で滞りなく運用していくために特に重要です … インフラストラクチャ保護 データ分類 どのようにデータを分類していますか? SEC 7 保管中のデータの保護 保管時のデータをどのように保護していますか? SEC 8 伝送中のデータの保護 転送時のデータをどのように保護していますか? SEC 9 システムを設計する前に セキュリティに影響を与える基本的なプラクティスを実施する必要があります 例えば データ分類は組織のデータを機密性レベルに基づいてカテゴリーに分類し 暗号化は認証されていないアクセスに対してデータが開示されてしまうことを防ぎます これらのツールやテクニックは 金銭的な損失の予防や規制遵守という目的を達成するためにも重要です … データ保護 インシデント対応 インシデントの予測、対応、復旧はどのように行いますか? SEC 10 非常に優れた予防的 発見的統制が実装されていてもなお 組織はセキュリティインシデントの潜在的な影響に対応し 影響を緩和する手段を講じる必要があります ワークロードのアーキテクチャは インシデントの際にチームが効果的に対応できるかどうか システムを隔離するかどうか 運用を既知の正常な状態に復元できるかどうかに大きく影響します セキュリティインシデントが起きる前にツールとアクセスを実践し 本番を想定したインシデント対応を定期的に実施することで タイムリーな調査と復旧を可能にするアーキテクチャを構築できます … インシデント対応 このセキュリティの柱では、データ、システム、資産を保護して、クラウドテクノロジーを活用し、セキュリティを向上させる機能について説明します。 セキュリティ サービスクォータと制約 サービスクォータと制約はどのように管理しますか? REL 1 ネットワークトポロジ ネットワークトポロジをどのように計画しますか? REL 2 基盤となる要件は 単一のワークロードまたはプロジェクトの範囲を超える要件です システムを設計する前に 信頼性に影響を与える基本的な要件を満たしておく必要があります 例えば データセンターへの十分なネットワーク帯域幅が必要です … 基盤 サービスアーキテクチャ どのようにワークロードサービスアーキテクチャを設計すればよいですか? REL 3 障害を防ぐための操作を設計する 障害を防ぐために、分散システムの操作をどのように設計しますか? REL 4 障害を軽減するための操作を設計する 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか? REL 5 信頼性の高いワークロードは ソフトウェアとインフラストラクチャの両方について事前に設計を決定することから始まります アーキテクチャの選択は 5 つの Well Architected の柱すべてにかけてワークロードの動作に影響を与えます 高い信頼性を保つには 特定のパターンに従う必要があります … ワークロードアーキテクチャ リソースのモニタリング ワークロードリソースをモニタリングするにはどうすればよいですか? REL 6 需要の処理 需要の変化に適応するようにワークロードを設計するには、どうすればよいですか? REL 7 変更管理 変更はどのように実装するのですか? REL 8 ワークロードを信頼できる形で実行するには ワークロードやその環境に対する変化を予測して対応することが不可欠です 変更には 需要の急増などのワークロードに負荷がかかる変更や 機能のデプロイやセキュリティパッチの適用といった内部からの変更があります … 変更管理 データバックアップ データはどのようにバックアップするのですか? REL 9 障害分離 ワークロードを保護するために障害分離をどのように使用しますか? REL 10 弾力性のある設計 コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか? REL 11 信頼性テスト どのように信頼性をテストしますか? REL 12 災害対策 災害対策 (DR) はどのように計画するのですか? REL 13 どのようなシステムでも ある程度複雑になると障害が発生することが予想されます 信頼性は 発生時点で障害を認識し 可用性への影響を回避するための措置を講じることをワークロードに要求します ワークロードは 障害に耐え 問題を自動的に修復できる必要があります … 障害の管理 期待されるタイミングで、意図した機能を正確かつ一貫して実行するワークロードの能力。これには、そのライフサイクル全体を通じてワークロードを運用およびテストする機能が含まれます。 信頼性 アーキテクチャの選択 どのように最良パフォーマンスのアーキテクチャを選択するのですか? PERF 1 コンピューティングの選択 コンピューティングソリューションはどのように選択するのですか? PERF 2 ストレージの選択 ストレージソリューションをどのように選択していますか? PERF 3 データベースの選択 データベースソリューションをどのように選択していますか。 PERF 4 ネットワークの選択 どのようにネットワーキングソリューションを選択するのですか? PERF 5  特定のワークロードに最適なソリューションはさまざまで 大抵の場合 ソリューションには複数のアプローチが組み合わされています 優れた設計のワークロードは パフォーマンスを向上させるために複数のソリューションを使用し 異なる機能を有効化します … 選択 アーキテクチャの進化 ワークロードを進化させるためにどのように新機能を取り込んでいますか？ PERF 6 クラウドテクノロジーは急速に進化しているため ワークロードコンポーネントが新しいテクノロジーとアプローチを使用してパフォーマンスを継続的に改善できるようにする必要があります ワークロードコンポーネントに対する変更を継続的に評価して検討し パフォーマンスとコストの目標を確実に満たすようにする必要があります 機械学習や人工知能 AI などの新しいテクノロジーにより カスタマーエクスペリエンスを再考し ビジネスワークロード全体にわたってイノベーションを起こすことができます … レビュー パフォーマンスをモニタリングする リソースが稼働していることを確実にするためのリソースのモニタリングはどのように行いますか? PERF 7  ワークロードを実装した後は そのパフォーマンスをモニタリングして 問題が顧客に影響を及ぼす前に修正できるようにする必要があります モニタリングメトリクスは しきい値を超えたときにアラームを発行するために使用するようにしてください … モニタリング パフォーマンストレードオフ トレードオフをどのように使用するとパフォーマンスが向上するのですか? PERF 8  ソリューションを設計するときは 最適なアプローチを確保するためにトレードオフを考慮します 状況に応じて 整合性 耐久性 および時間とレイテンシーの余裕と引き換えに より優れたパフォーマンスを実現することができます … トレードオフ システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力。 パフォーマンス効率 クラウド財務管理 クラウド財務管理はどのように実装しますか? COST 1  クラウドの導入により 承認 調達 インフラストラクチャのデプロイサイクルが短縮されるため 技術チームは より迅速にイノベーションを起こすことができます ビジネス価値と財務的な成功を実現するには クラウドでの財務管理に対する新たなアプローチが必要です このアプローチとはクラウド財務管理であり 組織全体での知識の蓄積 プログラム リソース プロセスを実装することで 組織全体の機能を構築します 多くの組織は 異なる優先順位を持つ多数の異なる単位で構成されています 合意された一連の財務目標に整合するように組織を調整し それらを満たすメカニズムを組織に提供することで より効率的な組織を構築できます 有能な組織は より迅速にイノベーションを進め より迅速に構築し より俊敏になり 内部的または外部的要因に合わせて自らを調整します … クラウド財務管理を実践する 使用状況ガバナンス 使用状況をどのように管理しますか? COST 2 使用状況とコストのモニタリング 使用状況とコストをどのようにモニタリングしますか? COST 3 リソースを削除する 不要なリソースをどのように削除しますか？ COST 4 クラウドによる柔軟性と俊敏性の向上は イノベーションを促進し 開発とデプロイのペースを高めます クラウドによってオンプレミスインフラストラクチャのプロビジョニングに関連した手動プロセスや時間を省くことができます これにはハードウェア仕様の決定 価格交渉 注文管理 発送のスケジュール設定 リソースのデプロイなどが含まれます ただし この使いやすさと事実上無限のオンデマンドキャパシティーを生かすには 費用に対する新しい考え方が必要になります 多くのビジネスは さまざまなチームが運用する複数のシステムによって構成されています リソースのコストをそれぞれの組織や製品オーナーに帰属させることができると リソースを効率的に使用し 無駄を削減できます コストの帰属を明確にすることで 実際に利益率の高い製品を把握し 予算の配分先についてより多くの情報に基づいた決定ができるようになります … 経費支出と使用量の認識 サービスの選択 サービスを選択するとき、どのようにコストを評価しますか? COST 5 リソースタイプ、リソースサイズ、およびリソース数を選択する コストターゲットに合わせて、リソースタイプ、リソースサイズ、およびリソース数を選択するには、どうすればよいですか? COST 6 料金モデルの選択 コストを削減するには、料金モデルをどのように使用したらよいでしょうか? COST 7 データ転送の計画 データ転送料金についてどのように計画していますか？ COST 8 ワークロードにとって適切なインスタンスとリソースを使用することが コスト削減の鍵になります たとえば レポート処理を小規模なサーバーで実行すると 5 時間かかるものの 費用が 2 倍の大規模なサーバーでは 1 時間で実行できるとします どちらのサーバーでも同じ結果が得られますが 長期的に見れば小規模なサーバーで発生するコストの方が大きくなります 優れた設計のワークロードでは最もコスト効率の良いリソースが使用されるため 大幅にプラスの経済的影響が生じます また マネージドサービスを使用することで コストを削減できる場合もあります 例えば E メールを配信するためにサーバーを保守することなく メッセージ単位で料金が発生するサービスを使用できます … 費用対効果の高いリソース 需要を管理し、リソースを供給する どのように需要を管理し、リソースを供給しますか? COST 9 クラウドに移行すると お支払いは必要な分のみになります 必要な時にワークロードの需要に合わせたリソースを供給できるため コストがかかる無駄なオーバープロビジョニングの必要性を排除できます また スロットル バッファ またはキューを使用して 需要を滑らかにし 少ないリソースで供給することで コストを削減したり 後でバッチサービスで処理したりできます … 需要を管理し、リソースを供給する 新しいサービスの評価 新しいサービスをどのように評価していますか？ COST 10 AWS では新しいサービスと機能がリリースされるため 既存のアーキテクチャの決定をレビューし 現在でもコスト効率が最も優れているかどうかを確認することがベストプラクティスです 要件の変化に応じて 不要になったリソース サービス全体 システムを積極的に廃止してください … 経時的な最適化 最も低い価格でシステムを運用してビジネス価値を実現する能力 コスト最適化