テクニカルサポートから的確な答えを引き出すための技術（初回チケット起票編）#テクニカルサポート #サポートエンジニア

はじめに

MongoDBテクニカルサポート担当の山森です。

クリエーションラインでは、MongoDBの他にGitLab、Docker(Mirantis)、Neo4jのテクニカルサポートを提供しています。これらのサポート要員は、2023年10月からSEAiCという同じチーム内で働いています。

なぜこれを書こうと思ったか

SEAiCでは、チーム発足時から、困ったチケットやうまく対応出来たチケットを共有する会を毎朝開催しています。共有する会を始めてから5か月近く経ちますが、どのソフトウェア製品でも対応に困ったチケットは共通している点が多いことに気づきました。

今回の記事では、チケット起票時にはこのような情報を書いて欲しいな、という点をまとめました。

チケットを起票するときのポイント

チケットを起票するとき、多かれ少なかれ「早く解決してほしい」という思いがあるはずです。解決までのスピードは、初回起票時にどれだけ情報が正確に、漏れなく書かれているかにかかっています。

初回起票時に内容が不足していると、テクニカルサポートがお客様の抱えている問題を明確に把握できず、何往復ものやり取りが発生します。これで、解決までに時間がかかってしまうチケットが非常に多いです。

初回起票時に気を付けて欲しいポイントは以下の２つです。

1.適切な影響度と優先度を設定する

クリエーションラインでは、テクニカルサポートとのやり取りで「Zendesk」というSaaSを使用しています。起票時に「影響度」と「優先度」の2つを設定することができます。

影響度は、重大、大、中、小の4段階に設定することができます。これは、「お客様の業務にどれだけ影響が出ているか」の指標です。以下はMongoDBの指標ですが、他の製品でも大きく変わりはありません。

• 重大：製品を使用しているシステムに障害が発生し、業務に多大な影響が出ている。または、障害によって重要なデータが損失した。回避策がない。
• 大：製品を使用しているシステムに障害が発生し、業務の一部に影響が出ている。回避策がなく障害が継続している。
• 中：製品を使用しているシステムに障害が発生しているが、回避策があり、縮退で動作している。
• 小：上位影響度に該当しない一般的なエラーメッセージ、一般的な質問、オペレーションに関する相談や質問

勘違いされることが多いのですが、影響度を上げても、テクニカルサポートが緊急性が低いと判断した場合は、着手や解決までのスピードは変わりません。件名に「緊急」とついていたり、「今日中に返答をください」と記載があっても、影響度がひき上がることはありません。

優先度に関しては、判断が難しいのですが、「今の段階では緊急度が低いが、時間経過により緊急度があがるもの」に関して「高」を付けていただければと思います。影響度の時と同じですが、ここを「高」にしても、返答スピードは変わりません。

緊急度は災害時のトリアージと似ています。

大量に出血していたり、意識がなかったり、放っておくと命の危険がある患者がいれば、当然緊急度は高くなり、「死なないための措置」をします。

骨折している患者はどうでしょうか。命の危険はないものとします。そうなると、相対的に緊急度が低くなります。骨折している患者本人は直ちに措置をしてほしいと思うでしょうが、救急医は緊急度が高い患者の後に、骨折している患者にギブスなどの措置をするかと思います。

このように、緊急度は「対応するスピード」だけでなく、「措置の内容」が変わってくると考えていただきたいです。

2.発生した事象と困っていることをセットで伝える

ここで重要なのは、発生した事象と困っていること（最終的にどうなってほしいか）を必ずセットで伝えてほしいということです。発生した事象だけを伝えられても、テクニカルサポートは「何を持って解決とするか」が分かりません。

反対に、困っていることだけを伝えられても、発生した事象を把握できないと、どうやって解決に導けばいいのか分かりません。

タイトル　：エラーが出ています
緊急度　　：最高
内容　　　：MongoDBでこのようなエラーが出ました。どうしたらいいですか？
（エラーメッセージのスクリーンショット）

タイトル：mongoDBにつながりません
緊急度：最高
内容：本番のmongoDBにつながらなくなりました。業務に影響が出ています。至急連絡ください。電話番号 xxx-xxxx-xxx

