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

Slide 1

Slide 1 text

AWS パートナー企業でテクニカルサポートに従事して 3年経ったので思うところをまとめてみた [JAWS-UG初⼼者⽀部#62 オンラインLT⼤会] 株式会社サーバーワークス市野和明（JAWS-UG 神⼾） 2024-11-06

Slide 2

Slide 2 text

⽬次 1. ⾃⼰紹介 2. 先に結論 3. お伝えしたいこと 4. まとめ

Slide 3

Slide 3 text

⾃⼰紹介

Slide 4

Slide 4 text

4 はじめまして名前︓市野和明（いちのかずあき）所属︓株式会社サーバーワークス MS 部テクニカルサポート１課好きな AWS サービス︓ AWS CLI （テクサポとして）嫌いな AWS サービス︓ Amazon FSx for Windows AWS Deadline Cloud 趣味︓ミクが好き、酒を飲む @kazzpapa3

Slide 5

Slide 5 text

先に結論

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

お伝えしたいこと

Slide 8

Slide 8 text

8 ありえないだろう…、と思われるが、よくある問い合わせ例 > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。

Slide 9

Slide 9 text

9 お客様からいただいた⽂⾯そのままではないが… > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。これは私が夢でみかけた⽂章ある特定のお客様からいただいた⽂⾯そのままではない

Slide 10

Slide 10 text

10 100％妄想、というわけでもない > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。ただ、多少誇張した妄想的な⽂⾯ではあるものの 100％妄想というわけでもない本質的な部分では同質なお問い合わせをいただくことは、実は結構あるこれは私が夢でみかけた⽂章ある特定のお客様からいただいた⽂⾯そのままではない

Slide 11

Slide 11 text

あの⽂⾯で（私が、かろうじて）読み取れること

Slide 12

Slide 12 text

12 AWS の「何か」に繋がらない︖ Ø AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ Ø 「AWS に繋がらない」の部分から

Slide 13

Slide 13 text

13 過去形で書いてないから「現在も継続中︖」 Ø AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ Ø 「AWS に繋がらない」の部分から Ø すでに収束した事象に対して原因究明をしたい問い合わせではなく、現在も継続中の事象に対しての問い合わせではないか︖ Ø 今朝から AWS に繋がらない ← 繋がらない時間帯があった。という書き⽅ではない点から推測

Slide 14

Slide 14 text

14 時間軸は私と⼀緒の⽇本時間かな︖ Ø AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ Ø 「AWS に繋がらない」の部分から Ø すでに収束した事象に対して原因究明をしたい問い合わせではなく、現在も継続中の事象に対しての問い合わせではないか︖ Ø 今朝から AWS に繋がらない ← 繋がらない時間帯があった。という書き⽅ではない点から推測 Ø ⽇本国内のお客様なので、「今朝」と記載されているのは、私が思う今朝と同じ頃︖ Ø 7時〜 9時すぎくらいまでの間あたりとか︖

Slide 15

Slide 15 text

15 すべて、私の推測… Ø AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ Ø 「AWS に繋がらない」の部分から Ø すでに収束した事象に対して原因究明をしたい問い合わせではなく、現在も継続中の事象に対しての問い合わせではないか︖ Ø 今朝から AWS に繋がらない ← 繋がらない時間帯があった。という書き⽅ではない点から推測 Ø ⽇本国内のお客様なので、「今朝」と記載されているのは、私が思う今朝と同じ頃︖ Ø 7時〜 9時すぎくらいまでの間あたりとか︖ ただしこれらは、あくまで私の推測に過ぎない聞かないとわからない

Slide 16

Slide 16 text

16 ツッコミどころは多いが… Ø お客様に確認したいポイントは思いつく限り以下が考えられる Ø 接続できない対象は何︖ Ø AWS マネジメントコンソール︖AWS アカウント内に存在する何かのリソース︖ Ø 接続できないのは誰か︖ Ø 「誰もが接続できない」のか「特定のユーザーだけ」なのか︖ Ø 発⽣時間帯は︖ 今朝というアバウトな時間軸ではなく、明確に何時ごろ、という情報がほしい Ø さらに⾔うなら、⽇本時間ですよね︖という確認はしておきたい Ø 現在も継続中なのか︖収束しているのか︖ Ø 時間軸の話で⾔うなら「今回初めて」なのか「⼀定程度発⽣していた」のか、発⽣頻度の情報もほしい

Slide 17

Slide 17 text

17 確認したいポイントは多め Ø お客様に確認したいポイントは思いつく限り以下が考えられる Ø 接続できない対象は何︖ Ø AWS マネジメントコンソール︖AWS アカウント内に存在する何かのリソース︖ Ø 接続できないのは誰か︖ Ø 「誰もが接続できない」のか「特定のユーザーだけ」なのか︖ Ø 発⽣時間帯は︖ 今朝というアバウトな時間軸ではなく、明確に何時ごろ、という情報がほしい。 Ø さらに⾔うなら、⽇本時間ですよね︖という確認はしておきたい Ø 現在も継続中なのか︖収束しているのか︖ Ø 時間軸の話で⾔うなら「今回初めて」なのか「⼀定程度発⽣していた」のか、発⽣頻度の情報もほしい確認したいポイントはいくつもある

Slide 18

Slide 18 text

ところで、AWS サポートにも SLO があります

Slide 19

Slide 19 text

19 契約中のサポートプランと選択したケースの重要度に応じて… Ø ⽬安となる初回応答時間の設定があります「AWS サポートプラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋

Slide 20

Slide 20 text

20 契約中のサポートプランと選択したケースの重要度に応じて… Ø ⽬安となる初回応答時間の設定があります Ø ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、「ベストエフォート」であることには注意が必要「AWS サポートプラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋

Slide 21

Slide 21 text

21 例えば、エンタープライズプランの場合⽬安となる初回応答時間の設定がありますただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、「ベストエフォート」であることにも注意が必要エンタープライズプランを契約しているお客様で、「ミッションクリティカルなシステムのダウン」を選択したときには、おおむね 15分以内には初回の回答をもらえることとなります。「AWS サポートプラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋

Slide 22

Slide 22 text

22 ただし、SLO の設定は初回応答のみ Ø ⽬安となる初回応答時間の設定があります Ø ただし、「合理的な範囲でできる限りの努⼒を」と記載のある通り、「ベストエフォート」であることにも注意が必要ただし SLO は初回応答のみで、2ターン⽬以降には設定がない「AWS サポートプラン⽐較」（ https://aws.amazon.com/jp/premiumsupport/plans/ ）より抜粋

Slide 23

Slide 23 text

ってことは︖

Slide 24

Slide 24 text

AWS サポートの初回ターンを問い合わせ内容の再確認に費やすのはもったいない

Slide 25

Slide 25 text

25 先ほどのような問い合わせでは、おそらく初回で解決しない Ø 先ほどの問い合わせ⽂⾯を送信していた場合、初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確

Slide 26

Slide 26 text

26 おそらく、初回回答がヒアリングで終わるのではないか︖ Ø 先ほどの問い合わせ⽂⾯を送信していた場合、初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 Ø 「ツッコミどころは多いが…」のスライドで書いたようなヒアリング事項が初回回答として返ってくることは容易に想像できる

Slide 27

Slide 27 text

27 待った挙句、ヒアリングだけか… Ø 先ほどの問い合わせ⽂⾯を送信していた場合、初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 Ø 「ツッコミどころは多いが…」のスライドで書いたようなヒアリング事項が初回回答として返ってくることは容易に想像できる Ø 前述の応答時間を待機して、ようやく得られた返事にヒアリング項⽬しか書かれていない状況は⼗分考えられる

Slide 28

Slide 28 text

28 緊急を要するときほど、困るのでは︖ Ø 先ほどの問い合わせ⽂⾯を送信していた場合、初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 Ø 「ツッコミどころは多いが…」のスライドで書いたようなヒアリング事項が初回回答として返ってくることは容易に想像できる Ø 前述の応答時間を待機して、ようやく得られた返事にヒアリング項⽬しか書かれていない状況は⼗分考えられる Ø 本番環境にクリティカルな障害が発⽣している場合であれば、なかなか前に進まない感覚になってしまうかもしれません

Slide 29

Slide 29 text

29 SLO の待機時間を待った挙句… Ø 先ほどの問い合わせ⽂⾯を送信していた場合、初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確 Ø 「ツッコミどころは多いが…」のスライドで書いたようなヒアリング事項が初回回答として返ってくることは容易に想像できる Ø 前述の応答時間を待機して、ようやく得られた返事にヒアリング項⽬しか書かれていない状況は⼗分考えられる Ø 本番環境にクリティカルな障害が発⽣している場合であれば、なかなか前に進まない感覚になってしまうかもしれません（実際に AWS から⾔われるかどうかは別として）ヒアリング事項をまとめて SLO 時間内に初回応答しましたよね︖ あとは順次対応しますね。だと、もったいないですよね。

Slide 30

Slide 30 text

結局のところ

Slide 31

Slide 31 text

客観的に理解してもらえるように書く

Slide 32

Slide 32 text

32 客観的に理解してもらえるように書く Ø 結局のところ、これに尽きるのだと思います。

Slide 33

Slide 33 text

33 客観的に理解してもらえるように書く Ø 結局のところ、これに尽きるのだと思います Ø 障害や発⽣事象により緊急度や内容も違うが、問い合わせへの逆質問の発⽣を極⼒減らしてやり取りのターン数を削減することで、可能な限りスピーディな課題の解決につながると考えています

Slide 34

Slide 34 text

では、どのように伝えようか

Slide 35

Slide 35 text

35 そもそも、相⼿は誰なのか︖ Ø 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協業先などではなく、まったくの第三者である点が重要なポイントです

Slide 36

Slide 36 text

36 そもそも、相⼿は誰なのか︖ Ø 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協業先などではなく、まったくの第三者である点が重要なポイントです。 Ø 相⼿に対して理解を求めるにあたり、同じ⽂化圏にいない⼈が対象であるという点で、ハイコンテクストな記述は避けるべきです Ø 社内の⼈間であれば知っているであろうことも伝えないと、相⼿は知り得ないという点に注意が必要だと考えます

Slide 37

Slide 37 text

37 そもそも、相⼿は誰なのか︖ Ø 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協業先などではなく、まったくの第三者である点が重要なポイントです Ø 相⼿に対して理解を求めるにあたり、同じ⽂化圏にいない⼈が対象であるという点で、ハイコンテクストな記述は避けるべきです Ø 社内の⼈間であれば知っているであろうことも伝えないと、相⼿は知り得ないという点に注意が必要だと考えますそもそも、何も事情を知らない⼈に伝えるのだから、本来、それ相応の労⼒がかかるはずです

Slide 38

Slide 38 text

38 そもそも、相⼿は誰なのか︖ Ø 問い合わせを送る相⼿は、会社の中で隣にいる同僚や上司、あるいは取引先や協業先などではなく、まったくの第三者である点が重要なポイントです。 Ø 相⼿に対して理解を求めるにあたり、同じ⽂化圏にいない⼈が対象であるという点で、ハイコンテクストな記述は避けるべきです。 Ø 社内の⼈間であれば知っているであろうことも伝えないと、相⼿は知り得ないという点に注意が必要だと考えます。そもそも、何も事情を知らない⼈に伝えるのだから、本来、それ相応の労⼒がかかるはずです > 今朝から AWS につながりません。 > 障害など起きていないでしょうか。雑に投げては、伝わるものも伝わらないはずです

Slide 39

Slide 39 text

相⼿は何を知り、何を⾒られるのか

Slide 40

Slide 40 text

40 簡単にですが、 Ø AWS の利⽤者、AWS テクニカルサポート、そして、私が所属している企業のようなパートナーの三者で、誰が何を知り、何を⾒られるのかを簡単にまとめてみました Ø なお、前提として、弊社のようなリセラーが提供する AWS アカウントでは、お客様のサポートをリセラーが担うことになっています。 Ø そのため、リセラー内の知⾒や調査による回答が基本となりますが、 AWS 基盤側の問題が疑われるような場合などには、AWS サポートへエスカレーションし、お客様 ←→ AWS テクニカルサポートの仲介役として⽴ち回る場⾯があります Ø それぞれの⽴場で、⾒られる⾒られない、知っている知り得ないがあり、それらについてはより意識して伝える必要があると考えられます

Slide 41

Slide 41 text

41 それぞれがどの情報にアクセスできるか、知りうるか対象 AWS 利⽤者（お客様）（私の所属企業のような） APN パートナー企業 AWS テクニカルサポート設計背景や実装 ○ 知っている × 知り得ない × 知り得ない障害や事象の影響度 ○ 知っている × 知り得ない × 知り得ない AWS マネジメントコンソール ○ 閲覧可能 ○ 閲覧可能 ※⼀部例外あり1 × 閲覧不可能（閲覧しない） AWS で構築されたサーバ内部のデータやログ ○ 閲覧可能 × 閲覧不可（ログインしない） × 閲覧不可（ログインしない） AWS 物理基盤 × 閲覧不可 × 閲覧不可 ○ 閲覧可能 1. サービスのポータルや操作画⾯の閲覧のために、IAM Identity Center によるユーザー管理となっているサービスの場合、その発⽣事象の閲覧ができない AWS サービスもある

Slide 42

Slide 42 text

42 それぞれがどの情報にアクセスできるか、知りうるか対象 AWS 利⽤者（お客様）（私の所属企業のような） APN パートナー企業 AWS テクニカルサポート設計背景や実装 ○ 知っている × 知り得ない × 知り得ない障害や事象の影響度 ○ 知っている × 知り得ない × 知り得ない AWS マネジメントコンソール ○ 閲覧可能 ○ 閲覧可能 ※⼀部例外あり1 × 閲覧不可能（閲覧しない） AWS で構築されたサーバ内部のデータやログ ○ 閲覧可能 × 閲覧不可（ログインしない） × 閲覧不可（ログインしない） AWS 物理基盤 × 閲覧不可 × 閲覧不可 ○ 閲覧可能 1. サービスのポータルや操作画⾯の閲覧のために、IAM Identity Center によるユーザー管理となっているサービスの場合、その発⽣事象の閲覧ができない AWS サービスもある

Slide 43

Slide 43 text

過不⾜のない問い合わせのために

Slide 44

Slide 44 text

44 考え⽅の⼀例 Ø 「いつなにがどうした」を整理する⽅法としてよく使われている 5W1H のスキームに、もう⼀つ How Much を追加して 5W2H として整理してみました。

Slide 45

Slide 45 text

45 考え⽅の⼀例 Ø 「いつなにがどうした」を整理する⽅法としてよく使われている 5W1H のスキームに、もう⼀つ How Much を追加して 5W2H として整理してみました。 Ø あくまで、整理⽅法の⼀例ですし、私も書きながら「なにが」と「なにを」、「なにに」をすべて What に詰め込めなくもないなぁと思ってしまったところもありましたので、お客様組織内やプロジェクト内でアレンジいただいて良いかと思います。

Slide 46

Slide 46 text

46 考え⽅の⼀例 Ø 「いつなにがどうした」を整理する⽅法としてよく使われている 5W1H のスキームに、もう⼀つ How Much を追加して 5W2H として整理してみました。 Ø あくまで、整理⽅法の⼀例ですし、私も書きながら「なにが」と「なにを」、「なにに」をすべて What に詰め込めなくもないなぁと思ってしまったところもありましたので、お客様組織内やプロジェクト内でアレンジいただいて良いかと思います。ガチガチに決めておく必要まではないけど、プロジェクトの担当者ごとで差異が⽣まれないように、とかいざ障害が発⽣したときに、まごまごしなくていいように、ある程度フォーマット化しておくといいよね、くらいに捉えていただけると幸いです

Slide 47

Slide 47 text

47 5W2H の例 5W2H ⽬的問い合わせ時の記載項⽬として考えられる事柄 When ・時間軸、頻度、継続の有無を伝える・事象を観測できた⽇時・タイムゾーン・観測した事象は１回のみか・観測した事象は継続中か、収束しているか Where ・事象が発⽣している箇所を伝える・事象が発⽣している AWS リソースの ID や ARN What ・何をした時に発⽣する（発⽣した）かを伝える・すでに試してみていることがあれば合わせて伝える・＜How＞で伝える発⽣事象に対して、何をした時に発⽣するのか。あるいは何をした時には発⽣しないのか。・事象の解決を⽬的として、すでにやってみた⾏動はあるか。 Who ・事象に関与する⼈物、モノ（操作主体）の有無や詳細を伝える上記の＜What＞に対し、関連するヒト・モノがあれば記載する例）・操作主体（呼び出し元）としてのIAM ユーザーやロール・操作主体（呼び出し元）としての Lambda など他の AWS サービス・リソース

Slide 48

Slide 48 text

48 5W2H の例 5W2H ⽬的問い合わせ時の記載項⽬として考えられる事柄 Why ・発⽣事象をなぜ問題視しているかを伝える・実装しようとしている背景を伝える・発⽣している事象において AWS の不具合・不備を疑うに⾄った理由を伝える・構築中や検討中などで想定するゴールのイメージに対して、設計意図を伝える How ・どのような症状かを伝える発⽣している事象を記載する。例）・接続ができない・操作不能となる・〇〇という結果となることを想定しているが△△となる How Much ・影響度はどの程度か伝える事象が発⽣していることの業務への影響（ビジネスインパクト）を記載する。定量的な記載であればより客観的に判断が可能になる例）・〇〇⼈のユーザーのアクセスを処理することができず、〇〇円／⽇の損失がある

Slide 49

Slide 49 text

5W2H それぞれのポイント

Slide 50

Slide 50 text

50 When Ø 時間軸、頻度、継続の有無を記載いただきたい点はもちろんですが、 AWS ではグローバルサービスということもあり、グリニッジ標準時/GMT（⼀部太平洋標準時/PST）が利⽤されていることもあるため、意識齟齬を⽣まないためにタイムゾーンを記載いただくとより良いと思います。

Slide 51

Slide 51 text

51 Where, Who Ø EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、⼀意に特定できる値としては適切とは⾔えません。意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使⽤することをお勧めいたします。

Slide 52

Slide 52 text

52 Where, Who Ø EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、⼀意に特定できる値としては適切とは⾔えません。意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使⽤することをお勧めいたします。 Ø また、同様に意識齟齬を回避する⽬的で、お客様固有の俗称や略称の利⽤（AWS が正式に⾏なっていない略称も含む）も避けることで、スムーズな共通認識につながると考えます。

Slide 53

Slide 53 text

53 Where, Who Ø EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、⼀意に特定できる値としては適切とは⾔えません。意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使⽤することをお勧めいたします。 Ø また、同様に意識齟齬を回避する⽬的で、お客様固有の俗称や略称の利⽤（AWS が正式に⾏なっていない略称も含む）も避けることで、スムーズな共通認識につながると考えます。 Ø また、通信経路や登場⼈物の把握のために構成図などの補⾜資料を共有いただけると理解が早まる点もありますので、複雑な構成をとっているような場合や被疑箇所を明⽰したいような場合に添えていただけると幸いです。

Slide 54

Slide 54 text

54 Where, Who Ø EC2 インスタンスの Name タグなど、タグの値は、同⼀の値を許容しうるため、⼀意に特定できる値としては適切とは⾔えません。意識齟齬を⽣まないために、インスタンス ID や ARN など、⼀意となる値を使⽤することをお勧めいたします。 Ø また、同様に意識齟齬を回避する⽬的で、お客様固有の俗称や略称の利⽤（AWS が正式に⾏なっていない略称も含む）も避けることで、スムーズな共通認識につながると考えます。 Ø また、通信経路の把握に構成図を共有いただけると理解が早まる点もありますので、複雑な構成をとっているような場合や被疑箇所を明⽰したいような場合に添えていただけると幸いです。余談ですが… SQL Server が関連するお問い合わせで RDS と記載されていた箇所を Amazon Relational Database Service と認識し対応していて、どうも話が⾷い違うな︖ と思ったところ、Windows Server リモートデスクトップサービス（RDS) のことだったと判明し、対応⽅針の変更を迫られた場⾯もありました。

