IT運用保守プラットフォームアルゴリズムの背後にある2つの「神の助け」

[51CTO.comからの原文] インテリジェント運用保守（AIops）は、IT運用保守の分野で最もホットな用語です。正式名称はアルゴリズムIT運用プラットフォームで、正式翻訳は「アルゴリズムベースのIT運用保守プラットフォーム」です。アルゴリズムは、インテリジェント運用保守のコア要素の1つであることがわかります。

[[192576]]

この記事では、主に運用と保守におけるアルゴリズムの役割について、異常検出と属性分析という 2 つの側面から説明します。また、運用保守システム Kale におけるスカイライン、Oculus モジュール、Opprentice システム、Granger 因果関係、FastDTW アルゴリズムなどの詳細についても説明します。

異常検出は、運用および保守エンジニアが最初に遭遇する可能性のあるものです。結局のところ、監視とアラームはすべての運用と保守作業の基礎です。アラームしきい値の設定は、時間と労力がかかる作業であり、作業を進める前に運用および保守担当者がビジネスを完全に理解する必要があります。また、ビジネスが着実に発展しているかどうかも考慮する必要があります。そうしないと、1 週間または 2 週間ごとに変更が行われると、運用および保守エンジニアは間違いなく気が狂ってしまいます。

この部分の作業をアルゴリズムに任せて解決できれば、間違いなく大きな進歩となるでしょう。機械学習は確かにこれを実現できます。ただし、機械学習がなくても、数理統計に基づくアルゴリズムを使用することもできます。その結果も同様に良好です。

2013 年、Etsy は Kale と呼ばれる社内運用および保守システムをオープンソース化しました。スカイライン部分は異常検出用のモジュールであり、 9 つの異常検出アルゴリズムを提供します。

• 最初の1時間の平均、

• 移動平均からの単純な標準偏差、

• 移動平均からの標準偏差、

• 平均減算累積、

• 最小二乗法
  

• ヒストグラムビン、

• グラブス、

• 中央絶対偏差、

• コルモゴロフ-スミルノフ_テスト
  

簡単にまとめると、これら 9 つのアルゴリズムは次の 2 つのカテゴリに分類されます。

1. 正規分布から始める: データがガウス分布に従うと仮定すると、標準偏差を使用してほとんどのデータ ポイントの間隔を決定できます。または、分布ヒストグラムに基づいて、ヒストグラムに含まれるデータが少なすぎる場合は異常です。または、ボックス プロット分析を使用してロングテール効果を回避できます。

2. サンプル検証から始めます。Kolmogorov-Smirnov、Shapiro-Wilk、Lilliefor などのノンパラメトリック検証方法を使用します。

これらは機械学習ではなく、統計アルゴリズムです。もちろん、Etsy の Skyline プロジェクトは異常検出だけが目的ではありません。

まず、ここでは指標自体の状態のみを考慮し、垂直時系列の観点から異常検出を実行します。しかし、ビジネスの複雑さによって生じる横方向の異常は考慮されていません。第二に、提供されているアルゴリズムが非常に多い中で、どのアルゴリズムがより正確に指標を判断できるのでしょうか?これもまた判断が難しい点です。

質問 1:実装の選択肢。同じサンプル検証アルゴリズムを使用して、指標の現在の状態と過去の状態を比較したり、複数の指標のうちのどれが他の指標と異なるかを比較したりできます。

質問 2: Skyline は、実際には非常に単純でシンプルな方法を使用してこれを補足します。9 つのアルゴリズムのそれぞれに 1 つの投票があり、しきい値に達した場合にその投票がカウントされます。この閾値については、通常 6 または 7 が使用され、これが大多数を占めることを意味します。

それに比べて、同じ問題に直面した場合、Baidu SRE のインテリジェントな運用と保守はどのように対処するのでしょうか?昨年のAPMconで、Baiduのエンジニアたちはこの画像を使ってOpprenticeシステムの主要なアイデアを説明しました。

Opprentice システムの主なプロセスは次のとおりです。

• KPI データはさまざまな検出器によって計算され、各ポイントの多くの特徴を取得します。

• 特別なインタラクティブ ツールを使用して、運用および保守担当者は KPI データの異常な期間をマークします。

• 異常分類にはランダム フォレスト アルゴリズムが使用されます。

検出器には、以下に示すように 14 個の異常検出アルゴリズムがあります。

これらのアルゴリズムの多くは Etsy の Skyline にも存在していることがわかります。ただし、多数のアルゴリズムのパラメータを調整するのを避けるための直接的なアプローチは、各パラメータの値の範囲を均等に分割することです。ランダム フォレストでは、特徴エンジニアリングは必要ありません。たとえば、検出器のタイプとして holt-winters を使用します。 Holt-wintersには、α、β、γの3つのパラメータがあり、すべて[0, 1]の範囲にあります。次に、(0.2、0.4、0.6、0.8) としてサンプリングされ、4 ** 3 = 64 の可能性があります。すると、各点には 64 個の固有値が割り当てられます。

