まず業務サービス・プローブ・正式な依存関係を確認する
業務責任者と運用担当者がまず保護対象の業務サービスを明確にし、そのうえでプローブを設定して依存関係を確認します。機器の自動検出や依存関係の候補は整理の手がかりであり、人が確認した正式な関係だけが業務判断に用いられます。関係が欠けている場合やプローブが利用できない場合は、まず業務マッピングを補うかデータ収集を復旧させてから、影響を判断します。
AIOA Aegis / 業務影響を優先する AIOps 判断支援基盤
設備警報の後、業務への影響をどう判断するか？
設備警報の後に業務プローブと正式な依存関係を確認し、監視と資産構成から調査範囲を絞ります。点検と AI が検証可能な証拠を提示し、人が対応を判断します。影響が見つからないことは、障害がない証明ではありません。
内容確認日 · v1.4.3
業務の流れ
障害・資産・トポロジで調査範囲を絞る
機器のアラートが発生したら、Zabbix の障害・メトリクス・履歴を、関連する資産と業務の文脈に戻して確認します。異常が業務プローブの変化と整合するかを照合し、トポロジを用いて影響範囲を判断します。機器のアラートと業務停止は別の事実であり、業務影響が確認されないことは、現場に障害がないことの証明にもなりません。
証跡を収集し、判定済みと未判定を区別する
点検の実行、または権限を限定したアシスタントのツールを通じて再確認できる証跡を取得し、そのうえで判読と追加確認を行います。収集と解釈は分けて保存し、バッチの一部が失敗した場合も、取得済みの結果と未判定の項目を残します。収集した元の証跡が利用可能で、ジョブの状態が許す場合は、収集をやり直さずに解析だけ再実行できます。証跡が不足している項目や解析に失敗した項目は、引き続き調査が必要です。
対処の責任を明確にし、処理後に業務状態を再確認する
運用担当者が証跡に基づいて対処方法を決め、責任・進捗・再確認の結果を記録します。アシスタントが生成するのは助言としての変更ドラフトであり、承認されても、そのドラフトをプラットフォームが自動実行することはありません。既存の管理機能や機器設定機能には、別途の権限と操作範囲があります。処理後も業務プローブと関連する障害を確認し、追跡可能な記録として残す必要があります。
現場確認で注目する境界
- 正式な業務依存関係は人が確認しており、検出された候補と正式な資産関係は区別されている。
- 元の証跡・部分的な結果・未判定の項目を識別でき、業務影響が確認されない場合も、現場の証跡と併せて業務状態を確認する。
- 対処の権限・現場アカウント・責任分担が明確で、助言ドラフトを自動実行の仕組みと取り違えていない。
対象のお客様
企業 IT 運用部門、情報センター、運用サービス事業者。
導入と適用範囲
PostgreSQL と pgvector を使う自社環境への導入に対応。監視・現場アカウントの権限、発見方式、対象拠点を確認します。
変更提案は承認されても自動実行されません。一部の管理・設備設定には書込みがあるため、基盤全体が読取専用ではありません。
HONGCHUANGDA TECHNOLOGY
お問い合わせ
各製品は独立して導入できます。製品間連携は案件ごとに範囲を確認します。