サポートケース利用ガイドライン

[akumakura]

---

• はじめに
• サポートケースを利用する前の重要事項
• 課題を明確にする
• 情報を集める
• 正確な情報を提供する
• 具体的な情報のみを提供する(抽象的な内容や曖昧な内容は提供しない)
• 客観的な事実を元に説明する
• 事実と推測は明確に分けて説明する
• 省略して説明しない
• 第三者に伝わらない用語は使用しない
• 理由を明確に説明する
• サポートケース利用ガイド
• 事前準備
• 公開情報を確認する
• 動作確認を行う
• 再現試験を行う
• 緊急度を決める
• ケース登録
• 回答の確認
• ケース登録後の注意事項
• 緊急度の変更方法
• サポートケースでは対応できない課題

---

はじめに

サポートケースでは、課題を円滑かつ迅速に解決することを心がけています。

本ドキュメントでは、サポートケースにて課題解決を円滑に進めるためのガイドラインです。

ガイドラインに則することで、課題解決までの時間短縮、サポートエンジニアとの認識齟齬の発生回避など、

サポートケースを円滑に利用することが可能になります。

サポートケースを利用する前の重要事項

課題を明確にする

サポートケースで解決する課題を明確にします。

▪️　事象原因調査

▪️　事象解消方法の確認

▪️　RMAリクエスト

など

サポートケースでは1つの課題につき、１つのケースで対応します。課題に対するソリューションを提供した時点で、登録されたケースは終了します。ソリューション提供後、続けて同じケースにて別の課題の対応は行いません(新たなケースの登録が必要となります)。

課題が複数になる場合は、課題数に応じてケースを登録します。また、同一の課題であっても内容が複数になる場合、内容ごとにケースを登録します。

⚠️課題によってはサポートケースでは対応できない内容もあります。対応できない課題については、「サポートケースでは対応できない課題」を参照ください。

情報を集める

課題を解決するための情報を集めます。

集められた情報を元にサポートケースでの対応が行われますので、過剰と思われる情報であっても可能な限り集めておきます。また、ヒアリングやログ収集にて、情報の具体化も行なっていきます。

集める情報の例としては次のとおりです。

▪️　事象の具体的な内容

▪️　事象発生直後のログ類、もしくは事象発生中のログ類

▪️　事象発生中のデバッグ情報

▪️　事象発生中のパケットキャプチャー

▪️　事象発生までの具体的な操作手順とその時系列

▪️　事象発生がわかるエラーのスクリーンショット類

▪️　事象発生時のコンソールログ

▪️　環境によって発生するという場合、発生する環境と発生しない環境の差異

など

サポートケースの登録後に取得依頼されることがあることも予測し、あらかじめそれらの情報も取得しておきます。こうすることで、情報取得のためにサポートケースの対応が停止する時間を短縮できます。

⚠️サポートケースにアップロードするファイル名に関する注意

サポートケースにアップロードするファイル名については、ZIP圧縮などしている場合も含め、すべてのファイル名にマルチバイト文字を使用しないでください。これはファイル名のエンコードによって発生する問題を避けるためです。

ファイル名には半角英数字を使用し、半角記号を使用する場合は"-(ハイフン)", "_(アンダーバー)", ".(ピリオド)"のみを使用してください。

正確な情報を提供する

サポートケースで提供する情報は、正確な情報を提供ください。

また、情報提供の際は、次のことに注意ください。

具体的な情報のみを提供する(抽象的な内容や曖昧な内容は提供しない)

例：

🆖：

サーバーに接続できません。原因調査をよろしくお願いします。

🆗：

192.168.10.0/24上の全てクライアントで"https://xxx/yyy/zzz.html"にアクセスすると、 ブラウザのエラーが表示されます。

ブラウザA,B,Cいずれでもエラーが表示されます。ブラウザAでのエラーの例は添付のとおりです。

また、クライアント上でエラー時のパケットキャプチャを取得すると、10.10.10.10(サーバーのアドレス)より〇〇のデータを含んだパケットが応答されていることが確認でき、これが原因と推測されます。

ブラウザにエラーが表示される原因と、解消方法の調査をお願いします。

客観的な事実を元に説明する

例：

🆖：

遅延が大きくなりました。

🆗：

パケットキャプチャで確認すると100msで通過していたパケットが200ms要するようなりました。この蓄積によって10秒遅延するようになりました。

事実と推測は明確に分けて説明する

推測をあたかも事実のように説明せず、事実と推測は区別できるよう明確に分けて説明してください。

例： 

🆖：

