こんにちは。
Microsoft の製品をお使いの皆さんであれば、過去に 1 度は SR で問い合わせを行ったことがあると思いますが、その SR の話です。
今、CSA Dev Advocate というロールで、Microsoft Azure の技術支援をしていることから、お客様から SR の内容について相談されたり、SR で問い合わせが長期化しているといった相談をいただいたりします。
これらについては、様々な要因があり一概には言えないのですが、SR の上げ方を改善することでもっと素早い解決に至ることも少なくはないと感じたので、自分の考えの整理のためにこの記事を書きました。
ただ、前提として、僕はこの SR を受付お答えする部門にはいませんので、この記事で書いていることは僕が知ってる範囲の経験に基づき感じたことを書きます。
あと、今回は、SR をあげられるサポート契約があることを前提に書いてます。
SR のあげ方のコツ
Microsoft Azure で SR をあげる時、どこからあげてますか？
なんとなく経験上、Azure ポータルの「ヘルプとサポート」から「サポートリクエストの作成」をしている方が多いんじゃないかなって思います。
上記からでも問題なですが、もっといい方法があるんです。
Azure の各リソースのメニューの一番下に、「サポートとトラブルシューティング」というメニューがあります。下のスクショはこのサイトで使ってる App Service のリソースです。
そのメニューを開くと、「どのようなご用件ですか？」って問題の内容を聞いてくるんですね。
例えば、「コンテンツの表示が遅い」みたいに問題の内容を入力してみます。
そうすると、下のようなパフォーマンスに関するメトリックや、各種チェックを行ったリストを表示してくれます。今回はサンプル的にこのサイトので試したので特に問題ないけど、どこかエラー出たら良かったんですけどね。。。
あとは、Web の情報を教えてくれてますが、Teams じゃないんだよなーってところに、Microsoft っぽい雑味を感じます(しかも、自社コンテンツじゃないし。。。)
他にもおまけ的なことを教えてくれてますが、実際にトラブル起きてる時に他のことも教えられても、そんな場合じゃないよとは言われそう。。。
でも、こうやって切り分けするための情報を観れるのは、問題発生時にはとても重要なことだと思います。
で、上記の出て切り分けできたら SR しないで更なる問題調査をして、必要に応じて SR をあげていただくという流れになると思います。
SR が必要になったら上記の画面の右上の「×」で閉じるとこんな感じで、「サポートに問い合わせる」が出てきます。
最初「×」で閉じるってのに気づかなくて躊躇しましたが、そこは勇気を出して押してください。
で、ここで SR 最初から書くのかよって思う方もいると思いますが、この部分だけは補完してくれます。
多分ここまで読んでいただいた方は、こんな切り分けも全部 MS に相談したいから、真っ先に SR 投げたいんだよって方は、Azure ポータルの「ヘルプとサポート」からあげていただければと思います。
SR に記載する内容のコツ
SR をあげる際には、以下 2 点を意識して記載いただくといいと思います。
- お困りごとの内容をできるだけ詳しく書く
- 解決したいゴールを正しく書く
なんかすごく当たり前のことですよね。
詳しく書いた方がいい理由
詳しく書いた方がいいのは、情報量が多い方がいいに決まってるじゃんっていうのはそうなんですけど、それ以外にも理由があるです。
まず、サポートチームは製品のカテゴリ別にチームが組まれてます。
Azure の場合、Azure っていう1つのチームではなく、わかりやすいところで言えば、IaaS 系のインフラチームであったり、PaaS 系のチームであったり、DB系のチームのように複数のチームで構成されています。
最初のお問い合わせの時に、内容が曖昧であった場合、本来担当すべきチームと別チームで受けつけられてしまうケースがあります。
もちろん内部では連携して対応するのですが、普通に考えても本来担当すべきチームでお答えする方が早いですよね。
なので、最初の問い合わせの時は、以下の点に留意してできるだけ多くの情報をご提供いただけるとスムーズだと思います。
- どんな事象が起きているのか？
- これまでどんな調査したのか？
- MSに何を解決して欲しいのか？/しりたいのか？
多分この内容をまとめるためにも、各リソースの「サポートとトラブルシューティング」のところで一度切り分けてから SR をあげていただくといいんじゃないかなって思います。
解決したいゴールを書いた方がいい理由
問題が起きてるから改善したいって、すごく気持ちはわかるんですよね。
ただ、何ができたら改善できたは定義しないとそれに対してどこまでお答えできるかわからないですよね。
例えば、社内で重要システムがスローダウンして社内利用者から問い合わせが殺到している、App Service で動く Web アプリがあるとします。
これで、「Azure 上の Web アプリでスローダウンしてるから改善したい」って問い合わせあるとするじゃないですか。
で、まぁー スケールアウトとかスケールアップして改善されるか見てくださいとかって話は出てくると思うんですよね。
そうすると、料金が上がるからできないとか返事が来がちだと思うんです。
この時点で改善とは。。。。ってなっちゃいますよね。
一時的でもいいから今起きてる問題をすぐに解消したいのか、恒久的な対応でパフォーマンスチューニングの相談なのかで多分は答えがちがうって感じですね。
あと、「アプリも含めてパフォーマンスチューニングして」は多分 SR の範囲外になると思います。理由は、アプリが MS 製品じゃないからです。でも、Application Insights とかで性能的なメトリックスはどれどれですよくらいは教えてくれるかもしれないですし、もっと教えてくれるかもしれません。
より具体的なゴール設定をすることで、サポートエンジニアは答えやすくなると思います。
最後に
最後に、この記事で伝えたかったこととして、Azure を使う上で SR をうまく活用して頂きたいと思ってます。
Azure がクラウドのサービスである以上、責任共有モデルの仕組みであるため、MS に聞かないとわからないことって沢山あると思うんですよね。
一般に公開していない仕様もありますし、あんまりあると困るんですが Azure 側の障害がある場合もあるので。
で、その際に、サポートエンジニアと SR でのお問合せをいただいているみなさんは、同じ責任共有モデルの中にいるパートナーの関係だと思います。
問題の早期解決を目指して一緒に対応する仲間の一部とサポートエンジニアを捉えていただけると、サポートエンジニア側も色々と回答がしやすくなると思います。
逆に、サポートを受ける側と提供する側という主従関係という捉え方はやめた方がいいと思います。
経験上、「有償のサポート契約をしてるからこっちは客だぞ」とか
「Azure 使ってやってるけど、対応悪いと AWS に乗り換えるぞ」とか
そういうスタンスの方がいなくはないと思ってますし、人それぞれの考え方があるのでそういう考え方があってもいいと思います。
ただ、SR で問題を解決するのであれば、サポートエンジニアも含めもっともパフォーマンスが発揮できる方法を選択した方がいいと思います。
で、その後に、Azure 上の仕様やサポートの対応については、営業ロールに言っていただくのがトータルとしていいと思います。
ってことで、SR をうまく有効活用していただいて、Azure をより快適に利用してください〜。
コメント