本番環境でのトラブルシューティングを高速化するための7つのデバッグ手法

公開: 2022-03-11

アプリケーションに本番サポートを提供することは、ソフトウェア開発の最も困難な側面の1つです。開発者はメンテナンスチームに割り当てられ、アプリケーションのバグにパッチを適用する作業を行います。ただし、本番環境の停止が発生した場合に備えて、オンコールでも利用できます。その場合、アプリケーションを可能な限り迅速に軌道に戻すように機能します。

この記事は、本番環境でのバグを防ぎ、問題をより迅速に見つけることができるように、厳選された一連の推奨事項を提供することを目的としています。これらのアプリケーションを本番環境で処理することは複雑な作業です。多くの場合、利用可能なドキュメントがないか、アプリケーションがレガシーテクノロジースタックで作成されているか、またはその両方です。トレーニングセッションは非常に少なく、ほとんど知らないアプリケーションのサポートを提供するために呼び出されるのが一般的です。

多くの開発者は、本番環境でアプリケーションを処理した経験がありません。バグや停止を引き起こす本番環境で発生する一連の問題があり、通常、会社の収益が数千ドル、場合によっては数百万ドル失われます。さらに、開発者の大多数は環境にさらされていないため、いくつかの間違いを犯し続け、それがこれらの問題を引き起こします。このヒントのリストは、制作経験から教えることで、仕事の苦痛を軽減するはずです。

ヒント1：アプリケーションの実行に必要なすべての構成を削除または自動化します。

ソフトウェアを新しいサーバーにインストールするには、どのくらいの構成が必要ですか？以前は、チームに新しい開発者がいるたびに、これが完了するまでに3日かかることがありました。アプリケーションをインストールするには、手動で実行する必要のある多くの手順が必要になります。時間の経過とともに、ソフトウェアはそれらの命令と互換性がなくなる新しいバージョンに進化します。もちろん、命令は通常更新されません。突然、アプリケーションを起動して実行するためだけに、必要以上に多くの時間を費やしていることになります。

コンテナ化の出現により、アプリケーションをすぐに起動して実行する方法を提供することがはるかに簡単になりました。構成は不要であり、Dockerイメージは自己完結型であるため、実行回数がはるかに少なくなるという追加の利点があります。使用されているオペレーティングシステム、言語、フレームワークのさまざまなバージョンで問題が発生するリスク。

同様に、開発者のセットアップを簡素化して、IDEのセットアップを含め、起動して実行するのにそれほど時間がかからないようにします。開発者は、30分以内にゼロからヒーローに移行できるはずです。

制作上の問題が発生した場合、最高の専門家がいない場合（休暇や病気など）、問題を投げかけた人が誰でも迅速に解決できるようにしたい場合があります。

ヒント2：ハイテクスタックのスープトラップに陥らないでください。

使用するテクノロジーが少ないほど、優れています。もちろん、場合によっては、作業に適したツールを使用する必要があります。ただし、「適切なツール」で過負荷にならないように注意してください。水を飲みすぎると、深刻な健康問題を引き起こす可能性があります。技術スタックに追加されたすべての新しい言語とフレームワークは、影響を慎重に考慮して、明確に定義された意思決定プロセスを通過する必要があります。

StringUtilsクラスが必要であるという理由だけで、新しいフレームワーク依存関係を追加しないでください。
ファイルを移動するための簡単なスクリプトを作成する必要があるという理由だけで、まったく新しい言語を追加しないでください。

依存関係の山が大きいと、ライブラリに互換性がなくなったり、フレームワーク自体または推移的な依存関係にセキュリティの脅威が見つかったりすると、人生が悲惨になる可能性があります。

さらに、スタックの複雑さが増すと、チームの新しい開発者を見つけてトレーニングすることが難しくなることを忘れないでください。人々は他の会社で新しい役割に移ります、そしてあなたは新しいものを見つけなければなりません。エンジニアリングチームの離職率は非常に高く、優れた特典やワークライフバランスの扱いが認められている企業でも同様です。新しいチームメンバーをできるだけ早く見つけたいと考えています。テクノロジースタックの上に新しいテクノロジーが追加されるたびに、新しい候補者を見つける時間が長くなり、新入社員の費用がますます高くなる可能性があります。

ヒント3：ロギングは、問題を見つけるためにガイドする必要があります。無駄な詳細に溺れることはありません。

