JMPがクラッシュするという不運に見舞われたことがある方は、JMPにクラッシュファイルを送信するよう求めるプロンプトを目にしたことがあるでしょう。（補足：JMPテクニカルサポートと連携をご希望の場合は、クラッシュファイルを送信し、メールアドレスをお知らせください。）送信されたファイルは、世界中の社内テスターや顧客から送られてきたファイルと統合され、JMPクラッシュシステムに取り込まれます。JMP DevOpsチームは、お客様から報告されたJMPクラッシュファイルをJMP独自のソフトウェアで分析し、JMP開発チームと協力して、クラッシュのシグネチャと既知のバグとの関連性を特定します。
JMP やその他のツールを使用して JMP クラッシュを分析するプロセスについて概説します。新しいクラッシュ レポートを既知の問題と照合したり、さらに調査が必要な新しいケースとして特定したりすることは、現在では比較的簡単な作業となっています。しかし、原因不明の新しいクラッシュを解決するのは、それほど簡単なプロセスではありません。このポスターでは、クラッシュ レポートに詳細な情報を提供することで、より多くのクラッシュを解決するのにどのように役立つかを示し、それが JMP の開発プロセスにどのように役立つかを説明します。クラッシュの詳細に加えて、JMP 18 では、JMP 機能の使用状況に関する匿名テレメトリを送信することもできます。この情報は、お客様の使用パターン、ハードウェア、およびオペレーティングシステムの分布をよりよく理解するために使用されます。
皆さん、こんにちは。私の大好きなテーマの一つについて学ぶために、ポスターセッションにご参加いただきありがとうございます。私はJMP開発オペレーション担当ディレクターのシャノン・コナーズです。今日は、JMPの改善に役立つデータを生成・共有する方法についてお話ししたいと思います。
まず、私のDevOpsグループについて簡単に説明させてください。私たちは、JMPの機能開発、バグ修正、セキュリティリリースをサポートする計画、インフラストラクチャテスト、およびすべての本番環境タスクに関わっています。さまざまなリリースサイクルで、すべての機能をサポートしています。
さて、私の話はこれくらいにして、あなたのことを少しお話しましょう。もしあなたがこの録画ビデオをオンラインでご覧になっているなら、おそらく私と同じようにJMPを頻繁にご利用されている方でしょう。そうであれば、JMPから情報送信のお願いが表示されることがあることにお気づきかもしれません。このようなお願いが表示される主なケースは2つあります。1つ目は、JMPへのアクセス違反やソフトウェアのクラッシュが発生した場合です。2つ目は、JMPをインストールした際に、匿名での利用統計情報（テレメトリ）の送信をお願いされる場合です。私たちはあなたのプライバシーを尊重しているため、この情報の送信には同意をお願いしています。組織が既に設定していない限り、JMPの設定画面でプライバシー設定を行うことができます。
まず、クラッシュについてお話ししましょう。JMPのお客様は非常に創造的で、様々なデータソースや業界にアクセスされていることは周知の事実です。そのため、テストではこれまで確認されていないJMPのクラッシュが発生する可能性もあります。JMPにはクラッシュ検出機能が組み込まれており、ソフトウェアが動作しなくなった際に検出されます。そして、次回再起動時に、JMPは詳細情報の送信を促します。
長年にわたり、当社では、受信したクラッシュ情報を受信、保存し、既知の問題と照合する社内システムを構築してきました。このシステムにより、クラッシュが新規のもので詳細な調査が必要な場合、または既に認識していて修正プログラムのリリース時期や既に利用可能な修正プログラムの有無についてお客様にご案内できる場合を迅速に特定できます。また、このシステムは、お客様のクラッシュ情報を保存するだけでなく、サポートセンター、テクニカルサポート、テスター、その他当社で働く従業員によって発見された社内クラッシュに関するレポートも処理します。
では、この仕組みについて少し説明しましょう。JMP がシャットダウンしようとしていることを示す赤い X マークが表示されたダイアログが表示されることがあります。誰もがこのダイアログを見るのは嫌なものですが、必ず表示されます。 [OK] をクリックすると、JMP が再起動します。すると、JMP が予期せず終了し、テキストを追加するための空白のセクションが表示されます。表示されたウィンドウで、[レポートを匿名で送信] と [最近の問題を確認する] にチェックが入っていることに気づくでしょう。
まず最初に、ここで「キャンセル」をクリックしないでください。クリックしてしまうと、クラッシュしたことすら分からなくなってしまいます。このウィンドウを見て、JMPが私たちに何を送信しているのか不安に思うかもしれませんが、ご安心ください。JMPは、開いているテーブルスクリプトやその他の詳細情報を送信することはありません。JMPが送信するのは、ウィンドウの空白部分に入力したコメント、Windowsシステムに関する基本的なインストール情報とチェッカー情報（OSやインストールされているドライバやソフトウェアのリストなど）のみです。これらは、問題のトラブルシューティングに役立つ情報です。
最後に、JMPは、ソフトウェアが動作を停止した際にアクティブだったコードパスの詳細を示すクラッシュファイルを送信します。オペレーティングシステムやソフトウェア製品が生成する他のクラッシュファイルと同様に、これらのファイルは人間が読み取れるものではなく、特定の問題をデバッグする際の開発者にとってのみ役立ちます。
このウィンドウに表示されるデフォルト設定をそのまま受け入れて、「JMPにレポートを送信」をクリックしてクラッシュを匿名で送信すると、JMPはファイルを待機中のサーバーにアップロードします。匿名で送信すると、クラッシュはデータベースに追加されますが、クラッシュファイルだけでは問題を完全に診断して再現することはできない場合が多いことをご理解ください。開発者としてクラッシュをデバッグする場合、またはテスターとして弊社が行った修正を検証する場合、インタラクティブな操作やJSLスクリプトを使用して問題を再現することが、まさに理想的な方法です。
匿名チェックボックスのチェックを外し、メールアドレスをご入力いただくことを強くお勧めします。そうすることで、新しいテクニカルサポートケースを作成し、サポート担当者と直接問題解決に取り組むことができます。弊社のテクニカルサポートチームがお客様の問題を再現できるまで直接やり取りすることで、今後のバージョンで問題の理解と解決に繋がる可能性が最大限に高まります。
何をしたのか覚えていない場合や、担当者と相談する時間がなかった場合は、匿名で報告することも可能です。その場合は、JMPがクラッシュした際に何をしていたのか、覚えている限りの詳細をテキスト欄に記入してください。メールでテクニカルサポートに報告された場合でも、匿名で報告された場合でも、クラッシュを再現できれば、問題を追跡する新しいバグレポートを作成します。再現できない場合は、テストケースを作成するための新しい情報が届くまで、クラッシュ情報はシステムに残ります。
以前、JMPが動作を停止した際にどのような操作をしていたかの詳細をお知らせいただくようお願いしたクラッシュウィンドウについて、少しお話ししたいと思います。最初のスクリーンショットは、このクラッシュダイアログのデフォルト表示です。先ほど申し上げたように、メールアドレスも顧客情報も提供されていません。このクラッシュはデータベースに追加されますが、情報が一切ない匿名のクラッシュは、将来のバージョンで再現・解決される可能性が極めて低いため、最も役に立たない情報として分類しました。
2番目のウィンドウでは、お客様から匿名で報告がありましたが、クラッシュ発生前に実行した操作に関する非常に役立つコメントが添えられており、おかげで問題を再現することができました。しかし、メールアドレスが提供されていなかったため、クラッシュを再現できたこと、バグ報告として登録し、今後修正していく予定であることを伝えることができませんでした。
3番目のウィンドウは、匿名で投稿された例ですが、開発者が調査レポートを作成するのに十分な情報が提供されており、開発者はその問題を再現するJMPスクリプトを作成して、すぐに修正することができました。
最後のウィンドウは一例です。ある方がメールアドレスとスクリプトを提供してくれました。これは非常に役立ちます。なぜなら、そのスクリプトを複数のバージョンで実行することで、問題がいつ発生し始め、いつ停止したかを特定できるからです。誰もが問題を再現するためのスクリプトを作成する時間があるわけではないことは承知していますが、もし共有できるスクリプトをお持ちでしたら、問題解決に非常に役立ちます。
お客様からいただいたファイルの受け取り方と処理方法について、簡単にご説明させていただきます。基本的な流れとしては、クラッシュファイルがサーバーからダウンロードされます。次に、クラッシュスタックを処理する際に、ファイルにシンボルを追加します。これは、クラッシュスタックを処理するための技術的な用語です。その情報をデータベースにロードし、比較処理を行って「この新しいクラッシュは、これまで確認したどのクラッシュとも一致しない」と判断します。お客様からメールでご提供いただいた情報、または匿名および名前付きのクラッシュを調査するための社内ウェブページであるJMPクラッシュウェブページから、テクニカルサポート案件として情報を提供いたします。
テレメトリも非常に似たパイプラインを採用しています。テレメトリはすべて匿名で送信されるため、顧客とのやり取りは不要です。そのため、データを要約することができます。データをデータベースに格納し、要約した後、JMP Liveに公開します。プラットフォームの使用状況や機能の使用状況をより深く理解したい開発者は、データを直接ダウンロードし、開発者Evan McCorkle氏が作成したこのテレメトリアドインを使用して閲覧することができます。
興味深いことに、18を承認した顧客のうち約10%がテレメトリデータの共有を選択していることがわかりました。テレメトリデータはJMPのすべての使用状況を網羅しているわけではありませんが、顧客がソフトウェアで何をしようとしているのかを非常に的確に把握できており、今後のJMPのバージョンアップにおいて非常に役立つ情報となっています。
要約すると、JMPで発生した問題、例えばクラッシュレポートやsupport@jmp.comに直接メールで報告していただいたバグなど、どのような問題であっても、皆様からの情報提供は問題解決に非常に役立ちます。JMPで問題が発生した際にどのような操作をされていたかなど、詳細な情報をご提供いただけると大変助かります。いただいた情報は必ず確認し、テクニカルサポートチームが問題の再現に努めます。ベータ版ソフトウェアの場合は、テスターが問題の再現に取り組み、解決に向けて尽力いたします。
JMP 18では、テレメトリ情報の共有にご協力いただけるようになりました。この情報は、利用パターンや、ユーザーがソフトウェアやワークフローをどのように操作しているかを理解する上で非常に役立ちます。ぜひご参加ください。最後に、JMPの社内スタッフも実際にソフトウェアを活用して、JMPソフトウェアの改善に取り組んでいることを改めてお伝えしたいと思います。
私たちも皆さんと同様です。JMPを使い、JSLを使い、データベースと連携し、データをクリーンアップし、処理し、スクリプトを作成し、インタラクティブなグラフィックを作成してJMP Liveに結果を公開する方法を持っています。クラッシュパイプラインとテレメトリパイプラインの両方で私が本当に気に入っている点の1つは、まさにJMPを使ってJMPを改善しているということです。これは素晴らしいことだと思います。
私の講演をお聞きいただき、誠にありがとうございました。もしディスカバリー展にご参加される方は、ぜひ私のポスターセッションにお立ち寄りください。直接お話できることを楽しみにしております。ありがとうございました。