テクニカルサポートは「どこの環境にある、どんなバージョンのmongoDBなのかな？どこのPCから、どのクライアントツールを使ってつなごうとしているのかな？いつからつながらないのかな？障害の前に、何か作業があったのかな？どんなエラーが出ているか分からないから、エラーログがないとなんともいえないなあ・・・。」と思います。

助かるチケットの例：

タイトル：mongoshからMongoDBに接続できなくなりました
緊急度：中
内容：普段のオペレーションは保守用PCからmongoshでMongoDB Serverに接続していますが、本日15時過ぎから以下のエラーメッセージが出て、接続できなくなりました。
（エラーメッセージの内容）
アプリは問題なく動いていますので、システムへの支障は出ていませんが、本日予定していた定期保守作業ができませんので、早めに解消したいです。

ポイントまとめ

• 緊急度、優先度は適切に設定する
• 「発生した事象」と「困っていること（最終的にどうなってほしいか）」はセットで伝える

次は、発生した事象と困っていることを伝えるコツについて、それぞれまとめていきます。

発生した事象を正確に伝えるコツ

発生した事象は、正確に伝える必要があります。我々テクニカルサポートは、お客様の環境やユースケース、事象が発生した時のことを知りません。実際にとなりで見ていたわけではないからです。

テクニカルサポートは自身が持ち合わせている知識や経験で全て解決すると思われがちですが、そのほかにもソフトウェア製品のドキュメントやナレッジ、開発元へのエスカレーションといった武器を使って解決します。なので、正確に事象を把握できないと何をキーワードに調査を進めればいいか分からなくなってしまいます。

製品によって差はありますが、一般的には以下の情報を添付してもらえると助かります。

1.問題が発生した際の5W1H

• いつ発生したのか？（When）
  • 例：バージョンアップの作業時、バージョンアップ実施のコマンド押下した後に発生。
• なぜ発生したのか？（Why）
  • →ここは調査を進めていくうえで判明していくため空欄でOK
• なにで問題が起きたのか？（What）
  • 例：ECサイトののバックエンドで使用しているMongoDB Serverで発生。
• どこで問題が起きたのか？（Where）
  • 例：保守要員のPCでssh接続　※Whatと共通の時もあります。
• どのような問題が起きたのか？（How）
  • 例：「xxxxxxxx」というエラーが出て、MongoDB Serverが起動しなくなった。

オペレーション時に事象が発生した場合は、事象発生時に何をしていたか（どんなコマンドを実行したか、実行結果も合わせて）も、あわせて教えてくれると、助かります。

2.システムから採取できる情報

• 事象発生時のログ
  • ソフトウェア製品固有のログ、ＯＳのシステムログ

これは事象発生時の裏付けにもなります。ある程度調査を進めて「このような障害が発生した」と断定してお問合せをいただくお客様もいらっしゃるのですが、調査を進めていくと、実は原因が違うところにありました、というケースも珍しくありません。

• 使用している環境に関する情報
  • ソフトウェア製品のバージョン情報
    • 対象製品のエディション違い（コミュニティ版とエンタープライズ版、SaaS版とセルフホスト版など）
    • OSのバージョン情報
    • プラットフォームに関する情報（オンプレミス or VM or コンテナ,RAMやHDDの搭載量）
• 診断ファイル（製品ごとに固有）

セルフホステッド（自前のオンプレミスサーバーやVMで動くソフトウェア）だと、製品ごとに固有に診断ファイルを用意しているパターンが多いです。ソフトウェア製品の開発元にエスカレーションする場合はたいていこれを求められるので、必要な場合はテクニカルサポートからお客様に取得・送付してもらうように案内します。

また、使用している環境やプラットフォームに関する情報は、対象製品をインストールしているサーバのみに限定しません。ユーザとサーバの間の環境が原因でトラブルが起こることもよくあります。以下がよくある例です。

• サーバー製品と利用者端末との間にリバースプロキシーが入っている
  • リバースプロキシーがURLを書き換えるルールに誤りがある
  • サーバー製品がURL書き換えに対応していない
  • リバースプロキシーが動作していない
• サーバー製品の認証に外部のシステム/サービスを使っている(OIDC、SAML、LDAP等)
  • サーバー製品側の設定が誤っている
  • 外部認証システム/サービスが動作していない
  • サーバー製品と外部認証システム/サービスとの間の通信異常