Slide 55

Slide 55 text

55 What, How Ø 事象が発⽣する際の再現⼿順として記載いただくと良いと思います。

Slide 56

Slide 56 text

56 What, How Ø 事象が発⽣する際の再現⼿順として記載いただくと良いと思います。 Ø AWS では（弊社でも）事象の再現性を確認してお客様固有の問題か否かの判断をしたり、回避⽅法の有無の⽬的で、実際に検証を⾏う場⾯は多々あります。

Slide 57

Slide 57 text

57 What, How Ø 事象が発⽣する際の再現⼿順として記載いただくと良いと思います。 Ø AWS では（弊社でも）事象の再現性を確認してお客様固有の問題か否かの判断をしたり、回避⽅法の有無の⽬的で、実際に検証を⾏う場⾯は多々あります。 Ø 「やってダメだったから意味ないわ」と思わず、やってみてダメだったことも添えていただけると検証項⽬からの排除ができたり、別観点を加えてもう⼀度やってみてほしいなどの観点につながり、結果として迅速な課題解決につながると考えます。

Slide 58

Slide 58 text

58 Why Ø 予備知識のないテクニカルサポート担当側からは、 AWS マネジメントコンソールで発⽣している事象や設定は、拝⾒する段階での事実（の集合体）でしかない側⾯があります。

