とらえどころのないバグ：すべてのテストとチェックを逃したバグ

比較的単純な製品でさえ、テストからうまく隠れてリリースに至るバグに遭遇することがあります。 また、アプリケーションが複雑になるほど、このようなバグが発生する可能性が高くなります。 何百万行ものコードを含む製品では、すべてのエラーをキャッチすることは一般的に不可能であり、次のバージョンまでにその数を最小限に抑えることができます。 そして、リリース後、そのようなバグは時々気づきます。 Parallelsのプロジェクトマネージャーである Alexander Grechishkinは 、忍者のバグをどのように探し、それをどのように処理するかを教えてくれました。

バグ忍者

500万人以上が当社の製品を使用しているため、これは私たちにとってデリケートな問題です。 そして、新しいバージョンがリリースされると、大多数のユーザーは1〜2週間以内にバージョンを切り替えます。 現時点では、ある種のバグがポップアップします。これはテスト中には検出されませんでしたが、ユーザーの間で頻繁に表示されます。



私たちは最近、報告システムがどのように働くかについて書きました 。 簡単に繰り返します。プログラムがクラッシュした場合、ユーザーはレポートの送信を求められます。 理由は異なる場合があります。たとえば、アクセスできないメモリまたは保護されたメモリへのアクセスです。 レポートは、ログ、アプリケーションに関する内部情報、コンピューター構成、システム環境などの一連のファイルです。 これらのレポート、プロセス、分析を収集し、統計レポートを生成する独立したシステムがあり、ほぼリアルタイムで更新されます。



このレポートでは、タイプごと、IPごとなどのさまざまな基準に従って、記録された障害事例をグループ化できます。 このレポートにより、現在の障害のダイナミクスを追跡し、悪い傾向をタイムリーに検出できます。 同時に、同じものを数え、すべてのテストを逃れて生産に入ったような忍者のバグをキャッチするのに役立ちます。

パーソナライズされたサービス

クラッシュが100人の異なるユーザーで1回発生した場合-これは悪いことです。 しかし、アプリケーションが1回に100回クラッシュすると、人にとって何らかの厄介なバグが発生する可能性が高くなり、何度もドロップしても製品に対するユーザーの信頼が高まることはないため、これは私たちにとって非常に悪いことです。 そのため、このような状況を監視し、できるだけ早く対応するよう努めています。



レポートを使用すると、独自のバグの原因をすばやく見つけて、人を助ける方法を見つけることができます。 ただし、一部の開発者がすぐに修正できる場合でも、製品の更新を非常に迅速にリリースすることはできません。 コードベースには数千万行のコードが含まれており、そのような製品をランダムにリリースすることはありません。 コード内の1文字だけを変更すると、製品が完全に機能しなくなるという事実にすでに気付きました。 したがって、修正を導入して再構築する場合は、利用可能なリソースに応じて、2日から1週間かかるすべての自動テストとリリースチェックリストを確認する必要があります。



それでは、独自のバグを表示する個々のユーザーをどのように迅速に支援できるでしょうか？ これを行うには、クラッシュレポートを送信するという形で、ユーザーのメールボックス用のフィールドを挿入し、「利用可能になったらソリューションを送信してください」にチェックを付けます。 製品を変更しなくてもバグを修正できる場合は、レポートでメールボックスを示したユーザーに指示を記載した手紙を書きます。 新しいリリースでクラッシュが修正され、ユーザーがまだ古いリリースを使用している場合、クラッシュを検出すると、更新する価値があることを知らせるメールを送信します。 多くの場合、ユーザーは単に製品の自動更新をオフにします。



たとえば、このようなバグがありました。一部のユーザーにとっては、クラッシュレポートを送信するシステムが落ちました。 面白い状況ですが、それでも。 その理由は、ログフォルダー内のファイルの数が多すぎるためです。 解決策は簡単でした。ログフォルダーに移動してすべてのファイルを削除するようにユーザーに書き込みます。 コードのこのバグをすぐに修正し、次のアップデートで大量に配布しました。



