はじめに
Qiita への投稿は、はじめまして！ですが、AWS 再販パートナー企業でテクニカルサポート部門に従事している kazzpapa3 と申します。
現職について2年が経過し、さまざまなお客様からの問い合わせを受け付けている中で、問い合わせを行う際に必要な事項や、もう少しこうだったらより良いのに…と思ったことの雑記です。
所属企業でアドベントカレンダーを実施していて、会社のブログで書いてもよかったのですが、すでに同僚が良記事を書いてくれているのと、少しポエムっぽくなりそうだったので Qiita での公開としました。
職務柄 AWS に対する問い合わせに特化して書いているところはありますが、対象が AWS でなくとも、テクニカルサポート窓口に問い合わせをする際のご参考にしていただけると幸いです。
概要（お伝えしたいこと）
- AWS Support として望んでいることはすでに公式に書いてあるので、少なくとも AWS に対して問い合わせをするロールの人は、まずは目を通しておくと良いかと思われます。
- 問い合わせ文章は、5W2H を意識して問い合わせると良いと思います。
- 担当しているプロジェクトの全容について、ペライチで良いので、簡単に説明できる資料はあるに越したことはないです。
- 結局、急がば回れ。
ありえないだろう…、と思われるかもしれないが、よくある問い合わせ例
今朝から AWS につながりません。
障害など起きていないでしょうか。
上記の文例は、私が夢でみかけたと思しき文なので、ある特定のお客様からいただいた問い合わせ文面をそのまま転記しているわけではないことにご留意ください。
ただ、多少誇張した妄想的な問い合わせ文面ではあるものの、あながち 100％ 妄想というわけでもなく、本質的な部分では同質なお問い合わせをいただくことは、実は結構あります。
この文面で（私が、かろうじて）読み取れること
おそらく、AWS マネジメントコンソール自体か、AWS で作成した何らかのリソースに対して接続できない状態が発生していると拝察します。
かつ、すでに収束した事象に対して原因究明をしたい問い合わせではなく、現在も継続中の事象に対しての問い合わせではないかと推察します。
あとは、日本国内のお客様なので、「今朝」と記載されているのは、私が思う今朝と同じ時刻帯あたりを指しているんだろうなぁ、というところ。（ただし、それも私の推測に過ぎない。）
ツッコミどころは多いが…
確認したいポイントは思いつく限り以下かと思われます。
- 接続できない対象について明確にしたい。
- AWS マネジメントコンソールに対してなのか、AWS アカウント内に存在するリソースに対してなのか？
- 接続できない接続元は、「誰もが接続できない」のか「特定のユーザーだけ」なのか？
- 発生時間帯を明確にしたい。今朝というアバウトな時間軸ではなく、明確に何時ごろ、という情報がほしい。
- さらに言うなら、日本時間ですよね？という確認はしておきたい。
- 時間軸の話で言うなら、「今回初めて」なのか「一定程度発生していた」のか、発生頻度の情報もほしい。
ところで、AWS サポートにも SLA があります。
詳細は AWS Support プラン比較 をご覧いただきたいですが、契約しているサポートプランと選択したケースの重要度に応じて、目安となる初回応答時間の設定があります。
なお、出典の表の下部に注釈として「合理的な範囲でできる限りの努力を」と記載のある通り、「ベストエフォート」であることにも注意が必要です。
AWS Support プラン比較 https://aws.amazon.com/jp/premiumsupport/plans/ より抜粋
上記を見ると、例えば、エンタープライズプランを契約しているお客様で、「本番システムの障害」を選択したときには、おおむね 4 時間以内には初回の回答をもらえることとなります。
AWS の初回ターンを問い合わせ内容の再確認に費やすのはもったいない
さて、前述のような問い合わせ文面を送信していて、初回回答を得た際に、一発で課題解決する回答を得られないであろうことは、想像に難くないと思います。
文章の書きっぷりはさておき、「ツッコミどころは多いが…」の節で記載したような確認ポイントを列記した上でのヒアリングが初回回答として返ってくるのではないかと想像できます。
前述の応答時間を待機して、ようやく得られた返事にヒアリング項目しか書かれていない状況は寂しいものがありますよね。
本番環境にクリティカルな障害が発生している場合であれば、虚無感と落胆は相当のものだと思います。
極力、ツッコミどころのない問い合わせをしよう
結局のところ、これに尽きるのだと思います。
障害や発生事象により緊急度はもちろん、問い合わせの内容も都度異なるものの、問い合わせた内容に対する逆質問の発生を極力減らしてやり取りのターン数を削減することで、可能な限りスピーディな課題の解決につながると考えています。
では、どのように伝えようか
問い合わせを送る相手は、会社の中で隣にいる同僚や上司、あるいは取引先や協業先などではなく、まったくの第三者である点が重要なポイントです。
相手に対して理解を求めるにあたり、同じ文化圏にいない人が対象であるという点で、ハイコンテクストな記述は避けるべきです。
社内の人間であれば知っているであろうことも伝えないと、相手は知り得ないという点に注意が必要だと考えます。
相手は何を知り、何を見られるのか
AWS の利用者、AWS テクニカルサポート、そして、私が所属している企業のようなパートナーの三者で、誰が何を知り、何を見られるのかを簡単にまとめてみました。
それぞれの立場で、見られる見られない、知っている知り得ないがあり、それらについてはより意識して伝える必要があると考えられます。
さらに言うと、共通で見られるはずの AWS マネジメントコンソールであっても、予備知識がないと理解できないような側面や対象の取り違いは考えられるので、「相手も環境を覗けるはずだから…」と思わず、認識齟齬を生まないよう丁寧な記述をした方が良いと考えます。
| 対象 | AWS 利用者 （お客様） |
（私の所属企業のような） パートナー企業 |
AWS テクニカルサポート |
|---|---|---|---|
| 設計背景や実装 | ○ 知っている |
× 知り得ない |
× 知り得ない |
| 障害や事象の影響度 | ○ 知っている |
× 知り得ない |
× 知り得ない |
| AWS マネジメントコンソール | ○ 閲覧可能 |
○ 閲覧可能 ※一部例外あり1 |
○ 閲覧可能 ※一部例外あり1 |
| AWS で構築されたサーバ内部のデータやログ | ○ 閲覧可能 |
× 閲覧不可 （ログインしない） |
× 閲覧不可 （ログインしない） |
| AWS 物理基盤 | × 閲覧不可 |
× 閲覧不可 |
○ 閲覧可能 |
過不足のない問い合わせのために
「いつなにがどうした」を整理する方法としてよく使われている 5W1H のスキームに、もう一つ How Much を追加して 5W2H として整理してみました。
あくまで、整理方法の一例ですし、私も書きながら「なにが」と「なにを」、「なにに」をすべて What に詰め込めなくもないなぁと思ってしまったところもありましたので、お客様組織内やプロジェクト内でアレンジいただいて良いかと思います。
| 5W2H | 目的 | 問い合わせ時の記載項目として考えられる事柄 |
|---|---|---|
| When | ・時間軸、頻度、継続の有無を伝える | ・事象を観測できた日時 ・タイムゾーン ・観測した事象は１回のみか ・観測した事象は継続中か、収束しているか |
| Where | ・事象が発生している箇所を伝える | ・事象が発生している AWS リソースの ID や ARN |
| What | ・何をした時に発生する（発生した）かを伝える ・すでに試してみていることがあれば合わせて伝える |
・＜How＞で伝える発生事象に対して、何をした時に発生するのか。 あるいは何をした時には発生しないのか。 ・事象の解決を目的として、すでにやってみた行動はあるか。 |
| Who | ・事象に関与する人物、モノ（操作主体）の有無や詳細を伝える | 上記の＜What＞に対し、関連するヒト・モノがあれば記載する 例） ・操作主体（呼び出し元）としてのIAM ユーザーやロール ・操作主体（呼び出し元）としての Lambda など他の AWS サービス・リソース |
| Why | ・発生事象をなぜ問題視しているかを伝える ・実装しようとしている背景を伝える |
・発生している事象において AWS の不具合・不備を疑うに至った理由を伝える ・構築中や検討中などで想定するゴールのイメージに対して、設計意図を伝える |
| How | ・どのような症状かを伝える | 発生している事象を記載する。 例） ・接続ができない ・操作不能となる ・〇〇という結果となることを想定しているが△△となる |
| How Much | ・影響度はどの程度か伝える | 事象が発生していることの業務への影響（ビジネスインパクト）を記載する。 定量的な記載であればより客観的に判断が可能になる 例） ・〇〇人のユーザーのアクセスを処理することができず、〇〇円／日の損失がある |
5W2H それぞれのポイント
When
時間軸、頻度、継続の有無を記載いただきたい点はもちろんですが、AWS ではグローバルサービスということもあり、グリニッジ標準時/GMT（一部 太平洋標準時/PST）が利用されていることもあるため、意識齟齬を生まないためにタイムゾーンを記載いただくとより良いと思います。
Where, Who
EC2 インスタンスの Name タグなど、タグの値は、同一の値を許容しうるため、一意に特定できる値としては適切とは言えません。
意識齟齬を生まないために、インスタンス ID や ARN など、一意となる値を使用することをお勧めいたします。
また、同様に意識齟齬を回避する目的で、お客様固有の俗称や略称の利用（AWS が正式に行なっていない略称も含む）も避けることで、スムーズな共通認識につながると考えます。
また、通信経路の把握に構成図を共有いただけると理解が早まる点もありますので、複雑な構成をとっているような場合や被疑箇所を明示したいような場合に添えていただけると幸いです。
余談ですが
お客様からご連絡いただいていた SQL Server が関連するお問い合わせで RDS と記載されていた箇所を Amazon Relational Database Service と認識し対応していて、どうも話が食い違うな？と思ったところ、Windows Server リモートデスクトップサービス（RDS) のことだったと判明し、対応方針の変更を迫られた場面もありました。
What, How
事象が発生する際の再現手順として記載いただくと良いと思います。
AWS では（弊社でも）事象の再現性を確認してお客様固有の問題か否かの判断をしたり、回避方法の有無の目的で、実際に検証を行う場面は多々あります。
「やってダメだったから意味ないわ」と思わず、やってみてダメだったことも添えていただけると、検証項目からの排除につながり、結果として迅速な課題解決につながると考えます。
Why
予備知識のないテクニカルサポート担当側からは、AWS マネジメントコンソールで発生している事象や設定は、拝見する段階での事実（の集合体）でしかない側面があります。
設計の意図や目的（ゴールのイメージ）などの情報をいただいていることで、現在の実装方針では実現できないと判明したことに対して、代替案のご提示をすることが可能になる場合があります。
How Much
前述の通り、初回応答時間はベストエフォートであるため、同時に同程度の緊急度設定のサポートケースが上がってきた際に、取捨選択が発生してしまう可能性はあると考えられます。
その際に、定量的な記載を行うことで、お客様のお困り度合いをより適切に、かつ、より客観的な判断基準として相手に伝えることにつながると考えられます。
まとめ
本番障害が発生している場合など、緊迫した状況の中問い合わせを行わないといけない状況を考えると、本当に大変だろうな、とサポート担当側からも感じています。
そして、緊迫した状況だとわかっているものの、こちら側の不明点を次々とヒアリングしないといけない状況は、障害対応する中でさらに負荷をかけるものだと思っていて心苦しいことが多々あります。
ただ、サポート担当としても伺わないと知り得ないことで背景や事象の理解のために、やむを得ず問い合わせに対し逆質問を行なっていますが、初回から詳細な情報をいただけていると「この数ターンのやり取りにかかった時間分だけ解決が早まったのになぁ」と思うケースは結構見受けられます。
構成図の作成や要所要所でのアップデート、問い合わせ対応時に起票しやすいようなテンプレートの作成と共有など、有事に備えて用意いただくと良いかと思います。
その際に、本エントリで記載したような観点で伝えるとやり取りのオーバーヘッドを減らすことができ、結果として課題解決の速度が上がるかもしれないとご記憶いただけると幸いです。
さらに、再掲ですが AWS が公開しているガイドラインもお読みいただくとより万全です。（むしろ必要なことはすべて記載されています。）
仲間も募集中！
冒頭で記載しました通り、所属企業でアドベントカレンダーを実施していますので、その他の記事もぜひご覧ください。
そして、仲間も募集中ですので、話を聞いてみたいな、などあればお気軽にご連絡をいただけると中の人達が喜びます。