AWS パートナー企業でテクニカルサポートに従事して 3年経ったので思うところをまとめてみた

2024年11月6日にオンラインで配信された「JAWS-UG初心者支部#62 オンラインLT大会」でお話しした資料です。

実は、同じ文脈で半年前に開催された JAWS-UG 北陸新幹線でもお話ししたのですが、少し初心者の方向けに再構成＋この半年の間で分かったことも含めてアップデートしました。

＜お話の要旨＞
・AWS Support として顧客に望むことはすでに公式文書に書いてある
　・少なくとも AWS に対して問い合わせをするロールの人は、まずは目を通しておくことをおすすめです
　・技術的なお問い合わせに関するガイドライン（ https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines ）
・適切なサービス選択と、困っていることが端的にわかる問い合わせ件名を意識する
・問い合わせ文章は 5W2H を意識する
・担当しているプロジェクトの全容について、簡単なモノで良いので、説明できる資料があればベター
　・複数のアカウントを Transit Gateway などで連携させた、大きいネットワーク空間がある
　・マイクロサービスアーキテクチャで登場人物（サービス）が多い など
・結局、急がば回れ

#jawsug_bgnr

Transcript

1. AWS パートナー企業でテクニカルサポートに従事して 3年経ったので思うところをまとめてみた [JAWS-UG初⼼者⽀部#62 オンラインLT⼤会] 株式会社サーバーワークス 市野 和明（JAWS-UG 神⼾） 2024-11-06
2. ⽬次 1. ⾃⼰紹介 2. 先に結論 3. お伝えしたいこと 4. まとめ
3. ⾃⼰紹介
4. 4 はじめまして 名前︓市野 和明（いちの かずあき） 所属︓株式会社サーバーワークス MS 部 テクニカルサポート１課 好きな AWS サービス︓ AWS CLI （テクサポとして） 嫌いな AWS サービス︓ Amazon FSx for Windows AWS Deadline Cloud 趣味︓ミクが好き、酒を飲む @kazzpapa3
5. 先に結論
6. 6 解決スピードを上げるには︖ Ø AWS Support として顧客に望むことはすでに公式⽂書に書いてある Ø 少なくとも AWS に対して問い合わせをするロールの⼈は、まずは⽬を通しておくことをおすすめ Ø 技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines Ø 適切なサービス選択と、 困っていることが端的にわかる問い合わせ件名を意識する Ø 問い合わせ⽂章は 5W2H を意識する Ø 担当しているプロジェクトの全容について、 簡単なモノで良いので、説明できる資料があればベター Ø 複数のアカウントを Transit Gateway などで連携させた、⼤きいネットワーク空間がある Ø マイクロサービスアーキテクチャで登場⼈物（サービス）が多い など Ø 結局、急がば回れ
7. お伝えしたいこと
8. 8 ありえないだろう…、と思われるが、よくある問い合わせ例 > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。
9. 9 お客様からいただいた⽂⾯そのままではないが… > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。 これは私が夢でみかけた⽂章 ある特定のお客様からいただいた⽂⾯そのままではない
10. 10 100％ 妄想、というわけでもない > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。 ただ、多少誇張した妄想的な⽂⾯ではあるものの 100％ 妄想というわけでもない 本質的な部分では同質なお問い合わせをいただくことは、実は結構ある これは私が夢でみかけた⽂章 ある特定のお客様からいただいた⽂⾯そのままではない
11. あの⽂⾯で（私が、かろうじて）読み取れること
12. 12 AWS の「何か」に繋がらない︖ Ø AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ Ø 「AWS に繋がらない」の部分から
13. 13 過去形で書いてないから「現在も継続中︖」 Ø AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ Ø 「AWS に繋がらない」の部分から Ø すでに収束した事象に対して原因究明をしたい問い合わせではなく、 現在も継続中の事象に対しての問い合わせではないか︖ Ø 今朝から AWS に繋がらない ← 繋がらない時間帯があった。という書き⽅ではない点から推測
14. 14 時間軸は私と⼀緒の⽇本時間かな︖ Ø AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ Ø 「AWS に繋がらない」の部分から Ø すでに収束した事象に対して原因究明をしたい問い合わせではなく、 現在も継続中の事象に対しての問い合わせではないか︖ Ø 今朝から AWS に繋がらない ← 繋がらない時間帯があった。という書き⽅ではない点から推測 Ø ⽇本国内のお客様なので、「今朝」と記載されているのは、 私が思う今朝と同じ頃︖ Ø 7時 〜 9時すぎくらいまでの間あたりとか︖
15. 15 すべて、私の推測… Ø AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ Ø 「AWS に繋がらない」の部分から Ø すでに収束した事象に対して原因究明をしたい問い合わせではなく、 現在も継続中の事象に対しての問い合わせではないか︖ Ø 今朝から AWS に繋がらない ← 繋がらない時間帯があった。という書き⽅ではない点から推測 Ø ⽇本国内のお客様なので、「今朝」と記載されているのは、 私が思う今朝と同じ頃︖ Ø 7時 〜 9時すぎくらいまでの間あたりとか︖ ただしこれらは、あくまで私の推測に過ぎない 聞かないとわからない
16. 16 ツッコミどころは多いが… Ø お客様に確認したいポイントは思いつく限り以下が考えられる Ø 接続できない対象は何︖ Ø AWS マネジメントコンソール︖AWS アカウント内に存在する何かのリソース︖ Ø 接続できないのは誰か︖ Ø 「誰もが接続できない」のか「特定のユーザーだけ」なのか︖ Ø 発⽣時間帯は︖ 今朝というアバウトな時間軸ではなく、明確に何時ごろ、という情報がほしい Ø さらに⾔うなら、⽇本時間ですよね︖という確認はしておきたい Ø 現在も継続中なのか︖収束しているのか︖ Ø 時間軸の話で⾔うなら「今回初めて」なのか「⼀定程度発⽣していた」のか、発⽣頻度の情報もほしい
17. 17 確認したいポイントは多め Ø お客様に確認したいポイントは思いつく限り以下が考えられる Ø 接続できない対象は何︖ Ø AWS マネジメントコンソール︖AWS アカウント内に存在する何かのリソース︖ Ø 接続できないのは誰か︖ Ø 「誰もが接続できない」のか「特定のユーザーだけ」なのか︖ Ø 発⽣時間帯は︖ 今朝というアバウトな時間軸ではなく、明確に何時ごろ、という情報がほしい。 Ø さらに⾔うなら、⽇本時間ですよね︖という確認はしておきたい Ø 現在も継続中なのか︖収束しているのか︖ Ø 時間軸の話で⾔うなら「今回初めて」なのか「⼀定程度発⽣していた」のか、発⽣頻度の情報もほしい 確認したいポイントはいくつもある
18. ところで、AWS サポートにも SLO があります
19. 19 契約中のサポートプランと選択したケースの重要度に応じて… Ø ⽬安となる初回応答時間の設定があります 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
20. 20 契約中のサポートプランと選択したケースの重要度に応じて… Ø ⽬安となる初回応答時間の設定があります Ø ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、 「ベストエフォート」であることには注意が必要 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
21. 21 例えば、エンタープライズプランの場合 ⽬安となる初回応答時間の設定があります ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、 「ベストエフォート」であることにも注意が必要 エンタープライズプランを契約しているお客様で、 「ミッションクリティカルなシステムのダウン」を選択したときには、 おおむね 15分以内には初回の回答をもらえることとなります。 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
22. 22 ただし、SLO の設定は初回応答のみ Ø ⽬安となる初回応答時間の設定があります Ø ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、 「ベストエフォート」であることにも注意が必要 ただし SLO は初回応答のみで、2ターン⽬以降には設定がない 「AWS サポート プラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋
23. ってことは︖
24. AWS サポートの初回ターンを 問い合わせ内容の再確認に費やすのは もったいない
25. 25 先ほどのような問い合わせでは、おそらく初回で解決しない Ø 先ほどの問い合わせ⽂⾯を送信していた場合、 初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確
26. 26 おそらく、初回回答がヒアリングで終わるのではないか︖ Ø 先ほどの問い合わせ⽂⾯を送信していた場合、 初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 Ø 「ツッコミどころは多いが…」のスライドで書いたような ヒアリング事項が初回回答として返ってくることは容易に想像できる
27. 27 待った挙句、ヒアリングだけか… Ø 先ほどの問い合わせ⽂⾯を送信していた場合、 初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 Ø 「ツッコミどころは多いが…」のスライドで書いたような ヒアリング事項が初回回答として返ってくることは容易に想像できる Ø 前述の応答時間を待機して、ようやく得られた返事に ヒアリング項⽬しか書かれていない状況は⼗分考えられる
28. 28 緊急を要するときほど、困るのでは︖ Ø 先ほどの問い合わせ⽂⾯を送信していた場合、 初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 Ø 「ツッコミどころは多いが…」のスライドで書いたような ヒアリング事項が初回回答として返ってくることは容易に想像できる Ø 前述の応答時間を待機して、ようやく得られた返事に ヒアリング項⽬しか書かれていない状況は⼗分考えられる Ø 本番環境にクリティカルな障害が発⽣している場合であれば、 なかなか前に進まない感覚になってしまうかもしれません
29. 29 SLO の待機時間を待った挙句… Ø 先ほどの問い合わせ⽂⾯を送信していた場合、 初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 Ø 「ツッコミどころは多いが…」のスライドで書いたような ヒアリング事項が初回回答として返ってくることは容易に想像できる Ø 前述の応答時間を待機して、ようやく得られた返事に ヒアリング項⽬しか書かれていない状況は⼗分考えられる Ø 本番環境にクリティカルな障害が発⽣している場合であれば、 なかなか前に進まない感覚になってしまうかもしれません （実際に AWS から⾔われるかどうかは別として） ヒアリング事項をまとめて SLO 時間内に初回応答しましたよね︖ あとは順次対応しますね。だと、もったいないですよね。
30. 結局のところ
31. 客観的に理解してもらえるように書く
32. 32 客観的に理解してもらえるように書く Ø 結局のところ、これに尽きるのだと思います。
33. 33 客観的に理解してもらえるように書く Ø 結局のところ、これに尽きるのだと思います Ø 障害や発⽣事象により緊急度や内容も違うが、 問い合わせへの逆質問の発⽣を極⼒減らしてやり取りのターン数を削減すること で、可能な限りスピーディな課題の解決につながると考えています
34. では、どのように伝えようか
35. 35 そもそも、相⼿は誰なのか︖ Ø 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協 業先などではなく、まったくの第三者である点が重要なポイントです
36. 36 そもそも、相⼿は誰なのか︖ Ø 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協 業先などではなく、まったくの第三者である点が重要なポイントです。 Ø 相⼿に対して理解を求めるにあたり、同じ⽂化圏にいない⼈が対象であるという 点で、ハイコンテクストな記述は避けるべきです Ø 社内の⼈間であれば知っているであろうことも伝えないと、 相⼿は知り得ないという点に注意が必要だと考えます
37. 37 そもそも、相⼿は誰なのか︖ Ø 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協 業先などではなく、まったくの第三者である点が重要なポイントです Ø 相⼿に対して理解を求めるにあたり、同じ⽂化圏にいない⼈が対象であるという 点で、ハイコンテクストな記述は避けるべきです Ø 社内の⼈間であれば知っているであろうことも伝えないと、 相⼿は知り得ないという点に注意が必要だと考えます そもそも、何も事情を知らない⼈に伝えるのだから、 本来、それ相応の労⼒がかかるはずです
38. 38 そもそも、相⼿は誰なのか︖ Ø 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協 業先などではなく、まったくの第三者である点が重要なポイントです。 Ø 相⼿に対して理解を求めるにあたり、同じ⽂化圏にいない⼈が対象であるという 点で、ハイコンテクストな記述は避けるべきです。 Ø 社内の⼈間であれば知っているであろうことも伝えないと、 相⼿は知り得ないという点に注意が必要だと考えます。 そもそも、何も事情を知らない⼈に伝えるのだから、 本来、それ相応の労⼒がかかるはずです > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。 雑に投げては、伝わるものも伝わらないはずです
39. 相⼿は何を知り、何を⾒られるのか
40. 40 簡単にですが、 Ø AWS の利⽤者、AWS テクニカルサポート、そして、私が所属している企業の ようなパートナーの三者で、誰が何を知り、何を⾒られるのかを簡単にまとめて みました Ø なお、前提として、弊社のようなリセラーが提供する AWS アカウントでは、 お客様のサポートをリセラーが担うことになっています。 Ø そのため、リセラー内の知⾒や調査による回答が基本となりますが、 AWS 基盤側の問題が疑われるような場合などには、AWS サポートへエスカレーションし、 お客様 ←→ AWS テクニカルサポートの仲介役として⽴ち回る場⾯があります Ø それぞれの⽴場で、⾒られる⾒られない、知っている知り得ないがあり、 それらについてはより意識して伝える必要があると考えられます
41. 41 それぞれがどの情報にアクセスできるか、知りうるか 対象 AWS 利⽤者 （お客様） （私の所属企業のような） APN パートナー企業 AWS テクニカルサポート 設計背景や実装 ◦ 知っている × 知り得ない × 知り得ない 障害や事象の影響度 ◦ 知っている × 知り得ない × 知り得ない AWS マネジメントコン ソール ◦ 閲覧可能 ◦ 閲覧可能 ※⼀部例外あり1 × 閲覧不可能（閲覧しない） AWS で構築されたサーバ 内部のデータやログ ◦ 閲覧可能 × 閲覧不可 （ログインしない） × 閲覧不可 （ログインしない） AWS 物理基盤 × 閲覧不可 × 閲覧不可 ◦ 閲覧可能 1. サービスのポータルや操作画⾯の閲覧のために、IAM Identity Center によるユーザー管理となっているサービスの場合、その発⽣事象の閲覧ができない AWS サービスもある
42. 42 それぞれがどの情報にアクセスできるか、知りうるか 対象 AWS 利⽤者 （お客様） （私の所属企業のような） APN パートナー企業 AWS テクニカルサポート 設計背景や実装 ◦ 知っている × 知り得ない × 知り得ない 障害や事象の影響度 ◦ 知っている × 知り得ない × 知り得ない AWS マネジメントコン ソール ◦ 閲覧可能 ◦ 閲覧可能 ※⼀部例外あり1 × 閲覧不可能（閲覧しない） AWS で構築されたサーバ 内部のデータやログ ◦ 閲覧可能 × 閲覧不可 （ログインしない） × 閲覧不可 （ログインしない） AWS 物理基盤 × 閲覧不可 × 閲覧不可 ◦ 閲覧可能 1. サービスのポータルや操作画⾯の閲覧のために、IAM Identity Center によるユーザー管理となっているサービスの場合、その発⽣事象の閲覧ができない AWS サービスもある
43. 過不⾜のない問い合わせのために
44. 44 考え⽅の⼀例 Ø 「いつなにがどうした」を整理する⽅法としてよく使われている 5W1H の スキームに、もう⼀つ How Much を追加して 5W2H として整理してみました。
45. 45 考え⽅の⼀例 Ø 「いつなにがどうした」を整理する⽅法としてよく使われている 5W1H の スキームに、もう⼀つ How Much を追加して 5W2H として整理してみました。 Ø あくまで、整理⽅法の⼀例ですし、私も書きながら「なにが」と「なにを」、 「なにに」をすべて What に詰め込めなくもないなぁと思ってしまったところ もありましたので、お客様組織内やプロジェクト内でアレンジいただいて良いか と思います。
46. 46 考え⽅の⼀例 Ø 「いつなにがどうした」を整理する⽅法としてよく使われている 5W1H の スキームに、もう⼀つ How Much を追加して 5W2H として整理してみました。 Ø あくまで、整理⽅法の⼀例ですし、私も書きながら「なにが」と「なにを」、 「なにに」をすべて What に詰め込めなくもないなぁと思ってしまったところ もありましたので、お客様組織内やプロジェクト内でアレンジいただいて良いか と思います。 ガチガチに決めておく必要まではないけど、 プロジェクトの担当者ごとで差異が⽣まれないように、とか いざ障害が発⽣したときに、まごまごしなくていいように、 ある程度フォーマット化しておくといいよね、くらいに捉えていただけると幸い です
47. 47 5W2H の例 5W2H ⽬的 問い合わせ時の記載項⽬として考えられる事柄 When ・時間軸、頻度、継続の有無を伝える ・事象を観測できた⽇時 ・タイムゾーン ・観測した事象は１回のみか ・観測した事象は継続中か、収束しているか Where ・事象が発⽣している箇所を伝える ・事象が発⽣している AWS リソースの ID や ARN What ・何をした時に発⽣する（発⽣した） かを伝える ・すでに試してみていることがあれば 合わせて伝える ・＜How＞で伝える発⽣事象に対して、何をした時に発⽣ するのか。 あるいは何をした時には発⽣しないのか。 ・事象の解決を⽬的として、すでにやってみた⾏動はある か。 Who ・事象に関与する⼈物、モノ（操作主 体）の有無や詳細を伝える 上記の＜What＞に対し、関連するヒト・モノがあれば記載 する 例） ・操作主体（呼び出し元）としてのIAM ユーザーやロール ・操作主体（呼び出し元）としての Lambda など他の AWS サービス・リソース
48. 48 5W2H の例 5W2H ⽬的 問い合わせ時の記載項⽬として考えられる事柄 Why ・発⽣事象をなぜ問題視しているかを 伝える ・実装しようとしている背景を伝える ・発⽣している事象において AWS の不具合・不備を疑うに ⾄った理由を伝える ・構築中や検討中などで想定するゴールのイメージに対し て、設計意図を伝える How ・どのような症状かを伝える 発⽣している事象を記載する。 例） ・接続ができない ・操作不能となる ・〇〇という結果となることを想定しているが△△となる How Much ・影響度はどの程度か伝える 事象が発⽣していることの業務への影響（ビジネスインパ クト）を記載する。 定量的な記載であればより客観的に判断が可能になる 例） ・〇〇⼈のユーザーのアクセスを処理することができず、 〇〇円／⽇の損失がある
49. 5W2H それぞれのポイント
50. 50 When Ø 時間軸、頻度、継続の有無を記載いただきたい点はもちろんですが、 AWS ではグローバルサービスということもあり、グリニッジ標準時/GMT（⼀ 部 太平洋標準時/PST）が利⽤されていることもあるため、意識齟齬を⽣まない ためにタイムゾーンを記載いただくとより良いと思います。
51. 51 Where, Who Ø EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、 ⼀意に特定できる値としては適切とは⾔えません。 意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使 ⽤することをお勧めいたします。
52. 52 Where, Who Ø EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、 ⼀意に特定できる値としては適切とは⾔えません。 意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使 ⽤することをお勧めいたします。 Ø また、同様に意識齟齬を回避する⽬的で、お客様固有の俗称や略称の利⽤ （AWS が正式に⾏なっていない略称も含む）も避けることで、スムーズな共通 認識につながると考えます。
53. 53 Where, Who Ø EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、 ⼀意に特定できる値としては適切とは⾔えません。 意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使 ⽤することをお勧めいたします。 Ø また、同様に意識齟齬を回避する⽬的で、お客様固有の俗称や略称の利⽤ （AWS が正式に⾏なっていない略称も含む）も避けることで、スムーズな共通 認識につながると考えます。 Ø また、通信経路や登場⼈物の把握のために構成図などの補⾜資料を共有いただけ ると理解が早まる点もありますので、複雑な構成をとっているような場合や被疑 箇所を明⽰したいような場合に添えていただけると幸いです。
54. 54 Where, Who Ø EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、 ⼀意に特定できる値としては適切とは⾔えません。 意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使 ⽤することをお勧めいたします。 Ø また、同様に意識齟齬を回避する⽬的で、お客様固有の俗称や略称の利⽤ （AWS が正式に⾏なっていない略称も含む）も避けることで、スムーズな共通 認識につながると考えます。 Ø また、通信経路の把握に構成図を共有いただけると理解が早まる点もありますの で、複雑な構成をとっているような場合や被疑箇所を明⽰したいような場合に添 えていただけると幸いです。 余談ですが… SQL Server が関連するお問い合わせで RDS と記載されていた箇所を Amazon Relational Database Service と認識し対応していて、どうも話が⾷い違うな︖ と思ったところ、Windows Server リモートデスクトップサービス（RDS) のこ とだったと判明し、対応⽅針の変更を迫られた場⾯もありました。
55. 55 What, How Ø 事象が発⽣する際の再現⼿順として記載いただくと良いと思います。
56. 56 What, How Ø 事象が発⽣する際の再現⼿順として記載いただくと良いと思います。 Ø AWS では（弊社でも）事象の再現性を確認して お客様固有の問題か否かの判断をしたり、回避⽅法の有無の⽬的で、 実際に検証を⾏う場⾯は多々あります。
57. 57 What, How Ø 事象が発⽣する際の再現⼿順として記載いただくと良いと思います。 Ø AWS では（弊社でも）事象の再現性を確認して お客様固有の問題か否かの判断をしたり、回避⽅法の有無の⽬的で、 実際に検証を⾏う場⾯は多々あります。 Ø 「やってダメだったから意味ないわ」と思わず、 やってみてダメだったことも添えていただけると検証項⽬からの排除ができたり、 別観点を加えてもう⼀度やってみてほしいなどの観点につながり、 結果として迅速な課題解決につながると考えます。
58. 58 Why Ø 予備知識のないテクニカルサポート担当側からは、 AWS マネジメントコンソールで発⽣している事象や設定は、 拝⾒する段階での事実（の集合体）でしかない側⾯があります。
59. 59 Why Ø 予備知識のないテクニカルサポート担当側からは、 AWS マネジメントコンソールで発⽣している事象や設定は、 拝⾒する段階での事実（の集合体）でしかない側⾯があります。 Ø 設計の意図や⽬的（ゴールのイメージ）などの情報をいただいていることで、 現在の実装⽅針では実現できないと判明したことに対して、 代替案のご提⽰をすることが可能になる場合があります。
60. 60 How Much Ø 前述の通り、初回応答時間はベストエフォートであるため、 同時に同程度の緊急度設定のサポートケースが上がってきた際に、 取捨選択が発⽣してしまう可能性はあると考えられます。
61. 61 How Much Ø 前述の通り、初回応答時間はベストエフォートであるため、 同時に同程度の緊急度設定のサポートケースが上がってきた際に、 取捨選択が発⽣してしまう可能性はあると考えられます。 Ø その際に、定量的な記載を⾏うことで、お客様のお困り度合いをより適切に、 かつ、より客観的な判断基準として相⼿に伝えることにつながると考えられます。
62. 62 How Much Ø 前述の通り、初回応答時間はベストエフォートであるため、 同時に同程度の緊急度設定のサポートケースが上がってきた際に、 取捨選択が発⽣してしまう可能性はあると考えられます。 Ø その際に、定量的な記載を⾏うことで、お客様のお困り度合いをより適切に、 かつ、より客観的な判断基準として相⼿に伝えることにつながると考えられます。 Ø 「このシステムが停⽌していることで〇千万円／⽇の機会損失となる。」 みたいな具体的な記載です。
63. 63 テンプレート化の⼀例 AWS サポート ご担当者様 いつもお世話になっております。〇〇と申します。 〇〇について確認させてください。 （〇〇で△△という事象が発⽣しています。） ・発⽣した⽇時・タイムゾーン、発⽣頻度、事象の継続性 ・環境について(リソースID等含む) ・事象を観測した経緯、発⽣までの⼿順 ・既に調査したこと、およびその結果 ・なぜこの設計となっているか （なぜ本問い合わせ⽬的を達成したいのか） ・緊急度、業務への影響度について（定量的に書く） --- 以上、よろしくお願いいたします。
64. AWS ではケースを担当するまで 内容がわからない、らしい
65. 65 ここ最近で聞いた話ではないので、今は違うかもしれませんが AWS テクニカルサポートでは、 ディスパッチャがいて、適宜サポートケースをアサインするのではなく ⾃分の担当サービスのケースの⼀覧を⾒て、 担当する（したい）ケースを⾃らが取っていく⽅式、と聞いたことがあります
66. 66 その際に、問い合わせ本⽂まで⾒られるわけではなさそう AWS テクニカルサポートでは、「データベース」などサポートエンジニア⾃⾝ の担当領域があると聞いたことがあります そのため、⾃⾝の担当領域に含まれるケースの⼀覧の中から 緊急度と件名を⾒て、担当する（したい）ケースを取って対応に⼊っていくそう です
67. 67 本⽂以外にも気にする必要がある点がありそう 先ほどまでは本⽂中の 5W2H の話をしていましたが… 実はケースのタイトル（件名）と、正しいサービスの選択をする必要があると 考えられます
68. 68 サービスの選択画⾯ Ø 適切でないサービスやカテゴリーを選択しない Ø 選択したサービスやカテゴリーではない 問い合わせを本⽂に混在させない
69. 69 サービスの選択画⾯ Ø 適切でないサービスやカテゴリーを選択しない Ø 選択したサービスやカテゴリーではない 問い合わせを本⽂に混在させない
70. 70 ケースの件名 Ø ケースを担当するかどうかの判断時点では、 選択されたサービス、緊急度と件名しか⾒られ ないのであれば、より具体的な記載をしておく ⽅が、専⾨性の⾼いサポートエンジニアに拾っ てもらえるかもしれない… Ø ❌ 件名︓AWS に今朝からつながりません Ø ⭕ 件名︓EC2 インスタンスで構築した Linux サーバに ⽇本時間 9:00 頃より SSH 接続ができない事象について
71. まとめ
72. 72 解決スピードを上げるには︖ Ø AWS Support として顧客に望むことはすでに公式⽂書に書いてある Ø 少なくとも AWS に対して問い合わせをするロールの⼈は、まずは⽬を通しておくことをおすすめ Ø 技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines Ø 適切なサービス選択と、 困っていることが端的にわかる問い合わせ件名を意識する Ø 問い合わせ⽂章は 5W2H を意識する Ø 担当しているプロジェクトの全容について、 簡単なモノで良いので、説明できる資料があればベター Ø 複数のアカウントを Transit Gateway などで連携させた、⼤きいネットワーク空間がある Ø マイクロサービスアーキテクチャで登場⼈物（サービス）が多い など Ø 結局、急がば回れ
73. 余談
74. 74 回答・サポートに対する評価 AWS のサポートケースは、進⾏中の問い合わせであっても、 回答⽂⼀つ⼀つに５段階の評価をつけることが可能です。 サポートエンジニアに対するフィードバックとなるようで、可能な限り⼊⼒して あげると良いようなのですが、⽇本⼈的感覚で「普通＝★ ★ ★ ☆ ☆ 」ってつ けると、⽂化の違いで、割と低めの評価を与えていることになるっぽいです。 なので過不⾜なかったよ、なのであれば星５としてあげたほうが良いようです。
75. 75 回答・サポートに対する評価 AWS のサポートケースは、進⾏中の問い合わせであっても、 回答⽂⼀つ⼀つに５段階の評価をつけることが可能です。 サポートエンジニアに対するフィードバックとなるようで、可能な限り⼊⼒して あげると良いようなのですが、⽇本⼈的感覚で「普通＝★ ★ ★ ☆ ☆ 」ってつ けると、⽂化の違いで、割と低めの評価を与えていることになるっぽいです。 なので過不⾜なかったよ、なのであれば星５としてあげたほうが良いようです。