運用安定性の問題の鍵 – 可用性

レビューは、要約とその後の改善に基づいています。では、安定性の問題をどのように見つけて測定するのでしょうか?次に、今日の主役である可用性を引き出す必要があります。

可用性とは何ですか?

可用性はビジネスの安定性を評価するための重要な指標であり、データの定量化とベースラインの確立を通じてビジネスの定期的な問題を発見し、より的を絞った方法でサービス品質を向上させることができます。

それでは、可用性とは何でしょうか?可用性とは、特定の時間間隔内で機能的な個人が利用できる合計時間の割合を指します。言い換えれば、システムが指定された期間内に正常に動作できる確率または割合を指します。現在のインターネットビジネスの多くは「リアルタイム」かつ「オンライン」、つまりリアルタイムオンラインシステムです。当社のビジネスのほとんどでは、上記の指定期間は 7*24 時間である必要があります。

可用性の結果は、多くの場合、小数点またはパーセンテージを使用して表現されます。通常、小数点以下の連続する 9 の数に対応する、9 の数と呼ばれる尺度を使用します。たとえば、「ファイブ ナイン」は、指定された期間内にシステムの可用性が 0.99999 (または 99.999%) であることを意味します。

対応する大き​​さを理解するにはどうすればよいでしょうか?

たとえば、システムは 1 日、つまり 24 時間など、指定された期間内で動作します。同時に、監視の粒度は分、つまり 1440 分です。 1440 分間の監視中、システムは 1430 分間正常に動作しました。この指定された期間内でのシステムの可用性は、1430/1440 ≈ 0.99306 (99.306%) になります。これは、よく「9 が 2 つ」と呼ばれるものです。

値 99.306% は、通常利用可能な可用性状態にあるシステムの割合を表し、1 ～ 99.306% から取得された値 0.694% は、例外を処理できない非可用性状態にあるシステムの割合を表します。 。単純に数式として列挙すると、次のようになります。

ビジネスがオンラインになっている合計時間 = ビジネスの通常の可用性時間とビジネスの異常な非可用性時間

さらに一歩進んで、可用性とは次のことを意味します:

可用性 = ビジネスの通常の可用性時間 / ビジネスの合計オンライン時間

可用性を確立する方法

可用性とは何かを理解した上で、可用性を確立する方法について話しましょう。ユーザビリティを確立するにはさまざまな方法があり、一般的な方法がいくつかあります。

ダイヤルテスト方法

ダイヤルテスト方式とは、各業務の稼働状況が正常であるかどうかを、アプリケーション、機能、モジュールごとに定期的にテストする方式です。

例: 私たちのビジネスには A という名前のモジュールがあります。次に、ユーザーの動作をシミュレートすることによって、このモジュールの実行ステータスを定期的に (たとえば、5 分に 1 回) サンプリングします。モジュールが正常に動作している場合は「可用性」として記録され、異常な場合は「使用不可」として記録されます。一定期間 (たとえば、1 日) 内に蓄積された可用性ステータスの割合が、このモジュールの可用性になります。

では、ビジネスやモジュールが正常かどうかはどうやって判断すればよいのでしょうか? Web系ビジネスを例に挙げると、サービス配下のホームページ、カテゴリーページ、コンテンツページの主要なコンテンツを確認することができます。一般的に、指定されたページの見出し、本文、および末尾の指定されたフィールドまたはキーワードを照合できます。指定されたフィールド、フィールドのグループ、またはキーワードが一致する場合は正常であり、一致しない場合は異常です。スクリプト、Nagios、Zabbix、その他のツールを使用して、ビジネスの定期テストを実装できます。

この方法の長所と短所は明らかです。この方法の利点は、実装の難易度が低く、ユーザーの行動をシミュレートすることで測定でき、実際のビジネス状況との整合性もより高いことです。しかしながら、この定期的なサンプリング方法では、サンプリングサンプルが不十分または偏ってしまうという問題がある。たとえば、ダイヤル テストは 5 分ごとに実行されますが、障害が発生し、この 5 分以内に修復された場合、ダイヤル テスト方式でそのようなエラーを検出することは困難になります。