そして、ユーザーの視点からどのように見えるか想像してください。 彼のプログラムはクラッシュし、誓い、レポート送信ボタンを押し、数分後、Parallelsからの手紙に関する通知を受け取ります。「問題があることがわかりました。そのように解決できます。」 ほぼリアルタイムの個別サービス！ 数分以内に、機能しない問題の解決策を提案したという事実に感謝の手紙を書きました。

MacOSの怒り

多くの場合、クラッシュは製品のバグではなく、システム環境に関連しています。 奇妙なことに、Mac OS 10.11がリリースされる前は、クラッシュの主な原因はMac OS自体でした。 バージョン10.9では、いわゆるサイレントアップデート-サイレントアップデートが登場しました。 たとえば、あなたがコンピュータを離れて翌日に来て、彼が言った：「私はここにアップデートをインストールしたが、心配しないで、私は再開機能を持っている。」 つまり、更新プログラムをインストールする前に機能していたすべてのアプリケーションが再び起動されます。 そして、何も変わっていないようだ。同じサイトがSafariで開かれている、メールの不完全な手紙、メッセンジャーの通信。



Mac OSのバグが原因で、システムはアプリケーションの動作が完了するまでWindows Serverを強制終了しました。 重いアプリケーションがあり、稼働中の仮想システムを突くには時間がかかりますが、Mac OSは非常にゆっくりと反応し、 kill -9でそれを削減することを決定しました。 また、マルチプロセスシステム、2つのカーネルドライバー、仮想マシンプロセッサ、グラフィカルインターフェイス、および統合コンポーネントがあります。 Windowsでは、現時点で何かをダウンロードまたはインストールできます。 たとえば、更新が行われ、レジストリ内のエントリの質量が変更されましたが、決して無効にしないでください。 また、Mac OSは、Windows Serverを使用したサーバーよりも早くWindows Serverを停止するか、仮想マシンのスローダウンによりParallels Desktopを停止します。



当然のことながら、アプリケーションは大量に落ち始め、Mac OS自体が積極的にレポートを生成していました。 私たちのアプリケーションはシステムログをチェックし、これらの記録を見つけ、これらのレポートを私たちに転送したユーザーに正直に報告しました。 また、統計によると、4人に1人が「レポートを送信」ボタンをクリックするだけであることに注意する必要があります。 ですから、私たちにとっては単なる悪夢でした。 クラッシュメッセージでユーザーを混乱させないように、レポートシステムからクラッシュ署名を削除する必要さえありました。



結局、Appleにこのバグを修正するよう説得し、Mac OS 10.11からは気にしなくなりました。

すべてのドライバーが同じように役立つわけではありません。

環境が当社製品の動作に与える影響のもう1つの典型的な例は、 外国人ドライバーの転落です 。 特に、Linux（OpenGL）およびWindows（DirectXおよびOpenGL）で3Dをサポートしています。 また、nVidiaドライバーが非常に安定して動作する場合、Intelドライバーの場合、くしゃみをするのが一般的です。 そして、これは、アプリケーションのクラッシュ、OSの再起動、使用済みプログラムなど、最も嘆かわしい結果につながります。 当然、データが失われます。



たとえば、ある人がリソースを集中的に使用するプログラムを起動しました。 Mac OSでゲームを言う。 彼女は、メモリ、プロセッサ、ビデオカードを最大限に活用し始めます。 そして、3Dドライバーで行われていることは、これらの同じドライバーの作成者だけが知っています。 ユーザーがゲームをプレイしましたが、ドライバーはバッファーを解放せず、システムの設定を変更しませんでした。 その後、またはこの間、ユーザーが製品を起動します。これにはビデオカードからのリソースも必要です。結局、これはコンピューターエミュレーターです。 彼は積極的に3Dグラフィックスの使用を開始し、その結果、ビデオカードのMacドライバーのエラーが原因でクラッシュします。

BSOD forever