Slide 59

Slide 59 text

59 Why Ø 予備知識のないテクニカルサポート担当側からは、 AWS マネジメントコンソールで発⽣している事象や設定は、拝⾒する段階での事実（の集合体）でしかない側⾯があります。 Ø 設計の意図や⽬的（ゴールのイメージ）などの情報をいただいていることで、現在の実装⽅針では実現できないと判明したことに対して、代替案のご提⽰をすることが可能になる場合があります。

Slide 60

Slide 60 text

60 How Much Ø 前述の通り、初回応答時間はベストエフォートであるため、同時に同程度の緊急度設定のサポートケースが上がってきた際に、取捨選択が発⽣してしまう可能性はあると考えられます。

Slide 61

Slide 61 text

61 How Much Ø 前述の通り、初回応答時間はベストエフォートであるため、同時に同程度の緊急度設定のサポートケースが上がってきた際に、取捨選択が発⽣してしまう可能性はあると考えられます。 Ø その際に、定量的な記載を⾏うことで、お客様のお困り度合いをより適切に、かつ、より客観的な判断基準として相⼿に伝えることにつながると考えられます。

Slide 62

Slide 62 text

62 How Much Ø 前述の通り、初回応答時間はベストエフォートであるため、同時に同程度の緊急度設定のサポートケースが上がってきた際に、取捨選択が発⽣してしまう可能性はあると考えられます。 Ø その際に、定量的な記載を⾏うことで、お客様のお困り度合いをより適切に、かつ、より客観的な判断基準として相⼿に伝えることにつながると考えられます。 Ø 「このシステムが停⽌していることで〇千万円／⽇の機会損失となる。」みたいな具体的な記載です。