困っていること（最終的にどうなってほしいか）を明確に伝えるコツ

「何に困っているのか（最終的にどうなってほしいか）」が明確でないケースは多いです。

例えば以下のような書き方だと、テクニカルサポートは最終的にどこに着地させれば良いか分からないので、困ってしまいます。

着地地点に困るチケットの例

タイトル：教えてください
（エラーログのスクリーンショット）
作業後、こんなログが出ました。対応方法を教えてください。

テクニカルサポートは「この人はどんな作業をしていてこの状況になったのかな？最終的にはどうしたいのかな？」と思います。

助かるチケットの例

タイトル：バージョンアップ作業後起動しなくなりました。

以下の構成でMongoDBを使用しています。
バージョン：MongoDB Server 4.4 -> 6.0.6
構成：P1S2　PとSはスペックが同じです。
※Primary 1台、Secondary 2台
OS:RHEL 8.1
プラットフォーム：VMware上のVM
RAM：16GB
HDD：60GB

（エラーログのスクリーンショット）

4.4から6.0.6へのバージョンアップ作業中、以下のエラーが出て以後の作業ができなくなってしまいました。MongoDBも起動しません。

エラー時の実行コマンドと実行結果は以下の通りです。
（実行コマンドと実行結果）

MongoDBを起動できないエラーは以下の通りです。
（エラーログ）

最終的にはバージョンアップを完了したいのですが、どのようにすれば良いでしょうか？
一旦切り戻した方が良いでしょうか？バージョンアップ前にmongodumpは取得済みです。

このようなチケットであれば、発生した事象が明確に伝えられていますし、バージョンアップを完了したいことが明確に分かりますので、調査が進めやすくなります。

本題から逸れる問い合わせをついでに質問しないことも大事です。

これは小さな子供が「どうして空は青いの？」「どうして水は冷たいの？」「どうして…」というふうに、質問を次々に繰り出すのと似ています。質問には出来るだけ回答してあげたい気持ちはあるものの、「夕飯急いで作っているタイミングで、それ聞く？」という内容を、矢継ぎ早に聞かれると困ってしまいますね。（きっと育児あるある）

テクニカルサポートエンジニアの時間は有限です。テクニカルサポートは契約時にけっして安くないお金をいただいていますし、出来るだけ活用して欲しい気持ちはあるのですが、あれもこれも聞かれてしまうと、回答までに時間がかかってしまいます。

ひとつのチケットで複数の質問を記載いただいても構いませんが、サポートエンジニアが本題から逸れると判断した場合は、問題解決に注力するためにチケットを分けるように促すことがあります。

また、チケットを分けると基本的には違う人間がアサインされるため、単純に解決までのスピードが速くなります。

さいごに

ダメな例ばかりをあげてしまったので、「もしかしたら自分のお問い合わせはダメなのかもしれない」と思われる方もいるかもしれませんが、我々テクニカルサポートは、お客様の問題を解決するためにいますので、躊躇せずどんどん起票して欲しいです。

実は製品に関係ないところに問題があった。というケースもよくありますが、基本的に問い合わせてもらって問題ありません。

MongoDBを担当している私が経験しているパターンだと、MongoDBに関するお問合せが、ふたを開けてみるとOSに関するものだったということも少なくありません。

私自身もサーバの運用経験がありますし、経験がない事象があれば手元で検証したり、MongoDBにエスカレーションしたりしますので、気にせずにどんどん問い合わせてください。

問い合わせに関するガイドラインは、サービスプロバイダが独自に出しているところもあります。例えば、Amazon Web Serviceが出しているものはかなりよくまとまっていて、他のサービスにも共通する内容ですので、紹介しておきます。

参考：技術的なお問い合わせに関するガイドライン

サポートへの問い合わせ全般で書くつもりでしたが、今回は思ったよりネタが多くなってしまったので、「初回チケット起票編」としました。またネタが溜まったら追加で書くつもりです。

※蛇足・・・アイキャッチ画像は、筆者が最近ダンジョン飯にはまっているため、「ダンジョンを攻略する時のサポート契約があったら面白いな」と思って、描いてみたのですが、普通にスマホでナビを使っている絵になってしまいました。