Azure Supportの問い合わせで気を付けること
はじめに
日々Azureを利用していくうえで、技術的な問合せ（障害時の復旧サポートや仕様の確認）で、AzureサポートにSR (Support Request) を行うこと、数多くあると思います。
ここでは、何かしら技術的な問い合わせをするときに、「正確な解答」を「早く引き出す」ためのテクニックとして、私が意識していることを吐き出してみたいと思います。
問合せが悪いと、サポート側も何を答えていいのか分からず、意図の確認に何往復も必要となってしまいます。問い合わせが長期化してしまうことで、結果として我々利用者にも利用料やサポートのサービスレベル低下（返事が遅くなる）などの不利益が見込まれます。
私自身もこれまで「サービス運営」に携わってきた経験から、何を聞きたいのかわからない質問を数多く目にしてきました。利用者・サービス双方が幸せになるために、問い合わせ側もレベルアップしましょう！というお話です。
なお私の場合、AzureポータルやAPI操作で、意図通りのことができない／マニュアル通りに動かない／マニュアルに記載がない」といった仕様関連や、インフラエンジニア観点での障害調査の問い合わせをすることが多く、視点が少し偏ってるかもしれません。
参考情報
Azureの話をするのに、いきなりAWSのページから参考情報を持ってきます。（以前、Azure使いだすときにまずやることを書いた時にも同じようにAWSの情報を参照しました。笑）
こちら、とてもよく纏まっており、クラウドサービスに限らずどこに問い合わせるときでも参考になります。ぜひ読んでみてください。
気を付けること
それではAzure版、サポートに問い合わせるときに気を付けていることです。
契約
サポートプラン
必要なサービスレベルのサポート契約を行う
そもそもですが、必要な問い合わせができるサポート契約が必要です。Azureのサポートは以下の４段階に分かれており、何かしら技術的な問合せを行うのであればDeveloper以上の契約が必要になります。
問合せできる内容だけでなく、重要度・連絡手段などの設定にも影響がでますので、その環境に必要な契約を行います。
起票
カテゴリ
間違えると担当外のエンジニアが付いてしまうので、地味ながら重要な選択肢です。どのサービスの、どういう問い合わせをしたいのか。プルダウンで選びます。
カテゴリ・サブカテゴリ選びは、できるだけ妥協しない
どの問い合わせカテゴリが適切かわからず、選んでみないとどういうサブカテゴリがあるのかもわからない。早く問い合わせたいのに、どう選んだら適切なのかわからずストレスが溜まる工程…。特に障害時だと急いでいるのにどう問い合わせればいいか分からなくて困ってしまいます。
しょうがないので、適切なカテゴリが見つからない場合は近いところを選択し、フリーテキスト部分に詳細を書くことにします。
ただ、ここで正確な選択ができてないと、サポートエンジニアが「誤解した状態」からスタートしてしまうので、できるだけ適した選択肢を選びましょう。
なお、サービスをまたがる接続・連携部分に対する問い合わせだと、最初にアサインされたエンジニアのサービス側で解答し切れないと「専門のエンジニアが対応するので、再度起票してください」などと言われてしまうので、要注意です。
以前、問い合わせの後のフィードバックで「せめて一覧を公開して欲しい」などと要望したこともありますが…期待薄な反応をされました。
関連して、ある方のQiitaの記事で、サポートカテゴリの一覧の取得方法が書かれていましたので、紹介させていただきます。
重要度
問合せの応答時間や、対応時間（業務時間／24時間）を決める重要度（Severity）です。
適切なSeverityを選択して、問い合わせをする
特に障害の時は、当事者にとっては重要度が高く感じられるものです。ですが、不必要に高い重要度で問い合わせてしまうと、サポート担当から見た優先順位の選択を狂わせ、正当な問合せを行っている他の利用者が不利益を被ることになります。長い目で見ると、サポート/問い合わせ者の双方にメリットがありませんので、適切なランクを選択しましょう。
Mirosoftの問い合わせでは、Severity A〜Cの3段階で重要度を選択します。
| 重要度 | 内容 |
|---|---|
| Sev.A | 事業に大きな影響が発生する場合 |
| Sev.B | 事業に部分的な影響が発生する場合 |
| Sev.C | 事業に軽微の影響が及ぶ場合 |
（参考）https://azure.microsoft.com/ja-jp/support/plans/response/
大きく変わるのは 「Sev.A」 を選択した時です。
事業に大きな影響を及ぼす障害のときなどにのみ使える選択肢で、例えば「銀行のATMが止まっている時」レベルです、と説明されたことがあります。
Microsoft側のエンジニアも24時間張り付きで対応に当たってもらえる分、利用者側も同じ体制（24時間体制）が求められます。Azureに限らず、オンプレミスでのPremierサポート含めて何度かSev.Aの問い合わせを行ったことはありますが、そもそも辛い障害の時ですので、二度と使わずに済むならそれに越したことは無い、という禁断の魔法です。
Sev.Bは冗長構成・複数台構成のサーバーが崩れるなど性能などに影響が出ているが、機能面ではサービス提供できている状態などに使います。
Sev.Cは、事業に影響は出ていない仕様面の問い合わせや、すぐには困らない不具合の際などで使うことになります。
連絡方法
基本的にWEB起票後はメールで進めますが、受ける電話は利用しましょう
賛否別れるところもあり、AWSの問い合わせだとメールを推奨されていますね。これはサポート目線で「電話で聞かれても即答できないから」です。
Azureのサポートの方は、（メール連絡を希望しても）電話をしてくる傾向にあります。笑
サポートエンジニアの方からすると、状況を聞いたり調査方針を固めるためには電話の方が認識合わせしやすいのかと思います。
逆に利用者側からは、エラーログ・簡単な構成図・背景の説明など、添付ファイルがあった方が認識合わせしやすいため、メール・Web（サポートリクエストページ）から情報を渡す方が進めやすいことが多いと思います。
手段にはこだわらず、認識齟齬を無くしてできるだけ無駄なくサポートが進められる道を選びましょう。
内容
解決したいことの共有
目的を明確にする
この問い合わせを通して、何を実現したいのか、サポート担当としっかり共有すると、問い合わせがスムーズに進みます。
何が目的か、はっきりゴール設定をします。
技術問い合わせなのか？障害対応なのか？
障害対応であれば、「復旧」がゴールなのか「原因究明」がゴールなのか？
サポートの方はリクエスト次第で、動きが変わります。復旧が優先なのに、原因究明に時間を使われてしまうと困りますよね。
問い合わせの背景を伝えます。
なぜその問い合わせをしているのかを、補足するようにします。
「こういうことは出来ますか。機能はありますか。どうやれば出来ますか？」と限定してしまうと、「サービス仕様上できません」で終わってしまいますが、背景を適切に共有できれば「もっと最適な方法が…」など提案してもらえることがあります。
困っているシステムの構成図を渡す、といったことも、サポートエンジニアの方と認識を共有する上で有効です。
状況の共有
事象を明確にする
サポートする側からすると、発生している事象や課題の全体像をまず明らかにしたいものです。特に障害の時は、5W1Hに照らし合わせて必要な情報を渡せているか考えます。（ビジネス書とか自己啓発本みたいですね…）
基本的に、サポートページのフォーマットに従って入力していけば、最低限必要な情報が満たされるようになっていますが、フリーフォーマットのところに自分で情報を埋める必要もあります。
例えば、
発生している課題を可能な限り明確化しましょう。
「VMに接続できません」という事象でも、
・where（from/toの問題、オンプレから？（ExpressRoute経由？インターネット経由？）、Azure内で別VM？）
・how（プロトコルは何？Pingに応答しない？SSH/RDPで接続できない？）
など状況によって疑うところが全く変わってきます。
事象の発生している時刻と、「継続状況」を伝えましょう。
whenの情報はかなり大事です。
・いつから発生している？以前はできたけど出来なくなった？最初から１度も出来ていない？
などは基本として、
・今も継続しているか／今は収束しているか／毎回か、ときどきか、１度だけしか発生していないか
・誰か一人の環境で発生するのか、誰がやっても発生するのか、同じPCから別アカウントでポータルにログインしたらどうか、別PCから同じアカウントでログインしたらどうか？
といった情報も、事象を切り分ける上で重要です。
サポートリクエスト起票ページでは「いつから発生している」しか入力できませんが、これでは情報が足りないことが殆どです。
ログ・キャプチャ・構成図などを連携する。
what（何が起きているか？何をした時に発生したのか？）を正確に伝えるためには、ログやスクリーンショットの形で発生している内容を共有することが大事です。
エラーメッセージを省略してテキストに書いたり、構成を頑張ってテキストにして伝えることは、多くの場合遠回りになります。
手順を明確にする
再現手順を連携する。
・同じ操作をした場合にサポートエンジニアの環境でも再現する場合、調査が格段に捗ります。疑っている動作の再現手順が確立している場合、必ず手順を連携しましょう。
※過去に、Azureポータルの明らかにおかしい動作がサポートエンジニアの方の環境で再現するにも関わらず、私の（利用者の）環境でパケットキャプチャを取らされたことがあります。結果、ポータル側の不具合だったんですけどね・・・。
試したことを明確にする
試した手順を連携しましょう。
参考にしたドキュメントなどあれば、公式だけでなく非公式なものも含めてURLを共有します。
また、ドキュメントに関係ない場合も「こういう手順を試したら、こういう結果になった」ということを明確にします。
問い合わせの序盤は、事象の切り分けのための「こういうことを試してくれ」とサポートサイドから提案されることが多くあります。すでに試したこと（つまり私自身は無駄だとわかっていること）を提示されることもありますが、事前に試したことを共有することで、この遠回りをかなり防ぐことが出来ます。
なお、「試した手順」や「（有効ではない）結果」については、【事象を明確にする】に準じて詳細に伝えることも大事です。
その他のコツ
ここまでは問い合わせに際し、どういう情報をいかに連携すべきか？という観点で書いてきました。ここからはちょっと別の切り口のTIPSを記載します。
Azure基盤側のログ保持期間
事象が起きたら、できるだけ早く問い合わせをします。
Azureサービスを稼働させている基盤自体のログを見てもらわないとわからないこともありますが、このログは無限に残されているわけではありません。
過去に聞いた範囲では、種類によって１週間／15日／３０日／９０日といった感じでパターンが分かれているようでした。「調査に必要なログが残ってる間に、問い合わせをする」ことが必須です。
ログが消えてしまっており、再発するまで待たないといけない…ということになりかねません。
サブスクリプションを跨ぐ問い合わせ
事象が発生しているテナント／サブスクリプションから問い合わせます。
問い合わせているユーザーアカウントと関係のないテナント・サブスクリプションで発生している事象について質問しても、サポートエンジニアからすると「無関係な環境のことは勝手には答えられない…」となってしまいます。
純粋な仕様に関する質問であればどこで実施しても良いですが、障害調査に関しては発生している環境から問い合わせる必要があります。
サブスクリプションを跨ぐような機能を使っている場合は、双方から問い合わせる必要があることもあります。その場合は、片方の問い合わせ番号を他方の問い合わせに記載し、同件であることが伝わるようにします。
ちなみに、サポートの起票画面で「問い合わせ番号」を記載すると、クレジットカード番号は書かないで！という警告が出ます。これ、地味にイラッとしますね…。
用語の選び方
通じる言葉を使いましょう。
特にエンタープライズで使っていると陥りがちなのが「社内用語」や「特定システム用語」をうっかり使ってしまうことです。聞き手からするとサッパリわかりません。
こんなの当たり前でしょ？と思いますが、結構聞かれること、ありますよ…。
問い合わせ時間
サポート窓口の稼働時間を考えます。
問い合わせ窓口の営業時間は、日本の場合平日の9時〜17時半です。それ以外の時間に問い合わせても（基本的に）営業時間中にしか反応してもらえません。日中に、こちらの作業待ちをさせてしまうと問い合わせが進まず時間がもったいないので、日中はできるだけサポート側に玉を持ってもらうように動きます。即ち、こちらのログ取得や切り分けは朝の9時までに行い、情報を渡します。
時々、どう見ても残業してくださるサポートの方もいるのですが、少なくとも新規受付を時間外にしてくれたことはありません。新規で問合わせるときは、何としても17時半までに打ち込みましょう。肌感覚ですが、翌朝のスタートダッシュが違います。
役割分担
サポート担当／開発担当の役割を考えます。
日本で問い合わせていると、基本的にサポート担当は日本にいる日本語話者になっていると思いますが、問い合わせ内容によっては本国（アメリカ）のエンジニアに確認してもらう必要が出てきます。
とすると、どんなに早くても１日１往復までしかアメリカのエンジニアには聞けません。開発部隊に確認する必要があるような問い合わせの場合、時間がかかることを覚悟すると共に、問い合わせの方向性が間違ってないか／何を聞いてもらうか、サポート担当の方とすり合わせを綿密にやりましょう。
帰ってきた答えが意図したものと違うと、とても時間を無駄にしてしまいます…。
1問1答
1つの問い合わせで1つのことを聞きましょう。
SRは1問1答というルールになっています。質問の答えによって次の質問に派生することもありますが、対象サービスや専門領域が少しずつずれていき、最初のサポート担当では答えづらくなってくることも多くあります。基本的にSRは1問1答の方針となっていますので、ちょっと逸れてくると「新しくSRを起票してくれ」という依頼を受けることがあります。
Microsoft側の管理の都合もあるようですが、新しく起票を提案されたときは素直に従いましょう。
答えてもらえない質問
サポートの方では答えられない質問、というものがいくつかあります。
修正時期の約束はしてくれない。
問い合わせの結果、Azureの不具合だと認めてられることがあります。サポートの方から開発部隊に修正依頼などしていただけるのですが、「いつまでに直す」など優先順位に関わるようなことは答えられないようです。
ものによっては「修正予定時期」や「サービスのアップデート予定」など分かるものもあるのですが、確約はされないので期待しないようにしましょう。
ただし、声を集めることで優先度を高くすることはできるようなので、要望自体は伝えることが大事です。
修正の報告はもらえない。
今不具合にはまっていて出来ないことで、修正され次第すぐに試したい・実装したいということがあります。しかしこの場合も「直ったら報告して欲しい」といった要望は受けてもらえません。
上に書いたように「修正の予定時期」まで聞いておき、その頃になったら改めてSRを起票し「不具合は改修されたか」と聞く必要があります。
不具合配下で動くように暫定構成にしておいて、不具合が無くなったら動かなくなることってあるんですよ。地味に困りますがこれはしょうがない…
クローズ
問い合わせが終わったら、SRをクローズします。その際にも忘れてはいけないことがあります。
クローズ漏れ
問い合わせが解決したら、必ず「クローズ」します。
回答をもらったらあと、何も反応しないとサポートの方から定期的に「状況伺い」の連絡が来ます。
無駄なステータス管理をさせてしまうことになるので、問い合わせた内容が解決しているのであれば必ず「解決しました、クローズしてください」と返します。
また、もらった回答を試すのに時間がかかる場合は、「いついつまでに試すから待っててね」と返事をしておきます。
一般ビジネスマナーみたいな話ですが、お互いが無駄なリソースを割かず、気持ちよくやり取りするためには大事なことです。
フィードバック
問い合わせ後、サポート担当の「評価」について聞かれることがあります。何かに忖度する必要はありませんが、ルールに従って回答します。
評価（メール）
「今回のサポートはいかがでしたか？」というアンケートメールが来ます。その回答についてです。
減点法で採点する
「問題がなければ満点」「何か問題があれば減点」という考え方になっています。
多くの日本人は「問題がなければ真ん中」「良ければ加点」と考えがちですが、Microsoftはアメリカ企業ですのでそこは考慮する必要があります。
※Microsoftに限らず、外資企業のサポートの方が「世界的な平均点と比べると、日本のサポートは質が低いと見られて困る」と発言されているのを見たことが何度かあります。
問い合わせた内容がちゃんと解決したら、基本的には満点になるかと思います。
逆に「早く解決してくれた」「より良い提案をしてくれた」など加点要素がある場合は、サポート担当の方が正当な評価を受けられるよう、フリーフォーマットのテキスト部分に書くようにしています。
優秀なサポート担当が評価されて、増えることが利用者メリットにもつながりますので、良かった点は積極的に伝えるようにします。
評価対象は「サポート担当」であることを意識する
問い合わせた結果、「Azureでは出来ない」「不具合だった」など残念な結果に終わることもあります。ですがその場合も、評価するのはあくまで「サポート担当」ですので、減点はしないようにします。
製品に対する不満や文句は、別途フィードバックしましょう。
評価（電話）
（特にうまくやり取りが進まなかった時など）「品質担当」の方から直接電話が来ることがあります。
不満、要望は整理して伝えます。
問い合わせに対して何かしら不満があれば伝えます。ただほとんどの場合、「評価（メール）」で書いた「減点」対象になるようなことはなく、基本的には製品への要望を伝えることがほとんどです。
品質評価に丁寧に答えることは、Azureやサポートの改善につながり、結果として利用者の利益になると思っています。
要望
製品に対する要望を伝えることは、正当な権利です。
問い合わせのクローズのタイミングで、サポートの方から「今回の問い合わせに関わらず、Azureに対する要望などはあるか」と聞かれることがあります。というかほぼ毎回聞かれます。せっかくの機会なので、このタイミングで不満や要望を伝えています。
どれくらい効果があるかは中の人でないとわかりませんが、問い合わせを通してサポートの方と友好的な関係を築けていれば、きっと要望を開発部隊に届けてくれるはず、です。たぶん…。
おわりに
以上の通り、問い合わせの時に私が意識していることをつらつらと書いてみました。
サポートの中の人からすると、「そんなわけあるか、もっとこうしてくれ！」みたいな話しもあるかもしれません。また、他の利用者の方から「こういう工夫をしているよ！」なんて話もきっとあると思います。
サポート／利用者双方のレベルアップが全体の幸せにつながるので、ぜひコメント・フィードバックいただけると嬉しいです！
Discussion