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

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

例: 私たちのビジネスには 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 つ以上選択し、貴社のサービス品質を継続的に向上させるために活用してください。