インシデント管理サービスのコミットメント

ケース 1: 既知の影響があるイベントが生成されます。AMS はインシデントを開き、通知します。

ケース 2: AMS から連絡があり、イベントの影響を確認します。イベントがインシデントであることを確認します。

ケース 3: 問題に気づき、インシデントレポートを送信します。

インシデント対応とインシデント解決のクロックは、次の場合に開始されます。

ケース 1: AMS はインシデントを作成します。

ケース 2: アラートがインシデントであることを確認します。

ケース 3: インシデントを送信します。

サービスコミットメントは、作成されたインシデントの優先度によって異なります。

インシデントを送信すると、AMS は確認応答を送信します。

AMS がユーザーに代わってインシデントを作成する場合、別のインシデント対応は送信されません。

インシデント解決のクロックはティックを継続します。

AMS がインシデント確認を送信すると、インシデント対応時間のクロックが停止します。

問題のリソース/サービスについて、AMS はヘルスをチェックして以下を確認します。

送信したインシデントの優先順位が正しくない場合、AMS はそのインシデントの優先順位を再設定します。AMS がインシデントの優先度を変更すると、優先度の変更の根拠とともに通知が送信されます。場合によっては、送信した問題が、原因によってはインシデントとして認定されないことがあります。このような場合、AMS はインシデントを終了し、その理由を説明する通知を送信します。イベントの分類に関係なく、AMS は必要に応じてサポートします。

インシデント分類のルールについては、「」を参照してくださいインシデントの優先度。

インシデントの優先度が変更された場合、新しい優先度のサービスコミットメントが適用されます。クロックはティックを継続します。インシデントの定義を満たさないためにインシデントがクローズされた場合、サービスコミットメントは適用されません。クロックは停止します。

AMS はインシデントに取り組み、サービスコミットメント内で解決します。場合によっては、利用できないスタック (複数可) またはリソース (複数可) をタイムリーに解決できないと AMS が判断した場合、AMS は解決のオプションとしてインフラストラクチャの復元を提供します。インフラストラクチャの復元では、影響を受けるスタックのテンプレート (複数可) に基づいて既存のスタック (複数可) を再デプロイし、ユーザーが特に指定しない限り、最後の既知の復元ポイント (EBS/RDS スナップショット) に基づいてデータ復元を開始します。個々の EC2 インスタンスのエフェメラルデータは失われます。AWS の推奨に従ってインフラストラクチャの復元を許可しない場合、関連する Incident Resolution Time Service コミットメントのサービスクレジットは付与されません。

クロックは、次の場合に停止します。

AMS では、事前に定義され、承認されたアクションがない限り、インシデント解決作業を進めるための明確化やアクティビティが必要になることがあります。その結果、インシデントを解決するために AMS とユーザーの間で通信が行われます。

クロックは、AMS がユーザーからの応答またはアクションを待っているときに停止します。

クロックは、AMS がユーザーからレスポンスを受け取るか、AMS が必要とするアクションが完了したときに再起動します。