おっと。何かが機能していません。デジタル製品ストアのオーナーとして、それを修正するプレッシャーはすべてあなたにかかっています。どうしますか？
ウェブサイトがダウンするのは楽しいことではありませんが、デジタルストアでは、収益、顧客の満足度、ブランドの評判が危機に瀕しています。良いニュースは、そもそもサイトクラッシュのリスクを軽減するために講じることができる予防策と、最悪の事態が発生した場合に講じるべき手順があるということです。
今週の The EDDit では、デジタル製品サイトがダウンした場合の対処法について説明します。これにより、より自信を持って、それに対処する準備ができるようになります！
問題が発生していることを確認する
より集中的なトラブルシューティングモードに入る前に、問題が発生していることを確認することが重要です。時折、実際には他の要因が関係しているにもかかわらず、サイトが「ダウンしている」という報告を受けることがあります。
状況を評価するために、次の質問をしてください。
- 自分のデバイスからサイトは正常に読み込まれますか？デスクトップ版とモバイル版を確認してください。Uptrends のウェブサイト可用性テスト、Where’s it Up、Down for Everyone, or Just Me? などのツールを使用して、世界のさまざまな地域でサイトがどのように読み込まれているかを確認することもできます。
- ユーザーのデバイスに問題がありますか？この場合、必ずしも多くのことはできません。
- 使用中のブラウザに問題がありますか？複数のブラウザでサイトを読み込んで確認してください。
- ユーザーは安定したインターネット接続を持っていますか？他のサイトには問題なくアクセスできますか？
- ユーザーはサイトのキャッシュされたバージョンを見ていますか？ハードリフレッシュを実行するとキャッシュがクリアされ、ブラウザはページの最新バージョンを強制的に読み込みます。これは次のように行うことができます
ユーザー、ブラウザ、接続性、キャッシュの問題をすべて除外したら、さらにトラブルシューティングを進めたいと思うでしょう。
問題の原因を特定する
HTTP エラーを知る
最新のブラウザは、リクエストが単純に失敗した場合に少し詳細を伝えようとしますが、デバッグプロセスを開始する前に、HTTP ステータスコードの意味とそれらがどのようにグループ化されているかを知ることも重要です。
特に、4XX または 5XX エラーが発生している場合は、問題を正確に評価（および対処）したい場合、その意味を理解することが重要です。
4XX クライアントエラー
これらのエラーはユーザーのブラウザによって引き起こされます。最も一般的な 4XX エラーは次のとおりです。
- 404 Not Found。この場合、ユーザーが要求したリソースはサーバーに見つかりませんでした。
- 403 Forbidden。 これは権限に基づくエラーであり、クライアント（ブラウザユーザー）がリソースにアクセスするための十分な権限を持っていないことを意味します。リソースに認証が必要な場合や、サーバー上のファイルに誤った権限が割り当てられている場合などが考えられます。
4XXエラーについてさらに詳しく知りたい場合は、Wikipediaのリストをこちらで参照してください。
5XXサーバーエラー
4XXエラーとは異なり、5XXエラーはサーバー側で発生します。一般的な5XXエラーには以下のようなものがあります。
- 500内部サーバーエラー。コードレベルのエラー、またはその他の特定不能なサーバーレベルのエラーです。
- 502不正なゲートウェイ。サーバーがプロキシとして機能している場合、ネットワーク階層内の別のサーバーから無効なリクエストを受信したときにこのエラーが発生する可能性があります。
- 503サービス利用不可。サーバーがメンテナンスのためにダウンしているか、同時に処理するリクエストが多すぎるために、リクエストを処理できない場合に発生するエラーです。
- 504ゲートウェイタイムアウト。サーバーが応答に時間がかかりすぎると、リクエストがタイムアウトし、504エラーが発生します。
500エラーが発生した場合は、コードでエラーが発生したため、エラーログを確認する必要があります。502および503エラーの場合は、Webサーバーサービス（Nginx、Apache、NodeJSなど）が実行されており、すべての依存サービス（データベース、PHPなど）がアクティブであることを確認してください。
504エラーの場合、サーバーがリクエストの処理に時間がかかりすぎたため、完全に停止しました。これは、データベースクエリが遅い、応答しない必要な外部サービスがある、サーバーリソースが最大になっているなど、いくつかの理由が考えられます。これらはそれぞれ少しずつ異なる方法で処理する必要があります。
5XXエラーの詳細については、こちらで確認できます。
ログの場所を知る
サーバーのエラーログの場所を含むリソースを記憶するか、安全に保存しておくことが重要です。eコマースストアがダウンしているときは時間が重要なので、問題を迅速に特定することが鍵となります。
Rollbarのような監視ツールを使用している場合は、アカウントにログインしてエラーログを確認するだけで済みます。
サーバーの負荷を確認する
すべてのサーバーには、現在の負荷（現在使用されているすべてのリソースのリスト、場合によっては履歴）を表示する方法があります。これらの表示方法を理解して、特定のリソースを過剰に使用しているものがないか確認してください。
注意を払うべき3つの主要なリソースは、CPU、メモリ、ディスクI/Oです。通常、Webベースのトラフィックの影響を受けるリソースであるCPUとメモリに主に焦点を当てる必要があります。
知っていましたか？
CPUはサーバーへのすべてのリクエストを処理し、それらのリクエストのすべての処理も行います。トラフィックが急増すると、サーバーがより多くのリクエストを処理しようとするため、CPU使用率も急増します。CPUで処理できる以上のリクエストがある場合、リクエストはキューに入り始め、先入れ先出し（FIFO）方式で処理されます。
メモリ使用量は、サイトの速度低下や完全に停止を引き起こす可能性のあるもう1つの一般的なボトルネックです。サーバーのメモリが不足すると、リクエストは完了するまで、より多くのメモリが利用可能になるまで待機します。CPUと同様に、2つの選択肢は、より多くのメモリを追加するか、各リクエストが必要とするメモリ量を減らすかのいずれかです。
CPUとメモリの両方には、トラフィックの急増や高負荷のリクエストを維持するための2つの基本的な方法があります。
- 必要なリソースを増やす
- コードまたはデータベースを最適化して、より少ないリソースで済むようにする
これら2つのトピックについては多くの書籍が書かれていますが、ここでは簡単に説明します。迅速かつ簡単な解決策は、より多くのリソースを追加することですが、それにはより多くのお金がかかる可能性があります。適切な長期的な解決策は、不要なコードとデータベースクエリを特定し、一時的に無効にするか、最適化することです。
NewRelicのような監視ツールは、どのプロセス、コード、データベースクエリがリソースを最も消費しているかについての洞察を提供してくれるため、最適化するかリソースを増やすべきかを判断するのに役立ちます。私たちは実際にこれを数回使用して、私たち自身のサイトで504エラー（タイムアウト）を引き起こしていたコードを特定しました！
ホスティング会社に連絡する
ほとんどのホスティング会社は自動監視を使用しているため、問題がホストにある場合、彼らはすでにそれを認識しており、積極的に修正に取り組んでいる可能性が高いです。ただし、確信が持てない場合は、サイトがダウンしていることを知らせるために連絡し、表示されている具体的なエラーを伝える必要があります。
言うまでもなく、サポートに関して良い評判を持つホストを選択することが重要です。ホスティングプロバイダーを調査する際は、サービス利用規約（TOS）とサービスレベルアグリーメント（SLA）を確認して、期待できるテクニカルサポート、保証された稼働時間、サーバーの可用性、監視などの状況を把握してください。
ソーシャルメディアでアナウンスする
一時的なダウンタイム以上のものが発生している場合は、特に多くの人が問題を抱えている大規模なビジネスを運営している場合は、ソーシャルメディアでアナウンスすることを検討してください。たとえば、Twitterは、問題が発生したときに企業がユーザーに迅速に通知するための一般的な方法です。
購入した製品を顧客に届ける
サイトがダウンしたために製品を受け取れなかった顧客がいる場合、それらの製品を適時に配信する方法が必要です。ストアの規模によっては、DropboxやGoogle Driveに製品のコピーを保管しておくのが良い選択肢となります。これにより、顧客にプライベートなダウンロードリンクを簡単に送信できます。製品をダウンロードしたら通知するように顧客に依頼することもできます。そうすれば、ユニークなリンクをすぐに削除できます。
予防のためのベストプラクティスを使用する
サイトがダウンする理由はたくさんありますが、昔から言うように、「予防は最善の策」です。では、これらの潜在的な問題から身を守るにはどうすればよいでしょうか。
まず、サイトのダウンタイムを監視していることを確認してください。結局のところ、同僚に伝えられるよりも、ましてや顧客に伝えられるよりも、自分でそれに気づく方が良いのです。
常にすべてをバックアップする
サイトに変更を加えるときはいつでも、必ずバックアップを作成してください。新しいコードをプッシュする場合でも、プラグイン、テーマ、CMSを更新する場合でも、その他のことを行う場合でも、サイトのバックアップは絶対に不可欠です。
また、事前に（そしてテスト済みの）「ロールバック」計画を立てておくことも重要です。変更を加えるためにその輝かしいボタンを押す前に、それらの変更を元に戻すために必要な手順を把握し、ステージング環境でそれらをテストしてください。
ソーシャルメディアでサービスプロバイダーをフォローする
一部のサービスプロバイダーは障害を公に発表しているため、ソーシャルメディアでフォローすることで、何かあった場合に情報を入手できます。これらのアカウントのプッシュ通知をオンにして、問題について最初に知ることができます。
プロバイダーによっては、インフラストラクチャ用の便利なステータスページを用意している場合もあります。ブックマークしておきましょう！
監視ツールの使用を検討する
- NodePing。このサーバー監視サービスは、複数の地理的な場所からホームページにアクセスして、ダウンタイムを警告します。ホームページとチェックアウトの監視を設定して、ホームページのフッターテキストやチェックアウトの購入ボタンのテキストなど、特定の文字列を検索できます。これらのチェックのいずれかが失敗すると、NodePingはSMS（または他の多くの方法）で通知します。
- Rollbar。エラー追跡とクラッシュレポートに効果的です。Rollbarはリアルタイムでエラーを監視し、エラーログをグループ化してリアルタイムフィードと検索可能なWebインターフェイスにカタログ化します。さらに重要なのは、特定のエラーの傾向が出始めた場合に通知できることです。これにより、サイトの更新が問題を引き起こしているかどうかを知ることができます。
- NewRelic。NewRelicはサーバーに直接統合され、サーバーに関するほぼリアルタイムの統計情報をログプラットフォームに送信します。これにより、遅いリクエスト、データベースクエリ、非効率的なコード（行ごとに分解できます）を特定するのに役立ちます。最終的には、エラーやページの読み込みが遅くなる原因を正確に特定できます。
これらの3つのサービスにより、コードレベルのエラーや停止を検出し、リアルタイムで通知を受けることができます。これにより、認識していない停止が発生することはなくなり、迅速に対応できます。
行動計画を立てる
サイトがダウンした場合に何をすべきかを知ることは、戦いの半分です。そして、問題が発生した場合に、あなたと顧客のために計画を立てておくことで、物事をずっと楽にすることができます。この投稿が、参照するためのガイダンスと、そもそもサイトのダウンタイムを防ぐのに役立つ洞察を提供してくれたことを願っています！
あなた自身のデジタル製品ストアのダウンタイムをどのように処理しましたか？サイトを復旧し、将来の問題を防ぐためにどのような手順を踏みましたか？あなたの意見を聞かせてください。以下にコメントを残してください！
Jessica Johnstonによるイラスト。
