皆さんこんにちは。湿気のせいで頭にカビが生えそうなid:k-furusawa--gです。
皆さんOracle Cloudで分からないことや疑問があった際はどうしていますか？ 私はOracle Cloudサポートのサービスリクエスト（以下、SR）を活用しています。しかしSRはなかなかにハードな質問力を要求してくるので、なかなか書きづらいのではないでしょうか。私も何度かSRで回答不可として突き返されて苦しい思いをしております。
というわけで、今回はさらに毛色を変えてSRの書き方なんかに触れていこうかと思います。SRを作成する側も、受ける側も少しでも楽になればと思います。
本記事の目次
まずは使えるようにしよう
Oracle Cloudサポートをまずは使えるようにする必要があります。
使えるようにするまでの道のりは、本ブログで記事になっておりますので、そちらをご覧ください。
重要になるのは質問内容の書き方
サポートでSRを投げようとしているときの心理は、とても困っていたり焦っていたりするものだと思います。
とはいえ要点のまとまっていない事をSRとして投げられても、読み手は困ってしまいます。質問内容の確認のための確認が発生すると時間の無駄ですね。それでなくてもSRは海外エンジニアが対応することが多いので、時差の関係で回答が返るのに数日は覚悟しなければいけません。なるべくスムーズに進めたいところです。
そこで重要になるのは、質問内容です。以下に、重視するべき事柄をまとめました。
質問したいことを絞ろう
あれやこれやと複数の質問を1つのSRに書くのは止めましょう。要点を1つにまとめると回答を得やすいSRになります。もしも複数の質問がある場合はSRを分けてしまいましょう。
SRを分けることで事象の整理ができ、もしかしたら自己完結に結び付くかもしれません。どうしても回答が導き出せない事だけをSRに書くように努めましょう。
SRを書くに至るまでの経緯を整理しよう
そもそもなぜSRを書くに至ったのかを明確にすると、SRを読む側も状況が整理しやすくなります。
何を操作しようとしたのか、どのサービスを利用中だったのか、もしくは利用しようとしているのか、などなど自分が何をしたくて何を行ったのかを端的に説明できるようにしましょう。
整理しているうちにSRじゃなくても確認する術が見えてくるかもしれません。
これは同時に、自分がいまOCIで何をしようとしているのか？ という整理にもつながります。
いつの出来事なのか明確にしよう
エラーの発生や何かしらの障害が疑われる状況で、藁にも縋る思いでSRを書こうとしている場合は、いつから発生している事象であるのかを確認しましょう。
日本時間で何月何日の何時まで明確に伝えることで、OCIのエンジニアも調査がしやすくなります。
今発生している！ っとSRを慌てて書いても、それを確認するエンジニアが海外の人だとすると対応は翌日だったりして認識に差が出てしまいます。
今とはいつか？ SRを読む人にとっての「いつ」を意識して書くとよいでしょう。
どこで起きているのかを把握しよう
割と難しいことでもあるのですが、どこの話であるのかを把握し伝えるようにしましょう。
この「どこ」とはつまりリージョンであったり、OCIでのコンパートメントであったり、クラウドアカウントであったりと様々です。
エラーや障害関係の場合、少なくとも「どこリージョン」の「どこサービス」で「どこのコンパートメント」なのか。は最低限把握し伝えるとよいでしょう。
なるべくスクリーンショットを送付しよう（英語推奨）
OCIダッシュボードでエラーが発生する！ なんか知らんがインスタンスが表示されない！ 文字化けしてるんだけど！ という画面のトラブルは多いです。
そういうときはスクリーンショットを保存しましょう。SRにファイル添付が可能なので、なるべくこれを活用していきましょう。
ただし画面のスクリーンショットを撮影する際は言語を英語にしておきましょう。基本的にエンジニアは英語園の方々なので、日本語の画面を送っても対応できないと返されることが多いです。
参照したドキュメントを書こう
SRを書くに至るまでに、公式のドキュメントを参照していると思います。何も調べずにいきなりSRを書く人はいないでしょう。
SR内に、どこのドキュメントを最低限読んだのかを書きましょう。書かないとエンジニアがドキュメントのURLを返してくることもあります。
ドキュメントに情報が不足していることもあるので、その場合はその旨をしっかりと伝えましょう。
私の経験ですが、エンジニアに「このドキュメントに書かれています」と返されたドキュメントには書かれておらず、それを伝えるとドキュメントに修正が入り詳しい説明も得ることができました。
変な回答を得ても怒らずにSR内容を見直そう
これは明言しておきますがいきなり１００％の完璧な回答は期待しないでおきましょう。それは無理です。
明らかに対応方法が間違っていたり、回答が不適切なことはあります。困っているのにいい加減に見える回答が返ってくることもあります。私もそれなりの数のSRを作成しましたが、SRは珍回答が非常に多いです。
そういう時は、もう一度SR内容を確認しましょう。勘違いをされてしまう要因が含まれてしないか読み直してみましょう。
必ずというわけではありませんが、どこかに珍回答を引き出してしまうような事柄が隠れていることがあります。肝になるのは英語翻訳です。自分の質問を翻訳にかけてみましょう。意図せずIT用語や別の意味にとれる単語に変換されてしまいエンジニアの混乱を招いていることもあります。
それでも納得できない回答が返ってきている場合は、素直に「この回答の意味が分からない」と返すのも重要です。どうしてその回答に至ったのかの理由を聞いてみるのもいいでしょう。時間はかかってしまいますが、認識の違いがあるまま進めるよりかは、かなりマシになるはずです。
質問先をよく考えよう
SRを書く際に、サービスタイプを選択する項目があります。これは重要なのでよく考えて選びましょう。
ここでどのサービスを選択したかによって、対応する部署が変わります。OCIであってもアカウント情報に関するものなのか、それともサービスについてなのかで対応が大きく変わります。
全く関係のない質問を、全く関係のない部署に投げてしまうのが一番まずいです。SR内容をよく読んでサービスタイプを選びましょう。
必須項目はなるべく正確に答えよう
SRでの関門の一つに、必須項目の質問一覧があります。これはなるべく書くようにしましょう。ここをいい加減に書くと、対応が拒否されることがあります。
特に環境の質問や再現性の有無などは重要ですので、必ず書きましょう。
ただし、エラーや障害とは関係のない、技術的な質問などでは何を書けばいいのか分からないと思います。そういう時は「質問事項のため該当なし」など、丁寧に書かない理由を書きましょう。
あんまり回答がないときは催促してみるのも手
SRが2週間ほど放置されてしまうことがあります。そういう時は、催促してみるといいでしょう。
ただし、「回答がないんだが！」などと強めに書かずに、状況はどうか、こちらでも再度試したが解決しないなど、自分側の進捗も書くといいでしょう。
SRは投げっぱなしにはせず、解決に自分なりに努力してみるのが重要です。OCIのエンジニアより先に原因を突き止めてやる！ という意気込みでもいいかもしれません。
SR質問雛型
最後にSRを書く際の雛型的なものを用意しました。全部の質問に使えるわけではありませんが、とりあえずここまで書けば問題ないのではと思います。
サマリ（SRタイトル）
【質問・障害報告】短い質問内容。一目で質問なのか報告なのかわかるようにする
本文
【質問内容】 詳しい質問内容。要点を絞って、端的に書く。 【発生時刻・期間】 日時と期間とか。正確に。UTCとかを意識して書くとなおよい。 【目的】 最終的に自分がやりたいことを書く。短く。 【経緯】 何をしようとしたのか、何が起きたのか、どこまで確認したのか。SRに至るまでの経緯を順に整理して書く。 必須項目の「行った手順」にはこれを簡略にしたものを書く。 【参照したドキュメント】 ドキュメントURLを箇条書きで書く。文字数制限で厳しい場合は、必須項目の「行った手順」に書く。
おしまいに
困ってサポートに頼ってるのに気を使わなきゃいけないこと多すぎじゃない？ って思った方は、一歩引いて落ち着きましょう。
単純な質問なら自力で解決できるはずですし、ドキュメントに書かれていることならOCIのエンジニアが出てくるまでもありません。SRを作成して質問するとは、つまりそういった領域ではない高度な質問を投げるということです。
その分、曖昧な内容やはっきりとしない事柄で質問することは望ましくありません。する側もされる側も幸せになりませんね。
私もSRでよくわからない質問をして、よくわからない回答を得て、よくわからないまま時間だけが過ぎる事態に陥りがちです。そういったことを少しでも減らすべく、実のあるSRを作成していきましょう！