Opprentice システムのプロセス全体は、最初にさまざまな統計アルゴリズムを通じて異常を見つけようとし、次に多数決方式/アルゴリズムを通じて最終的な判断結果を決定するという点で、スカイラインの考え方に似ています。

ただし、Baidu は投票の信頼性を高めるためにランダム フォレスト アルゴリズムを使用しています。 Etsy についてはどうですか? Skyline がオープンソース化されてから数か月後、社内で Thyme と呼ばれる新しいバージョンが実装されました。ウェーブレット分解、フーリエ変換、マン・ホイットニー検出などの技術を活用します。

さらに、コミュニティはSkylineに対してもその後のアップデートを行いました。EarthgeckoはTsfreshモジュールを使用して時系列データの特徴値を抽出し、複数の時系列間の異常検出を実行しました。後続の 2 つの Skylines では、依然として機械学習は使用されていませんが、時系列関連の統計アルゴリズムをさらに調査して調整していることがわかります。

Etsy に加えて、オープンソース コミュニティの他の多くの大手企業も、さまざまな時系列異常検出アルゴリズム ライブラリをオープンソース化しており、そのほとんどは 2015 年に開始されました。それらは以下の通りです:

• Yahoo! は昨年、eGads ライブラリをオープンソース化しました。 (ジャワ)

• Twitter は昨年、異常検出ライブラリをオープンソース化しました。 （右）

• Surus ライブラリは 2015 年に Netflix によってオープンソース化されました。 （豚、PCAに基づく）

Twitter ライブラリも Python コミュニティに移植されており、興味のある読者は試すこともできます。

属性分析は、アラーム受信後のトラブルシューティングである運用および保守作業の次の主要な部分です。単純な障害の場合、対応計画は一般的に単純で、サービス再起動エンジニアリングを使用します。ただし、大規模な IT 環境では、障害が発生すると、通常、広範囲にわたるアラームがトリガーまたは発生します。多数のアラームの中から最も緊急かつ重要なアラームを見つけることができれば、復旧時間（MTTR）を大幅に短縮できます。

この障害箇所特定要件は、通常、根本原因分析 (RCA) として分類されます。もちろん、RCA は障害箇所の特定以外にも使用できます。パフォーマンス最適化プロセスは通常、RCA の一種です。

異常検出と同様に、RCA も統計と機械学習の手法を並行して使用して実行できます。統計の観点から始めましょう。これは依然として Etsy の Kale システムであり、異常検出用のスカイラインと Oculus と呼ばれる別の部分が含まれています。そして、Etsy が Kale 2.0 を再構築したとき、Oculus は 1.0 の中で最も成功した部分であると考えられ、そのまま保持されました。

Oculus の考え方は、一言で言えば、「ある監視指標の時間傾向グラフが別の監視指標の傾向グラフと似ている場合、それらは同じ根本原因の影響を受けやすい」ということです。したがって、IT 環境全体における時間同期が信頼でき、監視指標の粒度が比較的細かい場合、アラームに最も類似した最も古い監視指標が、特別な注意を必要とする根本原因であると大まかに推測できる可能性があります。

Oculus のスクリーンショットは次のとおりです。

この部分では 2 つの計算方法が使用されます。

• ユークリッド距離は、異なる時系列データを同時に比較することです。 0 分 0 秒の場合、a と b の差は 1000 になり、0 分 5 秒の場合も差は 1000 になります。

• FastDTW はオフセットのレイヤーを追加します。0:00 の a と 0:05 の b の差は 1000 です。0:05 の a と 0:10 の b の差も 1000 です。以下同様です。もちろん、この単純な仮定の背後には、アルゴリズムの計算の複雑さを軽減するための多くの具体的な実装がありますが、ここでは説明しません。

唯一残念なのは、Etsy が当初 Oculus を ES バージョン 0.20 に基づいて実装し、それ以降更新されていないことです。これほど古いバージョンをまだ使用している ES ユーザーはほとんどいないはずです。 Oculus 以外にも、さまざまな統計原理を使用して同様の効果を実現する製品が数多くあります。

グレンジャー因果律はアルゴリズムです。簡単に言うと、「前瞬間の情報が全てわかっている場合の現時点でのXの確率分布」と「前瞬間のY以外の情報が全てわかっている場合の現時点でのXの確率分布」を比較して、YがXと因果関係があるかどうかを判定します。

機械学習について少し学んだ読者は驚くかもしれません。機械は相関関係には反応できるが因果関係には反応できないと言われているではないですか?ここでの因果関係は統計的な意味での因果関係であり、通常の哲学的な意味での因果関係ではないことに注意する必要があります。

因果関係の統計的定義は、「宇宙の他のすべてのイベントが一定であり、イベント A の発生または非発生が別のイベント B の発生確率に影響し、これら 2 つのイベントに時間的な順序 (A が B より前) がある場合、A は B の原因であると言えます。」です。 』

よく使用される別のアルゴリズムはピアソン係数です。次の図は、ITOM ソフトウェアの実装を示しています。

 acc_count<-scale(acc$acc_count,center=T,scale=T)
 CPU<-スケール(acc$cpuload5、中心=T、スケール=T)
 cor.test(acc_count,CPU) 関数