Slide 63

Slide 63 text

63 テンプレート化の⼀例 AWS サポートご担当者様いつもお世話になっております。〇〇と申します。〇〇について確認させてください。（〇〇で△△という事象が発⽣しています。）・発⽣した⽇時・タイムゾーン、発⽣頻度、事象の継続性・環境について(リソースID等含む) ・事象を観測した経緯、発⽣までの⼿順・既に調査したこと、およびその結果・なぜこの設計となっているか（なぜ本問い合わせ⽬的を達成したいのか）・緊急度、業務への影響度について（定量的に書く） --- 以上、よろしくお願いいたします。

Slide 64

Slide 64 text

AWS ではケースを担当するまで内容がわからない、らしい

Slide 65

Slide 65 text

65 ここ最近で聞いた話ではないので、今は違うかもしれませんが AWS テクニカルサポートでは、ディスパッチャがいて、適宜サポートケースをアサインするのではなく⾃分の担当サービスのケースの⼀覧を⾒て、担当する（したい）ケースを⾃らが取っていく⽅式、と聞いたことがあります

Slide 66

Slide 66 text

66 その際に、問い合わせ本⽂まで⾒られるわけではなさそう AWS テクニカルサポートでは、「データベース」などサポートエンジニア⾃⾝の担当領域があると聞いたことがありますそのため、⾃⾝の担当領域に含まれるケースの⼀覧の中から緊急度と件名を⾒て、担当する（したい）ケースを取って対応に⼊っていくそうです

