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

by kazzpapa3

Slide 1

Slide 1 text

AWS パートナー企業でテクニカルサポートに従事して 2年経ったので思うところをまとめてみた [JAWS-UG北陸新幹線] 株式会社サーバーワークス市野和明（JAWS-UG 関⻄） 2024-04-06

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

⾃⼰紹介

Slide 4

Slide 4 text

4 あらためまして名前︓市野和明（いちのかずあき）所属︓株式会社サーバーワークスマネージドサクセス部テクニカルサポート課好きな AWS サービス︓ AWS CLI （テクサポとして）嫌いな AWS サービス︓ Amazon FSx for Windows 趣味︓⾳楽鑑賞、酒を飲む @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 を意識する担当しているプロジェクトの全容について、ペライチで良いので、簡単に説明できる資料があればベター結局、急がば回れ

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

Slide 11

Slide 11 text

11 あの⽂⾯で（私が、かろうじて）読み取れること • AWS マネジメントコンソール⾃体か、 AWS で作成した何らかのリソースに対して接続できない状態が発⽣している︖ • 「AWS に繋がらない」の部分から

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

ってことは︖

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

24 SLA の待機時間を待った挙句… 先ほどの問い合わせ⽂⾯を送信していた場合、初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

27 SLA の待機時間を待った挙句… 先ほどの問い合わせ⽂⾯を送信していた場合、初回回答では⼀発で課題解決する回答を得られないであろうことは、ほぼ明確「ツッコミどころは多いが…」のスライドで書いたようなヒアリング事項が初回回答として返ってくることは容易に想像できる前述の応答時間を待機して、ようやく得られた返事にヒアリング項⽬しか書かれていない状況は寂しいものがありますよね。本番環境にクリティカルな障害が発⽣している場合であれば、虚無感と落胆は相当のものだと思います。

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

結局のところ

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

39 簡単にですが、 AWS の利⽤者、AWS テクニカルサポート、そして、私が所属している企業のようなパートナーの三者で、誰が何を知り、何を⾒られるのかを簡単にまとめてみました。それぞれの⽴場で、⾒られる⾒られない、知っている知り得ないがあり、それらについてはより意識して伝える必要があると考えられます。

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

5W2H それぞれのポイント

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

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 が正式に⾏なっていない略称も含む）も避けることで、スムーズな共通認識につながると考えます。また、通信経路の把握に構成図を共有いただけると理解が早まる点もありますので、複雑な構成をとっているような場合や被疑箇所を明⽰したいような場合に添えていただけると幸いです。余談ですが… SQL Server が関連するお問い合わせで RDS と記載されていた箇所を Amazon Relational Database Service と認識し対応していて、どうも話が⾷い違うな︖ と思ったところ、Windows Server リモートデスクトップサービス（RDS) のことだったと判明し、対応⽅針の変更を迫られた場⾯もありました。

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

まとめ

Slide 64

Slide 64 text

64 解決スピードを上げるには︖ AWS Support として顧客に望むことはすでに公式⽂書に書いてある少なくとも AWS に対して問い合わせをするロールの⼈は、まずは⽬を通しておくべき技術的なお問い合わせに関するガイドライン https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines 問い合わせ⽂章は 5W2H を意識する担当しているプロジェクトの全容について、ペライチで良いので、簡単に説明できる資料があればベター結局、急がば回れ

Slide 65

Slide 65 text

余談

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

No content