アプリケーションに本番サポートを提供することは、ソフトウェア開発の最も困難な側面の1つです。 開発者 メンテナンスチームに割り当てられ、アプリケーションのバグのパッチに取り組んでいます。ただし、本番環境の停止が発生した場合に備えて、オンコールでも利用できます。その場合、アプリケーションをできるだけ早く軌道に戻すように機能します。
この記事は、本番環境でのバグを防ぎ、問題をより迅速に見つけることができるように、厳選された一連の推奨事項を提供することを目的としています。これらのアプリケーションを本番環境で処理することは複雑な作業です。多くの場合、利用可能なドキュメントがないか、アプリケーションがレガシーテクノロジースタックで記述されているか、またはその両方です。トレーニングセッションは非常に少なく、ほとんど知らないアプリケーションのサポートを提供するために呼び出されるのが一般的です。
多くの開発者は、本番環境でアプリケーションを処理した経験がありません。バグや停止を引き起こす本番環境で発生する一連の問題があり、通常、会社の収益が数千ドル、場合によっては数百万ドル失われます。さらに、開発者の大多数は環境にさらされていないため、いくつかの間違いを犯し続け、それがこれらの問題を引き起こします。このヒントのリストは、制作経験から教えることであなたの仕事の苦痛を軽減するはずです。
ソフトウェアを新しいサーバーにインストールするには、どのくらいの構成が必要ですか？以前は、チームに新しい開発者がいるたびに、これが完了するまでに3日かかることがありました。アプリケーションのインストールには、手動で実行する必要のある多くの手順が必要になります。時間の経過とともに、ソフトウェアはそれらの指示と互換性がなくなる新しいバージョンに進化します。もちろん、指示は通常更新されません。突然、アプリケーションを起動して実行するためだけに、必要以上の時間を費やしていることになります。
の出現で コンテナ化 、アプリケーションをすぐに起動して実行する方法を提供することがはるかに簡単になりました。構成は不要で、Dockerイメージは自己完結型であるため、問題が発生するリスクがはるかに低くなるという追加の利点があります。使用されているオペレーティングシステム、言語、フレームワークのバージョンが異なります。
同様に、開発者のセットアップを簡素化して、IDEのセットアップを含め、起動して実行するのにそれほど時間がかからないようにします。開発者は、30分以内にゼロからヒーローに移行できるはずです。
制作上の問題が発生した場合、最高の専門家が対応できない場合があり（休暇や病気など）、問題を投げかけた人に迅速に解決してもらいたい場合があります。
使用するテクノロジーが少ないほど、優れています。もちろん、仕事に適したツールを使用しなければならない場合もあります。ただし、「適切なツール」で過負荷にならないように注意してください。水を飲みすぎると、深刻な健康問題を引き起こす可能性があります。技術スタックに追加されたすべての新しい言語とフレームワークは、影響を慎重に考慮して、明確に定義された意思決定プロセスを通過する必要があります。
StringUtilsが必要だからといって、新しいフレームワークの依存関係を追加しないでください。クラス。依存関係の山が大きいと、ライブラリに互換性がなくなったり、フレームワーク自体または推移的な依存関係にセキュリティの脅威が見つかったりすると、人生が悲惨になる可能性があります。
さらに、スタックの複雑さが増すと、チームの新しい開発者を見つけてトレーニングすることが難しくなることを忘れないでください。人々は他の会社で新しい役割に移ります、そしてあなたは新しい役割を見つけなければなりません。エンジニアリングチームの売上高は、優れた特典やワークライフバランスの扱いが認められている企業でも非常に高くなっています。新しいチームメンバーをできるだけ早く見つけたいと考えています。テクノロジースタックの上に新しいテクノロジーが追加されるたびに、新しい候補者を見つける時間が長くなり、新入社員の費用がますます高くなる可能性があります。
ロギングはコメントと非常によく似ています。行われているすべての重要な決定に加えて、デバッグ手法で使用するすべての情報を文書化する必要があります。簡単ではありませんが、少しの経験があれば、生産停止の考えられるシナリオをいくつか計画し、少なくともそれを解決するために必要なログを記録することができます。もちろん、ログは、表示される問題の種類に応じて、コードベースとともに進化します。一般的に言えば、ログの80％を、コードの最も重要な20％、つまり最も使用される部分に置く必要があります。たとえば、重要な情報は、メソッドに渡された引数からの値、子クラスからの実行時型、およびソフトウェアによって行われた重要な決定です。つまり、ソフトウェアが岐路に立って、左または右のいずれかを選択したときです。
コードの前提が何であるかを非常に明確に計画します。特定の変数に常に値2、5、または7を含める必要がある場合は、intではなく列挙型であることを確認してください。大規模な生産停止の最大の原因は、特定の仮定が失敗した場合です。彼らは当然のことながらいくつかのことを考えているので、誰もが間違った場所で問題を探しています。
.hおよび.cppファイル
仮定は明示的に文書化する必要があり、それらの仮定に失敗した場合は、十分なアラームが発生するはずです。 生産サポート チームは状況をすばやく修正できます。データが無効な状態になるのを防ぐコード、または少なくともその場合に何らかのアラートを作成するコードも必要です。特定の情報を1つのレコードに保存する必要があり、突然2つのレコードが存在する場合は、警告を発する必要があります。
最も難しいステップの1つは、常にお客様が直面している問題を再現することです。多くの場合、問題の再現に95％の時間を費やし、問題を再現できるようになった瞬間に、パッチテスト、テスト、導入を数分で行うことができます。そのため、アプリケーションアーキテクトは、問題を非常にシンプルかつ迅速に再現できるようにする必要があります。これの多くは、顧客と同じ状況に到達するために、開発者が大量のアプリケーション構成を行う必要があるために発生します。顧客が置かれている状況を複雑にする多くのレコードが保存されています。問題は、開発者としてのあなたが顧客の行動を正確に推測しなければならないことです。そして時々、彼らは一連のステップを実行しましたが、そのうちの最後のステップだけを覚えています。
また、お客様はビジネス用語で問題を説明し、開発者はそれを技術用語に翻訳する必要があります。また、開発者がアプリケーションの経験が少ない場合は、不足している詳細をまだ知らないため、不足している詳細を尋ねることを知りません。本番データベース全体をマシンにコピーすることは不可能です。したがって、状況をシミュレートするために必要なわずかなレコードのみを本番データベースからすばやくインポートするツールが必要です。
顧客が[注文]画面に問題があるとします。いくつかの注文、顧客レコード、注文詳細レコード、注文構成レコードなどをインポートする必要がある場合があります。次に、それをDockerインスタンス内のデータベースにエクスポートし、そのインスタンスを起動すると、次のようになります。顧客が見ているのと同じものを見ています。もちろん、これはすべて、開発者が機密データにアクセスできないように適切な注意を払って行う必要があります。
Customer画面がある場合は、ブレークポイントを配置してその画面の問題をデバッグできるCustomerオブジェクトが必要です。時々、開発者は抽象化熱に陥り、ユーザーインターフェイスイベントを処理する方法についていくつかの信じられないほど賢い概念を思い付くことがあります。代わりに、常にKISSの原則（Keep it Simple、St- er、Silly）に依存し、UIイベントごとに1つの簡単に見つけられるメソッドを用意する必要があります。同様に、バッチ処理ジョブとスケジュールされたタスクの場合、場所のブレークポイントを見つけて、そのコードが機能しているかどうかを評価する簡単な方法が必要です。
理想的には、ドキュメントが失われないように、ソース管理システム内のREADMEファイルでこれを実行します。アプリケーションを正しく実行するために利用可能でなければならない外部システム、データベース、またはリソースを文書化します。また、これらのどれがオプションであるかをメモし、オプションで利用できない場合の処理方法に関する説明を追加します。
新しい機能を作成したり、システムのメンテナンスを提供したりする際にこれらの推奨事項に従うと、本番サポートがはるかに簡単になり、会社が費やす時間（および費用）が大幅に削減されます。すでにご存知のように、本番環境のバグやクラッシュのトラブルシューティングを行う際には時間が重要です。節約できる分は、収益に大きな違いをもたらします。ハッピーコーディング！
デバッグは、アプリケーションの動作を分析して、バグの根本原因を特定するプロセスです。
アプリケーションからバグを削除するため、デバッグと呼ばれます。
ログは、アプリケーションで発生したアクションを説明するテキストです。これらは、バグが発生する直前にアプリケーションが何をしたかを確認して、そのバグに関する追加情報を収集できるようにするために重要です。
業界標準、特に以下に説明するヒントの多くに注意してください。また、練習してください。たくさん。