#ログ分析方法

ログ分析手法とは、各業務のアプリケーション、機能、モジュールのログを分析することで可用性を取得する手法です。

例: 私たちのビジネスには A という名前のモジュールがあり、このモジュールの 1 時間のログが定期的に (たとえば、1 時間に 1 回) 分析されます。ログ レベルから区別される通常のリクエストの割合は、過去 1 時間のこのモジュールの可用性です。 Web系ビジネスを例にとると、ログから2XXと5XXの状態をそれぞれ統計・分析することができ、2XXはAvailability、5XXはUnavailabilityであることがわかります。 （3XX、4XXは経営実態に応じて分析への参加を検討可能）

この方法は、ダイヤル テスト方法におけるサンプリング サンプルの不足または偏りの問題を明らかに解決しますが、実際のビジネス インパクト指数が大きく異なる可能性がある状況もあります。たとえば、過去 1 時間のエラーはすべて 1 分以内に発生し、残りの 59 分間の業務は正常でした。このようにして得られた可用性と実際のビジネス状況の間には、明らかに一定の乖離があります。では、このズレをどうやって解決すればいいのでしょうか？ログ分析閾値法が登場しました。

ログ分析閾値手法

ログ分析閾値手法は、ログ分析手法に基づいて状態閾値判定を追加した可用性計画手法です。

例: 私たちのビジネスには A という名前のモジュールがあります。ログ分析により、このモジュールに対する通常の状況でのリクエスト数は 1 分間に約 100,000 回であることがわかり、しきい値を 10 回に設定できます。この 10 回が意味するのは、1 分以内に発生する誤差が 1 万分の 1 未満であることを許容するということです。 1 分間に発生したエラーの数が 10 未満の場合、過去 1 分間のステータスは正常とみなされ、可用性としてマークされます。 1 分間に 10 件を超えるエラーが発生した場合、過去 1 分間のステータスが異常とみなされ、「使用不可」とマークされます。最後に、可用性ステータスの比率が計算されて、このモジュールの可用性になります。もちろん、このしきい値はビジネスの実際の状況に応じて調整する必要があります。

この手法は、ダイヤルテスト手法のサンプル偏差とログ分析手法の実際のビジネスへの影響との乖離の問題を解決し、バランスをとった手法です。

別の質問があります。ビジネスが 3 つのモジュール A、B、および C で構成されている場合、モジュールの可用性を通じてビジネスの可用性を計算するにはどうすればよいですか?簡単な方法は、最も多くの 3 つのモジュールの可用性の平均を使用することです。しかし、ビジネス目標には問題があります。次に、ビジネス目標に合わせて加重平均法を使用できます。たとえば、モジュール A がビジネスにとってより重要な場合、可用性を計算するときにモジュール A の重みを大きくします。モジュール C はビジネスにとってバイパス システムであるため、可用性を計算するときにモジュール C の重みを減らすことができます。類推すると、私たちが導き出す可用性は、ビジネスとその目標に可能な限り近づけることができます。

その他の方法

また、Keynote や Borui などのサードパーティのテスト プラットフォーム ノードを使用して、サンプル収集の精度を向上させ、その偏差を減らすことで、ビジネスのより広範なテストを実施することもできます。もちろん、結果はサードパーティのプラットフォームの影響とリンクの安定性によっても制限されます
顧客を持つ企業に対しては、顧客のクリティカルパスを管理し、ユーザーの管理ログをサーバーに集約して一元的に分析することができます。この方法は最も現実的なユーザー状況を反映できる一方で、実装コストが比較的高い、ログのアップロードが遅れるなどの問題もあります。

最後に書きます

可用性を計算する方法は上記で説明したものよりもはるかに少なく、すべての問題と問題点を解決できる単一の方法はありません。コスト、収入、時間などの観点から貴社のビジネスやチームに最適な方法を 1 つ以上選択し、貴社のサービス品質を継続的に向上させるために活用してください。

以上が運用安定性の問題の鍵 – 可用性の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。