現状の課題
監視システムを導入して運用を開始すると、システムから発生するアラート情報を継続的に削減するなどの改善をしていくべきだ。例を挙げよう。ある時間帯にOSやミドルウエアから障害情報がログに出力されるものの、実際にはその機能を利用していないとする。この場合、そのエラーは無視してよい。アラート情報の改善とは、運用上、不要なアラートを適切に対処したり、必要なアラートの適切な対応手順を定義したりすることである。
改善するにはシステム側を変更して根本対応することが望ましいが、一旦リリースした本稼働システムを変更することは困難である。システム側の変更を待たずにワークアラウンドとして何か対策方法がないだろうか。
解決策
根本的な対策を行うまでは、ワークアラウンドとして監視システム側でフィルタリングを行うように設定する。既知の問題である場合は、これまでに出力されたアラートを基に処理のルールを作成する。そして、次回以降の発生時には、「既知エラー」として判断し、自動的に処理を実施する。その際にはログを残すことを忘れないように注意する。
ワークアラウンドの決定は運用担当者ではなく、開発・基盤担当者が主体となって行うべきである。開発・基盤担当者には自分たちが構築したシステム状況から発生したアラートにどう対処すべきか決定する責任があるからだ。
ただし職責分離上、開発・基盤担当者は本番システムにアクセスすることができない。本番システムにアクセスしなくても、どのようにワークアラウンドが実行されるのかをシミュレーションできる環境を用意しておく必要がある。
Senju Familyでの実践方法
Senju DevOperation Conductorでは「メッセージアクション」機能を利用して、あらかじめ条件とするイベントと、そのイベントに対するアクションを設定しておき、条件に該当するイベントが発行された場合に、自動的に設定されたアクションを実行することが可能だ。これによりワークアラウンドとして、既知エラーを判断し自動的に処理を実行できる。
開発・基盤担当者が対応方法を定義する際には、「千手オフライザ」を利用すると便利だ。これは千手マネージャとの接続環境のないオフライン環境下、例えば自席のPC上などのローカル環境で手軽に定義データの作成・参照・確認などを行うことができるものである。
ルールのシミュレーション機能を用いて、イベントが発行された際にどのようにメッセージアクションが動作するかを事前に確認することができる。本番システムへのアクセスは不要である。
作成したメッセージアクション定義はテキストファイルで書き出し、読み込みも可能であり、各イベントに対するアクション定義を別ノードに対し複数横展開したい場合などはテキストデータで複製、修正も可能である。Senjuの各種機能をクラウド型で提供する運用基盤クラウドサービス「mPLAT」の運用においても、イベントに対するアクション定義を各テナント向けに横展開する際に、テキストデータでの書き出し、読み込みを活用している。