ロギングはコメントと非常によく似ています。行われているすべての重要な決定に加えて、デバッグ手法で使用するすべての情報を文書化する必要があります。単純ではありませんが、少しの経験があれば、生産停止の考えられるシナリオをいくつか計画し、少なくともそれを解決するために必要なログを記録することができます。もちろん、ログは、表示される問題の種類に応じて、コードベースとともに進化します。一般的に言えば、ログの80％を、コードの最も重要な20％、つまり最も使用される部分に配置する必要があります。たとえば、重要な情報は、メソッドに渡された引数からの値、子クラスからのランタイムタイプ、およびソフトウェアによって行われた重要な決定です。つまり、ソフトウェアが岐路に立って、左または右のいずれかを選択したときです。

ヒント4：予期しない状況に対処します。

コードの前提が何であるかを非常に明確に計画します。特定の変数に常に値2、5、または7を含める必要がある場合は、intではなく列挙型であることを確認してください。大規模な生産停止の最大の原因は、特定の仮定が失敗した場合です。彼らは当然のこととしていくつかのことを考えているので、誰もが間違った場所で問題を探しています。

仮定は明示的に文書化する必要があり、それらの仮定に失敗した場合は、本番サポートチームが状況を迅速に修正できるように十分なアラームを発生させる必要があります。データが無効な状態になるのを防ぐためのコード、または少なくともその場合に何らかのアラートを作成するためのコードも必要です。特定の情報を1つのレコードに保存する必要があり、突然2つのレコードが存在する場合は、警告が発生する必要があります。

ヒント5：顧客に起こっている問題を再現するのは簡単なはずです。

最も難しいステップの1つは、常にお客様が直面している問題を再現することです。多くの場合、問題の再現に95％の時間を費やし、問題を再現できるようになった瞬間に、パッチテスト、テスト、および展開を数分で行うことができます。そのため、アプリケーションアーキテクトは、問題を非常にシンプルかつ迅速に再現できることを確認する必要があります。これの多くは、顧客がいるのと同じ状況に到達するために、開発者が大量のアプリケーション構成を行わなければならないために発生します。顧客が置かれている状況を複雑にする多くのレコードが保存されています。問題は、開発者としてのあなたが顧客が何をしたかを正確に推測する必要があることです。そして時々、彼らは一連のステップを実行しましたが、そのうちの最後のステップだけを覚えています。

また、お客様はビジネス用語で問題を説明し、開発者はそれを技術用語に翻訳する必要があります。また、開発者がアプリケーションの経験が少ない場合は、不足している詳細をまだ知らないため、不足している詳細を尋ねることはできません。本番データベース全体をマシンにコピーすることは不可能です。したがって、状況をシミュレートするために必要なわずかなレコードのみを本番データベースからすばやくインポートするツールが必要です。

顧客が[注文]画面に問題があるとします。注文のいくつか、顧客レコード、注文詳細レコード、注文構成レコードなどをインポートする必要がある場合があります。次に、それをDockerインスタンス内のデータベースにエクスポートし、そのインスタンスを起動すると、次のようになります。顧客が見ているのと同じものを見ています。もちろん、これらすべては、開発者が機密データにアクセスできないように適切な注意を払って実行する必要があります。

ヒント6：アプリケーションのどこにブレークポイントを配置するかは明らかです。

Customer画面がある場合は、ブレークポイントを配置してその画面の問題をデバッグできるCustomerオブジェクトが必要です。時々、開発者は抽象化熱に陥り、ユーザーインターフェイスイベントを処理する方法についていくつかの信じられないほど賢い概念を思い付くことがあります。代わりに、常にKISSの原則（Keep it Simple、St-er、Silly）に依存し、UIイベントごとに1つの簡単に検索できるメソッドを用意する必要があります。同様に、バッチ処理ジョブとスケジュールされたタスクの場合、場所のブレークポイントを見つけて、そのコードが機能しているかどうかを評価する簡単な方法が必要です。

ヒント7：すべての外部依存関係が明示的に文書化されていることを確認してください。

理想的には、ドキュメントが失われないように、ソース管理システム内のREADMEファイルでこれを実行します。アプリケーションを正しく実行するために利用可能でなければならない外部システム、データベース、またはリソースを文書化します。また、これらのどれがオプションであるかをメモし、オプションで利用できない場合の処理方法に関する説明を追加します。

デバッグ技術を超えて

新しい機能を作成したり、システムのメンテナンスを提供したりする際にこれらの推奨事項に従うと、本番サポートがはるかに簡単になり、会社が費やす時間（および費用）が大幅に削減されます。すでにご存知のように、本番環境のバグやクラッシュのトラブルシューティングを行う際には時間が重要です。節約できる時間は、収益に大きな違いをもたらします。ハッピーコーディング！