Slide 67

Slide 67 text

67 本⽂以外にも気にする必要がある点がありそう先ほどまでは本⽂中の 5W2H の話をしていましたが… 実はケースのタイトル（件名）と、正しいサービスの選択をする必要があると考えられます

Slide 68

Slide 68 text

68 サービスの選択画⾯ Ø 適切でないサービスやカテゴリーを選択しない Ø 選択したサービスやカテゴリーではない問い合わせを本⽂に混在させない

Slide 69

Slide 69 text

69 サービスの選択画⾯ Ø 適切でないサービスやカテゴリーを選択しない Ø 選択したサービスやカテゴリーではない問い合わせを本⽂に混在させない

Slide 70

Slide 70 text

70 ケースの件名 Ø ケースを担当するかどうかの判断時点では、選択されたサービス、緊急度と件名しか⾒られないのであれば、より具体的な記載をしておく⽅が、専⾨性の⾼いサポートエンジニアに拾ってもらえるかもしれない… Ø ❌ 件名︓AWS に今朝からつながりません Ø ⭕ 件名︓EC2 インスタンスで構築した Linux サーバに⽇本時間 9:00 頃より SSH 接続ができない事象について

Slide 71

Slide 71 text

まとめ

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

余談

Slide 74

Slide 74 text

74 回答・サポートに対する評価 AWS のサポートケースは、進⾏中の問い合わせであっても、回答⽂⼀つ⼀つに５段階の評価をつけることが可能です。サポートエンジニアに対するフィードバックとなるようで、可能な限り⼊⼒してあげると良いようなのですが、⽇本⼈的感覚で「普通＝★ ★ ★ ☆ ☆ 」ってつけると、⽂化の違いで、割と低めの評価を与えていることになるっぽいです。なので過不⾜なかったよ、なのであれば星５としてあげたほうが良いようです。

Slide 75

Slide 75 text

75 回答・サポートに対する評価 AWS のサポートケースは、進⾏中の問い合わせであっても、回答⽂⼀つ⼀つに５段階の評価をつけることが可能です。サポートエンジニアに対するフィードバックとなるようで、可能な限り⼊⼒してあげると良いようなのですが、⽇本⼈的感覚で「普通＝★ ★ ★ ☆ ☆ 」ってつけると、⽂化の違いで、割と低めの評価を与えていることになるっぽいです。なので過不⾜なかったよ、なのであれば星５としてあげたほうが良いようです。

Slide 76

Slide 76 text

No content