また、 Windows自体にも 、製品の安定性に影響を与える可能性のあるエラーがあることを忘れてはなりません。 たとえば、あなたは冷静に仕事をしていて、突然Windowsが再起動しました。 どうしたの？ そして、同じ転倒、例外、または存在しない記憶へのアピールが発生しました。 しかし、私たちのプログラムは静かに再起動することはできません。 彼女はユーザーに何かを伝える必要があります。 彼女はエラーを出します。 そして、これらのエラーを収集して分析します。









それらのほとんどは単一ですが、経験上、これらの問題はプログラムとは関係がなく、修正することはできないため、考慮していません。 さらに、ユーザーにはこのようなエラーは発生しなくなります。 まず、レポートで最も頻繁に繰り返されるバグに注意を払います。



テストベンチでは、ユーザー間のソフトウェア環境のばらつきが無限であるため、特定の要因の組み合わせを予測することはできませんでした。 主な難点は、製品内で外国のプログラムが開始されることです。 たとえば、 Parallels Desktopの内部では、Windowsが実行されますが、内部にはまだ多くのアプリケーションがあります。 そして、すべての組み合わせをテストでカバーすることは不可能です。



しかし、Windowsおよびサードパーティのプログラムにはバグもあります。 このような問題を分析するときは、まずそのようなプログラムを見つけて実際のコンピューターで実行し、実際にどのように機能するかを確認します。 しかし、残念なことに、当社の製品のユーザーは非常に具体的であり、率直に言って、フリーソフトウェアではないため、いくつかの制限が課されています。

予測不能なQt

クラッシュのもう1つの一般的な原因はQtフレームワークです。 製品の開発に使用します。 Linux、Windows、Mac用のParallels Desktopがあったため、これは歴史的に起こりました。そのため、開発フレームワークとしてQtを選択する必要がありました。 良い方法では、何かが機能する場合は、変更しないでください。 しかし、私たちはまだ進歩的な企業であり、高度な技術を使用したいと考えています。 したがって、常にQtを更新します。 バージョン3.0、3.2、4.0、4.2、4.5、4.8、5.2、5.5がありました。 しかし、実際のところ、Qtの場合、2桁目の変更はほとんどの場合災害です。 すべてのプログラムでこれがメジャーアップデートであり、3桁目が修正である場合、フレームワークではこれを変更の1桁目と比較できる場合があります。 つまり、5.0と5.5の違いは顕著です。 作成者はクラス全体を削除し、膨大な数のコンポーネントをリファクタリングし、新しいAPIに切り替えます。 しかし、新しいコードはエラーなしでは発生しません。 また、Qtが原因で製品が落ちるという事実に定期的に直面しています。



ある時点で、我慢が止まりました。 Qtソースコード全体をリポジトリにアップロードし、メイントランクに導入せずにローカルパッチの作成を開始しました。 そのうち約250個を取得し、非効率性やコード操作の誤りによるかなり深刻な問題を解決しました。 そして最近、次のバージョンに切り替えて、すでにQtトランクにパッチを作成し始めました。



フレームワークのコードがどのように影響するかの簡単な例。 ユーザーのコンピューターの状況によっては、アプリケーションが恥知らずに遅くなりました。 すべてがうまくいきました。 製品を構築するときに、Qtネットワークコンポーネントが使用されることが判明しました。 使用していませんが、ライブラリにあります。 そして、これは何らかの形でフレームワーク全体の作業に影響します。 彼がそれを捨てるとすぐに、ブレーキはすぐに消えた。



最後に、面白い出来事を思い出しました。 レポートの分析中に、1つのアプリケーションが絶えずアプリケーションをクラッシュさせていることに気付きました。 そして、それは海賊であり、曲がって壊れているからです。 彼らは手紙を書きました。「ごめんなさい、私たちはParallelsからです。 私たちは助けたいです。 あなたの製品は完全に正直ではなく、落ちています！」 少女は謝罪し、アプリケーションは友人によってインストールされ、10分後に購入代金を支払ったと言いました。 それ以来、彼女からの単一の問題報告はありませんでした。