設計エンジニアのチームにとって興味深いタスクの1つは、機器を監視するための大規模な企業情報システム用の単一の「障害ツリー」を構築することでした。
問題の声明
この分類器を統合した情報システムは、さまざまな機器の事故に関する情報を一元化し、完全に異種のシステム、データベース、デバイスからさまざまな問題状況に関するデータを収集します。 このようなアーキテクチャの主要なアラームが完全に多様になることは明らかです。 たとえば、3つの異なる外部外部システムが「ブレーク」フォールトを送信しましたが、1つのケースでは接触ネットワークの中断でのキャリアケーブルの破損であり、もう1つのケースでは電源の切断であり、3番目では加入者間の接続が失われました。 この状況は、その後のレポート作成および分析タスクで使用するために明確な分類が必要なため、私たちには適していませんでした。
新しいタイプの着信イベントを見つけると、私たちのアクシデントハンドラーはそれらを単にディレクトリに追加し、メッセージタイプのみの体系化が開始されるまでに、1000個以上が蓄積されていました。
次の目標を設定しました。
- シノニムを削除-まったく同じ意味を持ち、スペルが異なるレコードを結合します。
- あらゆる性質の障害を「レイダウン」できる統一された階層分類構造を開発する。
- 明確で一貫性のある構成の原則を定義することにより、この分類のさらなる発展（詳細）を簡素化する
私たちは、分類の特徴的な特徴が次のようになるように努めました。
- 一般的な適用性、当社の他のプロジェクトおよび製品での使用の可能性。
- シンプルさと直感的な理解性。これにより、この構造を簡単に開発し、新しい誤動作の「適切な場所」を見つけることができます。
- 説得力、これを自動化の潜在的および潜在的顧客に証明する能力-実際、私たちのシステムは、この問題に対する独自のアプローチが採用された複数の大規模な組織単位の活動を一度にカバーしました。
進捗状況と間違い
作業の開始後すぐに、分類原則の開発がトピック全体の重要なタスクであることが明らかになりました。 以下の理由により、外部システムからの分類を基礎としてとることはできませんでした。
-特定のシステムによって解決されるタスクの特異性による推定の一般的な方向性の狭さ、
-多くの場合、問題の階層が存在しない（ツリー構造に組み込まれていないフラットな障害リスト）
-言葉遣いの複雑さ、原因と結果を1つの位置に混在させる。
これらの機能不全の兆候が発生したインフラストラクチャ施設ごとのグループ化に基づいて、最初のバージョンを作成しました。 実際、これは最も簡単な方法でした。単一の（当社の）インフラストラクチャモデルに基づいて、別個の「エイリアン」障害リストの単純な組み合わせを想定しているためです。
一般に、次のような結果になりました。
....約1,600行ありますが、そのうち約600行は特定のオブジェクトに添付できませんでした。 同時に、すべての問題に明確なオブジェクトバインディングがあったわけではなく、言及したすべてのオブジェクトがリソースベースに導入されたわけでもありません。 このアプローチは状況を少し解明しましたが、共通の階層を導入し、同義語を特定し、目標の1つである総数を減らすことはできませんでした。
将来、システムへのオブジェクトへの誤動作の「適用可能性」は残りましたが、これは誤動作の一般的な階層とは別のディレクトリになりました。
結果
そのため、ある時点で、以前に展開された情報ベースとシステム、または組織が採用した規制文書に基づいて単一の構造を作成できないことが明らかになりました。
その結果、次の作業原則を開発しました。
- 作成されたツリー違反（標準からの逸脱）と自然科学によって分類された自然プロセスの現れの根本で分離する。
- 現代科学の観点から、自然現象とプロセスの分類を保存する。
- 主要な症状から結果を分離し、現象と結果の両方を含む文言を結果が割り当てられるブランチに参照する（たとえば、「停電」は停電を指し、「停電の結果としてのデータ損失」は情報システムの混乱を指す）。
- これまで分類できなかったすべてを「その他」グループに割り当て、上記で採用した分類原則に基づいてこのグループの「分析」に関する体系的な作業を確立することができます。
- 一般構造内の各新規レコードの位置を決定するときは、原則に従ってのみ導かれます：「顕在化がすでにツリーに入力されている特定のケース」は、この方法でルート内からツリー内のこのレコードの場所を検索することです。
- 不足している「一般化」を自分でツリーに追加します（そのような初期アラームメッセージがない場合）。
このように動作して、ツリーの最初のレベルに次の一連のブランチを作成しました。
結果は何ですか？
残念ながら、この作業は完了しておらず、私たちがやめた結果は非常に「生」です。
この失敗の理由は次のとおりだと思います。
-この作業は、インフラストラクチャの所有者によって編成および継続されることになっていますが、自分でそれを引き受ける準備ができている専門家はいませんでした。
-「現場」の専門家は、おなじみの名前と分類に非常に満足しており、サブグループを一般化して区別しようとする私たちの試みは彼らの抵抗に応えました。
-この作業が実施されたグローバル分析レポートの実装は開始されませんでした。
一般的に、顧客はそのような変更に対応する準備ができておらず、従業員に影響を与えるだけの十分な管理リソースがありませんでした。
もちろん、時間は無駄ではなかったと言えます。 そのような作業を実行する際に、かなりの経験が蓄積されており、その一部は上記の原則に基づいています。 私自身、このようなプロジェクトを小さな段階に分割し、中間結果を常に顧客に示し、彼の側の変化に対して積極的なサポートを提供することが重要であると個人的に結論付けました。
なぜそうなったのですか？ なぜ私たちの意見でさえ得た中間結果が完全からはほど遠かったのですか？
実装中に判明したように、ユーザーは基本的に分類を受け入れる（そして許す）準備ができていますが、1つの単純な条件の下で-テキスト検索をフォームに追加します！
分類は経験の体系化の産物です。 明らかに、ユニークな個人的な経験に導かれた各人は、それを彼自身の方法で見ます。 たとえば、メールプログラムでは、一部（自分を含む）が受信メールをソートするための複雑なシステムを作成しますが、メールをまったくソートせず、すべてを1つのフォルダーに保存し、同時に完全にナビゲートします。 そして、彼らは私よりも速く正しい手紙を見つけます。 たぶんそのような人はYandexを頭に持っているのでしょうか？
さらに、事前定義された分類は、システムで受信した最新のデータを考慮して最終的に決定された後にのみ、100％完全になります。 つまり、分類には常に注意が必要であり、ユーザーはシステムで作業する必要はなく、使用する必要があります。 検索はインデックス付けであり、常に実際のデータで機能します。 その場合、分類は必要ですか？