© 2019, Amazon Web Services, Inc. or its affiliates オペレーションの優先順位 優先順位はどのように決定すればよいでしょうか? OPS 1 ワークロードに関する知見を得るための設計をする ワークロードの状態を理解できるようにするには、ワークロードをどう設計すればよいでしょうか? OPS 2 開発と統合 どのようにして欠点を減らし、修正を簡単にし、本番環境へのフローを改善しますか? OPS 3 デプロイのリスクの軽減 どのようにデプロイのリスクを軽減しますか? OPS 4 運用準備状況 ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか? OPS 5 運用上の優秀性を達成するには 効果的な準備が必要です ビジネスの成功は ビジネス 開発 運用の全体で目標と理解を共有することで実現できます 共通の基準が持つと ワークロードの設計と管理を簡素化することができ 運用上の成功をもたらします アプリケーション プラットフォーム インフラストラクチャのコンポーネント およびカスタマーエクスペリエンスと顧客の行動をモニタリングし インサイトを取得するメカニズムを使用してワークロードを設計します ワークロードまたは変更が本番環境に移行できる状態であり 運用上 サポートされていることを検証するためのメカニズムを作成します 運用準備状態はチェックリストを使用して検証し ワークロードが規定の標準を満たしていることと 必要な手順がランブックとプレイブックに適切に記載されていることを確認します ワークロードを効果的にサポートするために 十分にトレーニングを受けた担当者がいることを確認します 移行前に 運用上のイベントと障害への応答をテストします 障害の投入やゲームデーイベントによって サポートされる環境で応答を練習します … 準備 ワークロードの状態 ワークロードの正常性をどのように把握しますか? OPS 6 運用の正常性 オペレーションの正常性をどのように把握しますか? OPS 7 イベントへの対応 ワークロードと運用イベントはどのように管理しますか? OPS 8 ワークロードの運用の成功は ビジネスの成果と顧客の成果の達成度によって評価されます 予想される成果を定義し 成功を評価する方法を決定します また 運用が成功したかどうかを判断するための計算で使用するワークロードと運用のメトリクスを特定します ワークロードの状態と そのワークロードで実行する運用の状態と成功 デプロイとインシデント対応など の両方を含めて 運用の状態を検討します 運用の向上または低下を特定するための基準を確立し メトリクスを収集および分析します 次に 運用の成功に関する理解と 時間の経過とともにどのように変化するかについて検証します 収集したメトリクスを使用して 顧客とビジネスのニーズを満たしているかどうかを確認し 改善の余地がある分野を特定します 運用上の優秀性を実現するには 運用上のイベントを効率的かつ効果的に管理する必要があります これには 計画した運用上のイベントと計画外の運用上のイベントの両方が含まれます 十分に把握しているイベントには既定のランブックを使用し その他のイベントの解決にはプレイブックを使用します ビジネスと顧客への影響に基づいてイベントへの応答に優先順位を付けます イベントへの応答でアラートが発生する場合 実行する関連プロセスがあり 所有者が具体的に指名されていることを確認します イベントを解決する担当者を事前に決めておき 影響 期間 規模 範囲 に基づいて 必要に応じて他の担当者を関与させるためにエスカレーションするトリガーを含めます 以前に処理したことがないイベント応答によってビジネスに影響が及ぶ場合は アクションの方針を決定する権限を持つ担当者を特定し 関与させます 対象 顧客 ビジネス 開発者 運用など に合わせたダッシュボードと通知によってワークロードの運用状況が伝えられるため 適切なアクションの実行や予測の管理 通常の運用が再開される時期の把握を行うことができます 計画外のイベント および計画したイベントからの想定外の影響について根本原因を特定します この情報を使用して 将来イベントが発生した場合に問題を緩和できるように手順を更新します 必要に応じて影響するコミュニティに根本原因を知らせます … 運用 オペレーションの進化 オペレーションを進化させる方法 OPS 9 運用上の優秀性を維持するには運用の進化が必要です 継続的かつ段階的な改善を行うために専用の作業サイクルを作成します ワークロードと運用手順の両方について 改善の機会 機能のリクエスト 問題の修正 コンプライアンス要件など を定期的に評価し 優先順位を付けます 手順にフィードバックループを取り入れ 改善が必要な分野をすばやく特定し 実際に運用して教訓を学びます チーム間で学んだ教訓を共有し その教訓の利点を活用します 学んだ教訓に見られる傾向を分析し 運用のメトリクスに関してチーム間で遡及的分析を行い 改善の機会とその方法を特定します 改善をもたらす変更を実施し 結果を評価して成功の判断を行います … 進化 ビジネス価値を提供し、サポートのプロセスと手順を継続的に向上させるためにシステムを稼働およびモニタリングする能力 運用上の優秀性 認証情報管理 認証情報と認証をどのように管理していますか? SEC 1 人為的なアクセス 人為的なアクセスをどのように制御していますか? SEC 2 プログラムによるアクセス プログラムによるアクセスをどのように制御していますか? SEC 3 アイデンティティ管理とアクセス管理は情報セキュリティプログラムの重要な要素であり これによりお客様が意図した仕方で 承認され認証されたユーザーのみがリソースにアクセスできます 例えば プリンシパル つまり お客様のアカウントに対してアクションをとるユーザー グループ サービス ロール を定義し これらのプリンシパルに合わせたポリシーを構築し 強力な認証情報管理を実装できます これらの権限管理機能は認証と承認の中枢となっています … アイデンティティ管理とアクセス管理 セキュリティイベント セキュリティイベントをどのように検出し、調査していますか? SEC 4 セキュリティの認識 新しいセキュリティ脅威に対してどのように防御していますか? SEC 5 発見的統制により セキュリティの潜在的な脅威やインシデントを特定できます これはガバナンスフレームワークの最重要機能であり 品質管理プロセス 法的義務またはコンプライアンス義務 脅威の特定とその対応のサポートのために この機能を使用できます さまざまな種類の発見的統制があります 例えば アセットとそれらの詳細な属性のインベントリを実行することで より効果的に意思決定やライフサイクル管理を行い 運用の基準を確立できます また 内部監査という 情報システムに関連するコントロールの検査を行って ポリシーと要件に準拠し 定義した条件に基づいて正確に自動化されたアラート通知を設定できます これらのコントロールは 組織が異常なアクティビティの範囲を特定し把握するのに役立つ重要な対応機能です … 発見的統制 ネットワーク保護 ネットワークをどのように保護していますか? SEC 6 コンピューティング保護 コンピューティングリソースをどのように保護していますか? SEC 7 インフラストラクチャ保護には ベストプラクティスと組織の義務または規制上の義務に準拠するために必要な 深層防御などの制御手段が含まれています これらの手段を用いることは クラウドやオンプレミスの環境で滞りなく運用していくために特に重要です … インフラストラクチャ保護 データ分類 データをどのように分類していますか? SEC 8 保管中のデータの保護 保管中のデータをどのように保護していますか? SEC 9 伝送中のデータの保護 伝送中のデータをどのように保護していますか? SEC 10 システムを設計する前に セキュリティに影響を与える基本的なプラクティスを実施する必要があります 例えば データ分類は組織のデータを機密性レベルに基づいてカテゴリーに分類し 暗号化は認証されていないアクセスに対してデータが開示されてしまうことを防ぎます これらのツールやテクニックは 金銭的な損失の予防や規制遵守という目的を達成するためにも重要です … データ保護 インシデント対応 セキュリティインシデントにどのように対応していますか? SEC 11 非常に優れた予防的 発見的統制が実装されていてもなお 組織はセキュリティインシデントの潜在的な影響に対応し 影響を緩和する手段を講じる必要があります ワークロードのアーキテクチャは インシデントの際にチームが効果的に対応できるかどうか システムを隔離するかどうか 運用を既知の正常な状態に復元できるかどうかに大きく影響します セキュリティインシデントが起きる前にツールとアクセスを実践し 本番を想定したインシデント対応を定期的に実施することで タイムリーな調査と復旧を可能にするアーキテクチャを構築できます … インシデント対応 リスク評価とリスク軽減の戦略を通してビジネスに価値をもたらす、情報、システム、アセットのセキュリティ保護機能 セキュリティ サービスの制限 サービス制限をどのように管理していますか? REL 1 ネットワークトポロジ ネットワークトポロジをどのように管理していますか? REL 2 システムを設計する前に 信頼性に影響を与える基本的な要件を満たしておく必要があります 例えば データセンターへの十分なネットワーク帯域幅が必要です このような要件は 単一のプロジェクトの範囲を超えているため 無視される場合があります この点を無視すると システムの信頼性の達成に多大な影響が及びます オンプレミス環境では 依存関係により このような要件が長いリードタイムの原因となる可能性があるため 初期計画に組み込んでおく必要があります … 基盤 需要の処理 システムが需要の変化にどのように対応していますか? REL 3 リソースのモニタリング リソースをどのようにモニタリングしていますか? REL 4 変更管理 変更をどのように実施していますか? REL 5 変更がシステムに及ぼす影響に注意していれば 事前に計画できるようになります また モニタリングによってキャパシティーの問題や SLA 違反につながりかねない傾向をすばやく識別できます 従来の環境では 変更管理プロセスはしばしば手動で行われ 誰がいつ変更するかを効果的に制御するには 監査との注意深い連携が必要です … 変更管理 データバックアップ データをどうバックアップするか? REL 6 弾力性のある設計 どのようにしてシステムがコンポーネントのエラーに耐えるか? REL 7 弾力性テスト 弾⼒性をどのようにテストしていますか? REL 8 災害対策 災害対策をどのように計画していますか? REL 9 どのようなシステムでも ある程度複雑になると障害が発生することが予想されます そのため それらの障害をどのように検出して対応し 再発を防止するかが問題です … 障害の管理 インフラストラクチャやサービスの中断から復旧し、需要に適したコンピューティングリソースを動的に獲得し、誤設定や一時的なネットワークの問題といった中断の影響を緩和する能力 信頼性 アーキテクチャの選択 最も良いパフォーマンスのアーキテクチャをどのように選択していますか? PERF 1 コンピューティングの選択 コンピューティングソリューションをどのように選択していますか? PERF 2 ストレージの選択 ストレージソリューションをどのように選択していますか? PERF 3 データベースの選択 データベースソリューションをどのように選択していますか。 PERF 4 ネットワークの選択 ネットワークソリューションをどのように選択していますか? PERF 5 システムにとって最適なソリューションは お客様のワークロードの種類に応じて異なります 多くの場合 複数のアプローチを組み合わせて使用します 優れた設計のシステムでは複数のソリューションが使用され さまざまな機能によってパフォーマンスが改善されます … 選択 アーキテクチャの進化 ワークロードを進化させるためにどのように新機能を取り込んでいますか? PERF 6 ソリューションを設計するときは 選択できるオプションが限られていても 時間が経つにつれ アーキテクチャのパフォーマンスを向上させることができる新しいテクノロジーやアプローチが利用できるようになります … レビュー パフォーマンスのモニタリング リソースが正常に動作していることを確認するためにどのようにモニタリングしていますか? PERF 7 アーキテクチャの実装後は お客様が発見する前に問題を修正できるよう アーキテクチャのパフォーマンスをモニタリングする必要があります モニタリングメトリクスを使用して メトリクスがしきい値を超えたときにアラームを発生させるようにします アラームを使用すれば 正しく動作していないコンポーネントが見つかったときに そのコンポーネントを回避するための自動アクションをトリガーできます … モニタリング パフォーマンストレードオフ パフォーマンスを向上させるために、トレードオフをどのように利用していますか? PERF 8 ソリューションのアーキテクチャを設計する場合は トレードオフを考慮して最適なアプローチを選択します より高いパフォーマンスを実現できるように 整合性 耐久性 容量を重視するのか 時間またはレイテンシーを重視するのかを お客様の状況に応じてトレードオフしてください … トレードオフ システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力です パフォーマンス効率 使用状況ガバナンス 使用状況をどのように管理しますか? COST 1 使用状況とコストのモニタリング 使用状況とコストをどのようにモニタリングしますか? COST 2 リソースを削除する 不要なリソースをどのように削除しますか? COST 3 クラウドによる柔軟性と俊敏性の向上は イノベーションを促進し 開発とデプロイのペースを高めます クラウドによってオンプレミスインフラストラクチャのプロビジョニングに関連した手動プロセスや時間を省くことができます これにはハードウェア仕様の決定 価格交渉 注文管理 発送のスケジュール設定 リソースのデプロイなどが含まれます ただし この使いやすさと事実上無限のオンデマンドキャパシティーを生かすには 費用に対する新しい考え方が必要になります 多くのビジネスは さまざまなチームが運用する複数のシステムによって構成されています リソースのコストをそれぞれの組織や製品オーナーに帰属させることができると リソースを効率的に使用し 無駄を削減できます コストの帰属を明確にすることで 実際に利益率の高い製品を把握し 予算の配分先についてより多くの情報に基づいた決定ができるようになります … 費用認識 サービスの選択 サービスを選択するとき、どのようにコストを評価しますか? COST 4 リソースタイプとサイズの選択 リソースタイプとサイズを選択する際、どうすればコスト目標を達成できるでしょうか? COST 5 料金モデルの選択 コストを削減するには、料金モデルをどのように使用したらよいでしょうか? COST 6 データ転送の計画 データ転送料金についてどのように計画していますか? COST 7 ワークロードにとって適切なインスタンスとリソースを使用することが コスト削減の鍵になります たとえば レポート処理を小規模なサーバーで実行すると 5 時間かかるものの 費用が 2 倍の大規模なサーバーでは 1 時間で実行できるとします どちらのサーバーでも同じ結果が得られますが 長期的に見れば小規模なサーバーで発生するコストの方が大きくなります 優れた設計のワークロードでは最もコスト効率の良いリソースが使用されるため 大幅にプラスの経済的影響が生じます また マネージドサービスを使用することで コストを削減できる場合もあります 例えば E メールを配信するためにサーバーを保守することなく メッセージ単位で料金が発生するサービスを使用できます … 費用対効果の高いリソース 需要と供給の一致 リソースの供給と顧客の需要をどのように一致させていますか? COST 8 需要と供給を最適に一致させることでワークロードのコストを最低限に抑えることができますが プロビジョニングの時間と個々のリソースの障害に備えて十分に余裕を持った供給も必要です 需要が一定の場合も変動する場合もあり 管理に多大なコストがかからないようにメトリクスと自動化が必要です … 需要と供給を一致させる 新しいサービスの評価 新しいサービスをどのように評価していますか? COST 9 AWS では新しいサービスと機能がリリースされるため 既存のアーキテクチャの決定をレビューし 現在でもコスト効率が最も優れているかどうかを確認することがベストプラクティスです 要件の変化に応じて 不要になったリソース サービス全体 システムを積極的に廃止してください … 長期的な最適化 最も低い価格でシステムを運用してビジネス価値を実現する能力 コスト最適化