AWS サポートへケース起票する際に緊急度に迷ったら読む記事
この記事は アノテーション株式会社 AWS Technical Support Advent Calendar 2022 | Advent Calendar 2022 - Qiita 1日目の記事です。
はじめに
AWS サポートへ問い合わせを行う際には、緊急度の指定が必要となりますが、どの緊急度を指定するかを迷うことはありませんか？
この記事では、緊急度の選択指針について記載をしていきます。
よく問い合わせを行う方も、再度読み直せるような内容になっていますので、ぜひご一読をいただけますと幸いです。
緊急度について
AWS サポートへサポートケースを起票する際には、以下の緊急度があります。
| 緊急度 | 初回の応答時間 | 説明 |
|---|---|---|
| 通常の問い合わせ/機能要望 | 24時間 | 開発に関する一般的な質問がある場合、または機能をリクエストしたい場合 |
| 障害/開発中の急ぎの問い合わせ | 12時間 | アプリケーションの重要ではない機能が正常に動作していない場合、または開発に関して短期間で回答が必要な質問がある場合 |
| 発生中の障害 | 4時間 | アプリケーションの重要な機能に、障害またはデグレードが発生している場合 |
| 発生中の障害(ビジネスへの影響大) | 1時間 | ビジネスに重大な影響が出ている場合。アプリケーションの重要な機能を使用できない場合 |
緊急度が高くなるほどに、初回の応答時間が短くなり、ビジネスへの影響度についての言及が含まれていることが分かるかと思います。
問題発生時、極力早く解決したいという気持ちになるのは当然です。そのため、緊急度はできうる限り高く設定したくなる心情になるものと推察します。
しかしながら、AWS サポートへすべての問い合わせを緊急事態として起票をしていいものでしょうか。ドキュメントにも以下の記載があります。
サポートケースとケース管理の作成 - AWS Support
緊急度の選択
サポートケースを作成する際、常にサポートプランで許容される最大の重大度で作成しがちです。しかし、最も高い重大度は、回避できない場合や運用アプリケーションに直接影響する場合に選択することをお勧めします。
技術的なお問い合わせに関するガイドライン | AWS サポート
適切な緊急度の設定は問題の円滑な解決にとって重要です。
状況確認の結果によっては、サポートエンジニアが緊急度を下げるご協力をお願いする場合があります。
問題解決までに期限がある場合は、ケース起票時に適切な緊急度を指定いただき、サポートケース上で緊急度の背景や期限について補足いただくことがベストプラクティスです。
なぜ、AWS サポートは、適切な緊急度で問い合わせを行うことを推奨しているのでしょうか。
それは「発生中の障害」「発生中の障害（ビジネスへの影響大）」が選択されたケースに対して、AWS サポートがどのような対応方針で調査を行うかといったことに関わってきます。
「発生中の障害」「発生中の障害（ビジネスへの影響大）」について
当サポートでは、お客様からの問い合わせ内容を元に、AWS サポートへ適宜エスカレーションを行います。お客様からの問い合わせ内容の緊急性が高く、ビジネスへの影響が非常に高い場合 AWS サポートへお客様の影響度を鑑みて「発生中の障害」「発生中の障害（ビジネスへの影響大）」で問い合わせを行うことがあります。
その際、適切な情報を提供すると、AWS サポートから、驚くほどに迅速で、そして、的確な回答が来ます。
緊急性の高い問い合わせを受ける際に最も重要視するのは、復旧を優先するか、調査を優先するか、どこから着手するかの判断となります。その判断を行うため、どのような情報を提供すれば良いでしょうか。
的確な情報提供とは
ビジネスへの影響度
最も重要な事項です。
これを正確に捉えるには、緊急事態が発生したことを想定して、事前に影響を把握、定義することが必要です。
例えば、現在提供しているサービスについてアプリケーションの一部に問題し、1 時間サービスが提供できなかったとします。
その際に、どこまでの範囲に問題が波及するかを適切に計測できていますでしょうか。
これが適切に計測できており、緊急時に情報をサポートへ提供できているとベストです。
ビジネスへの影響度の記載は、どの部分から情報提供をすべきか、どの部分を復旧対応するか、サポート側の判断を助ける材料になります。
いつまでに解決したいか
直面している問題について、すぐに解決したいかもしれません。なるべく早く解決したいと書きたくなるかもしれません。
しかし、実際には猶予があるのかもしれません。ビジネスへの影響度を鑑み、許容できる時間を記載できるとベストです。
許容できる時間を記載することで、いつまでにどのような情報を提供することがベストであるか、サポート側の判断を助ける材料になります。
ただし、具体的な期日を記載しても、必ずしもその期日に解決することを約束することが難しい点については、ご了承ください。
具体的にどのような情報を伝えると良いのか
以下のように、具体的な数字を含んだ粒度での情報提供があると、判断の一助になります。
- ビジネスへの影響度の観点
- 10万人の会員が登録しているECサイトを運営しており、1時間サービスが停止するとxxx円の売り上げが減少する。
- 従業員数が100人の工場内で稼働しているシステムであり、1時間ラインが停止すると生産量がxxx減少する。
- 従業員数が10人の経理に関する部署のシステムであり、業務が停止することで、人件費xxx円の損失が発生する。
- 時間の観点
- 毎日夜23時にバッチを実行しているため、そのバッチ実行までに回避策を知りたい
- 12月31日に本稼働をするため、12月28日のテストに間に合わせたい。
- 12月31日の10時に予約販売を開始するため、それまでに復旧したい。
※上記はすべて架空の事例です。
「通常の問い合わせ/機能要望」「障害/開発中の急ぎの問い合わせ」について
ほとんどの場合、こちらの緊急度を選択して問い合わせを行うと思います。では、このふたつの緊急度はどのような場合に選択すると良いでしょうか。
- 通常の問い合わせ/機能要望
- 仕様の確認がしたい
- ドキュメントを読んだがどう解釈していいか分からない
- 要件定義を行う際に、不明な点を質問したい
- サービスを使う中で要件が達成できないため、機能要望がしたい
- 障害/開発中の急ぎの問い合わせ
- 過去に発生した障害について、早めに原因を把握したい
- 障害発生中だが回避策があり、ビジネスへの影響は軽微だが、早めに解決したい
- 要件定義を行っているが、都合上時間の制約がある
- バッチ処理が失敗した原因を知りたいが、次回のバッチ処理までに原因を把握したい
このように、時間の制約があるかどうかが選択基準になりえると考えます。
緊急度を後から変えたい
事象発生時は軽微だと考え、低い緊急度で問い合わせを行ったものの、後から緊急事態となる場合があります。
その場合は、新規ケースを高い緊急度で起票する方法をご検討ください。
AWS へ問い合わせ中のサポートケースですが、状況が変わってしまい早急に回答が必要になりました。何かいい方法はないでしょうか？ | DevelopersIO
まとめ
時は師走。開発や保守に関する、時間に制約のある事象が発生しがちな時期になってきているかもしれません。すべてのことが急ぎのように思えてきます。
しかし、焦って文章を書いてしまうと、ビジネスへの影響度を鑑みた正確な状況を伝えることが難しくなります。
状況を正確に伝えることが、最終的には事象解決の早道になります。
緊急度の選択に迷った際は改めてこの記事を思い出していただき、お問い合わせをいただけますと幸いです。
最後に
テクニカルサポートはお客様の問題解決を力添えする存在であり、敵ではありません。
共に問題を解決するよう、最大限お手伝いいたします。
AWS に関するサポートをご依頼の場合は、クラスメソッドメンバーズ・メンバーズサポートへお気軽にお問い合わせください。
