ツールとしての直観
直感を開発ツールとして（そして実際にツールとして）考えると、実際には、ツール自体を持っていることに加えて、このツールのスキルを持っていることもいいことがすぐに明らかになります。 この場合のスキルは、システムの開発/デバッグ/統合における個人的な経験になります。 経験が多ければ多いほど、起こりうる問題に対する「本能」が発達しました。 視野が広くなればなるほど、使用するシステム、その環境、および環境とそれが作用する鉄との相互作用の方法について深く知るほど、鉄から製品までの垂直集積回路全体を理解し、実現することが容易になります。 明確にするために、いくつかの例を示します。
例1：自己損傷アーカイブ
データが破損しているというメッセージをほとんど受け取らないことを想像してください。 多くのクライアントが存在し、条件は誰でも異なりますが、アーカイブコピーの復元が拒否されたことを通知する場合があります。 もちろん、「曲がった」ソフトウェア、「曲がった」手、そして一般的にすべてを責めます。 コードのテストを開始し、アーカイブの作成を確認します-すべてが順調です。 10人がリストを見て、問題はありません。 アーカイブを作成するデータ形式と方法には、障害に対するチェックと保護が含まれます。つまり、理論上、問題は製品にありません。 （注：アーカイブを作成するとき、リードソロモンコードが使用され、Amazon S3（200％の冗長性がある）と同じ信頼性で40％の冗長性のみを使用できます。これについては、次のいずれかの記事で説明します。 私たちのブログで 、購読し、間違いなく何も見逃さないでください！）
実際には問題があり、解決する必要があります。 製品を知ることは、バグを見つけるのに役立ちました。 事実、アーカイブの機能はメタデータの2つのコピーの作成であるということです。私は、それらが収束するかどうかを比較して確認することを提案しました。 同意しません。 彼らは掘り始めました-16進エディタで開いたときのコピーの1つで、明らかなパターンが見つかりました-64バイトのデータごとに16バイトの「デジタルガベージ」で共有されました。 このような「パターン」は、ファイルシステムとデータがサーバーに保存される方法と明確に相関しています。 環境の知識と製品の知識により、直観的なアプローチを使用して問題を見つけ、特定し、排除することができました。
広い視野->幅広い経験->エラーのクイック検索
前の例でわかるように、データの保存方法を知らなくても、非常に長い間エラーを探すことができました。 通常、優れた開発者はまずコードで問題を探しますが、デバッグの問題の1つは、開発者がデバッグの「サイクル」から抜け出すことが困難な場合があることです。洗練された条件下でデータ、アルゴリズム、結果を再チェックしても、「間違った」答えは生成されません。開発者はテストを再度開始するか、ソースに突入し、何も見つからないなど、稼働日が終わるまで続きます。 切り替えて自分の責任範囲を超えることができるようにすることは非常に重要です：エラーは必ずしもコード、ランタイム環境自体、およびすべてが回転しているハードウェア環境にあるとは限らず、それらを除外することはできません。 そして、この問題については、別の良い例があります。
例2：クライアントは操作の結果を待つことができず、エラーでクラッシュします
状況は次のとおりです。プログラムは長時間動作し、すべてが正常です。 リクエスト、回答、計算、結果-問題はなく、どこにも落ちません。送信データは期待どおりに見え、受信データは正しく処理されます。 しばらくすると、次のエラーが表示されるようになりました。クライアントは約1分間ダムであり、サーバーからの応答を待たずにエラーを返しました。 開発者は集中的に羊毛のように見えますが、完全に機能するコードであり、それまでは1日、2日、10日の間、問題なく機能していました。 ログの確認、読み取り、表示は結果をもたらしません。 悪循環のデバッグを終了しても終了しません。 ある時点で、彼らは問題をより広く見て、すべてのイベントを追跡し、エラーが発生し始める前にサーバー応答の履歴がどのように変化したかを見ることにしました。 ある瞬間から、応答時間がほぼ直線的に伸び始め、不幸な分に達することに気付きました。 SSHを調べて、強制的にインデックスを作成しました-うまくいきました。 振り返ってみると、ソリューションは明白でシンプルに見えますが、開発者がデバッグでループを終了し、内部ではなくシステムの側面から問題を調べることは困難でした。
例3：バックアップ後の非回復マシン
ここに最近の興味深い話があります。アクロニスでは、いつものように、以前の経験を考慮して、常に何かを改造して改善し、さらにはゼロから開発します。 この特定の例では、開発者は新しいタイプのアーカイブに取り組み、ディスクバックアップを実行します。ディスクバックアップは、Acronis Cloud Storageの一部になります（または、すでに作成されています）。 コードが作成され、チェックされ、バトルトライアルの時が来ました。 データをダウンロードし、バックアップを作成してクラウドに送信し、コンピューターの復元を試みました。 結果を確認します：一部-それは動作します、一部-いいえ、コンピュータは起動しません。 退屈な一連のデバッグ、ロギング、自動および手動モードでのエラーチェック、完全な回復のためのファイルシステムの直接確認-すべてが正常に行われ、ボリュームがマウントされ、すべてのファイルが読み取られます。 修正されたいくつかの小さなものを見つけましたが、コンピューターが起動しないという事実には影響しませんでした。 合計で、彼らはアンロードの理由をつかもうと、眠れない夜を数回過ごしました（そして、繰り返しますが、いくつかのコンピューターだけがロードされませんでした）。 一般に、開発者は終了することなくデバッグサイクルに入りました。 偶然にも、彼らはmftが断片化されている（約1.5万個のパーツを持っている）という事実に注目しました。 即座に、ブートローダーにはそのような情報の配列を処理するための何かが欠けているという考えが生まれました。 コードに入り、ファイルシステムパーサーを最適化し、いくつかのストロークを修正すると、問題はすぐに消えました。 この特定のケースでは、可能性のあるすべての些細な事に対する平凡な注意がデバッグループから推測されました。 また、振り返ってみると、解決策はシンプルで明白なように見えます。開発時には、断片化とパーサーをチェックするという考えは洞察に似ていて、Developer Graceを突然落としました。
結論の代わりに
製品を知り、コードを知り、周囲を知る。 バグをキャッチするのと同じ方法でハングアップしないでください。
プログラムとアルゴリズムだけでなく、その実行に関連するすべてのものもチェックしてください：関連製品、OSからの応答、ハードウェアやサーバーからの応答。 広く見て、深く見て、直観が問題の発見に役立ち、そしてもちろん、あなたの良い製品は顧客やユーザーにより近くなります。 ご清聴ありがとうございました。