事象発生時刻 - 2022/02/22 15:30

🆗：

事象発生時刻 - ログ調査からは事象発生時刻は不明。

ユーザーからの最初の申告は2022/02/22 15:30にあり、申告時刻以前から発生していると思われます。

上記のNG例では、ユーザーからの最初の申告時間を事象発生時刻としてしまっています。申告時間はあくまでも申告時間であり、事象発生時刻とは異なりますのでOK例のとおり分けて説明してください。

省略して説明しない

説明する際は、省略して説明することはしないでください。

社内やプロジェクト内での共通認識であるために省略して伝わる内容などは、第三者は説明を受けなければその共通認識は持っていないため伝わりません。

事実の省略や文脈の省略も行わないでください。省略され説明されていない内容は理解できませんので注意ください。

第三者に伝わらない用語は使用しない

社内用語やシステム名称、プロジェクト名など第三者に伝わらない用語や略語は使用しないでください。

理由を明確に説明する

理由を明確に説明してください。

例えば、「ない」と一言だけ説明するのではなく、「ない」理由を明確に説明することで状況が正しく伝わることになります。

▪️　情報取得できなかったため、ない

▪️　ユーザーにヒアリングを行なったが記憶が定かではなく、ない

▪️　ヒアリングをしていないため、ない

▪️　記録が既に失われたため、ない

これらは全て「ない」という状況を説明していますが、理由を説明していることでそれぞれ異なる状況であることが伝わります。

サポートケース利用ガイド

事前準備

サポートケースを利用するにあたって、事前準備を行います。

事前準備を行う前に、「サポートケースを利用する前の重要事項」を必ず確認してください。

公開情報を確認する

製品マニュアルやナレッジベースなど公開されている情報に、課題を解決するための情報が掲載されていることがあります。

公開情報にて課題が解決された場合、サポートケースへの登録が不要となり課題解決の時間短縮が可能となります。

サポートケースへ登録する前に、公開情報で課題が解決されるか確認します。

💡公開情報で課題が解決されなかった場合：

確認した公開情報をサポートケースで伝えてください。

💡公開情報で課題が一部解決された場合：

参照した情報と、解決された内容と解決されていない内容をサポートケースで伝えてください。

動作確認を行う

公開情報でも課題が解決されなかった場合、動作確認によって課題が解決することもあります。

動作確認によって課題が解決された場合、サポートケースへの登録が不要となり課題解決の時間短縮が可能となります。

サポートケースへ登録する前に、検証環境などで動作確認を行います。

💡動作確認で課題が解決できなかった場合：

実施した動作確認の内容をサポートケースで伝えてください。

その際、以下を伝えてください。

▪️　動作確認を行なった環境情報

▪️　動作確認時の設定情報

▪️　動作確認時の詳細な手順

▪️　動作確認にて確認できた内容と確認できなかった内容

💡動作確認を実施できない場合：

動作確認を実施していないことと、実施できなかった理由をサポートケースで伝えてください。

再現試験を行う

課題解決における事象調査では、事象を再現させ再現環境での調査を行うことが最善手段です。

また、事象を再現できた場合、以下のことが可能になります。

▪️　事象を引き起こす設定の絞り込みと特定

▪️　ソフトウェアバージョンごとの再現性確認と既知事象との関連切り分け

▪️　回避策および解消方法の特定

サポートケースへ登録する前に、再現試験を実施します。

💡再現試験で事象を再現できた場合：

実施した再現試験の内容をサポートケースで伝えてください。

▪️　再現試験の環境情報

▪️　再現試験時の設定情報

▪️　事象が再現するまでの詳細な手順

💡再現試験で事象が再現しなかった場合：

実施した再現試験の内容をサポートケースで伝えてください。

再現しなかった場合でも、実施した内容をサポートケースで伝えることで重複した再現試験が行われることを避け時間短縮に繋がります。

▪️　再現試験の環境情報

▪️　再現試験時の設定情報

▪️　再現試験で実施した詳細な手順

💡再現試験を実施できない場合：

再現試験を実施していないことと、実施できなかった理由をサポートケースで伝えてください。

緊急度を決める

課題に対する緊急度を決めます。

緊急度は技術的な要素のみが考慮されます。技術的な要素以外は全て緊急度の決定には関与しませんのでご注意ください。

以下の基準をもとに、課題に対する緊急度を設定します。

▶️　緊急度1 (Critical)：

製品が停止、もしくはミッションクリティカルな機能が使用不能な状態に陥り、本番環境に重篤な影響を与えている。かつ、回避策や解消法もない状態である。

▶️　緊急度2 (High)：

製品が停止しているものの本番環境が停止するには至っていない状態。ただし、製品が停止していることにより、本番環境に問題が発生している。かつ、回避策がまだ見つかっていない状態である。

▶️　緊急度3 (Medium)：

製品の機能に問題が発生しているが、本番環境に影響を与えていない状態である。

製品の問題が特定され、回避策も発見されている状態。

▶️　緊急度4 (Low) :

製品の機能に問題はなく、製品を使用している本番環境にも問題が生じていない状態である。

製品検証時に発見された問題、製品ドキュメントについての問い合わせなどが、この緊急度に設定されます。

⚠️緊急度1及び緊急度2を設定する際は、設定した技術的な理由を必ず説明ください。技術的な理由の説明がない場合、設定した緊急度では対応致しかねます。

「原因と対策の報告が至急で求められている」などの技術的ではない理由では、緊急度は上がりませんので注意ください。

ケース登録

事前準備の内容を踏まえ、サポートケースを登録します。

💡テンプレートの情報を埋める

ケース登録時のテンプレートが用意されていますので、テンプレートに沿って情報を埋めていきます。

▶️　ASC(Authorized Support Center)向けテンプレート

* ASC所属の方は用意されているテンプレートを必ず使用ください

Strata製品向けケース Template

Cortex Data Lake/ Prisma Access ケース テンプレート

Cortex XDR 製品に関するお問い合わせ時のケーステンプレート について

テンプレートでは、オープン質問とクローズ質問の項目があります。

▪️　自由回答形式(オープン質問)の回答：

要点 → 理由 → 背景・例　の順で記載すると伝わりやすいです。

▪️　選択回答形式(クローズ質問)の回答：

Yes or Noと答えるだけでなく、その答えの理由や背景を記載するとより伝わりやすくなります。

「Yes. Because ...」「No. Because ...」「はい。なぜなら...」「いいえ。なぜなら...」

💡テンプレートを使用しない場合

テンプレートが用意されていない場合など、やむを得ずテンプレートを使用しない場合、解決する課題について以下の文章構成で記載します。

要点 → 理由 → 背景・例

起承転結の文章構成では、解決する課題の把握が難しくなりますので注意ください。

回答の確認

サポートケースにて回答を得られたら、その内容を確認します。

また、理解できていない回答内容は明確にし、その内容を再度質問します。再質問する場合も、サポートケース登録時と同様「サポートケースを利用する前の重要事項」に則してください。

ケース登録後の注意事項

▪️　常に最新の状況をケースにてアップデートください。ケース以外で状況の変化を知ることができません。

▪️　緊急度を上げる場合は、緊急度を上げる理由を明確に説明ください。緊急度を上げる場合も、緊急度の基準にもとづき、技術的な要素にて考慮ください。また、緊急度を上げることで期待する内容、その内容を提供してほしい期限、その期限を設定している理由、これらも明確に説明ください。緊急度の変更方法は、「 緊急度の変更方法 」を参照ください。

▪️　緊急度1及び緊急度2を設定した場合、サポートエンジニアからのアップデートに対しても即時応答していただくことが求められます。高い緊急度を設定した後、数日間アップデートが行われないなど即時応答できない状態は避けてください。

緊急度の変更方法

CSPのメニューからSupport Casesを選択し、緊急度を変更するケースを開きます。右上にある「Manage Your Case」を選択すると、以下のページが表示されます。

表示されたページにて「CHANGE CASE SEVERITY」を選択し、必要事項の選択および入力を行います。「Reason for Case Update Request」に、「ケース登録後の注意事項」にある緊急度を変更する場合の注意事項に即して、理由などを英語で入力します。また、技術的な要素ではなくビジネス影響による緊急度の変更の場合、具体的なビジネス影響(例：機会損失/逸失利益の金額)を英語で入力します。

サポートケースでは対応できない課題

次の課題についてはサポートケースでは対応できません。課題としてケース登録していただいても、対応をお断りしますのでご注意ください。

▪️　設計や設定のコンサルテーション　　　*設定した内容が期待どおりの動作をしない場合の原因調査、解消方法の提供除く

▪️　カタログスペック以外の性能指標についての問い合わせ

▪️　報告書などサポートエンジニア規定以外の手段・方法での説明依頼

▪️　作業手順書の作成やレビューの依頼

▪️　社外秘に該当する情報の問い合わせ

▪️　サポートされていない構成における障害原因調査

▪️　作業立ち合いや作業時のリモートからの技術支援