「監視で収集したデータを有効に活用したい」というケースはとても多い。データの活用方法はさまざまだが、例えば次のようなものが挙げられる。
1.リスクを事前察知し、対応策を練る――例えば、「先月1カ月のハードディスク使用量の増加分を見ると、同じような使い方をすれば、あと2カ月で容量不足になってしまうことが分かった。念のためハードディスクの増設を行おう」といったとき
2.無駄の削減につなげる――例えば、「先々月に比べ、先月のハードディスク使用量は格段に増加している。何か無駄な利用をしていないだろうか。増加分を何のために使用しているか利用者に聞き、削減できないか確認しよう」といったとき
このような場合にお勧めしたいOSS製品が、Pandora FMSだ。Pandora FMSは、スペインのArtica社が開発する監視ツールで、収集した監視データを自動的にグラフ化し、まとめてPDF、HTML、XML、CSV形式で出力できる「リポート」機能を有している。
システム管理者自身がデータの推移を確認し、今後の運用に活用するには、この機能で十分だろう。しかし、リポートを取り扱う上で、次のような要望がある場合は、OSS製品だけでは実現できないため、商用ツールも視野に入れるべきだ(ただし、これらの中にはPandra FMSの有償版で提供されている機能もある)。
企業では、「稼働状況に問題がないか」「リソースは有効に活用できているか」を確認するために、運用状況を月次で報告書にまとめている例が多い。その報告資料の作成は、優れたリポート出力製品を使っているなら簡単に済むことだ。しかし、そうした製品や機能がない場合、管理者自身が手作業で、監視システムから膨大なデータをCSVで出力し、Excelで一つ一つグラフに加工しては資料に張り付けていく、といった作業をしていることが多い。
このような運用をしている場合、運用現場の状況を見据えて、OSSやOSS有償版、商用ツールの機能を見極め、うまく利用することで、管理者の人件費、ひいては運用のトータルコストを下げられる場合がある。管理者の生産性も上がることは言うまでもない。
監視で障害を検知した後に必ず行うことになるのが障害対応である。管理者の皆さんは、こんな経験はないだろうか。
「以前も同じような障害があったような気がするが、誰がどんな対応をしたのか思い出せなかった。もし分かっていれば、もっと楽に早く対応できたのに」
障害が起きたときに、以前のノウハウを活用できれば、より早く、より楽に障害に対応できる。しかし、ノウハウは大事だと認識していても、「障害対応が完了したことにホッとして、対応内容を記録するのを忘れてしまった」「担当者によって書き方がバラバラで、書いた人によっては、後から利用できるものになっていない」といった問題が起こりがちだ。
さらに、対策として書き方のルールを定めてみたものの、結局定着せずに自然消滅してしまったというのも起こりがちな例だ。その結果、同様の問題が起こってもまた一から対応を考えなければならなかったり、ノウハウが属人化してしまったりする。
こうした問題に対応するOSS製品が、「OTRS」だ。OTRSはドイツのOTRS AGが開発しているITIL v3に準拠したインシデント管理ツールである。
OTRSは、登録された一つ一つのタスクを、「チケット」という単位で管理し、開始から終了までの状況を記録できる。メールによるチケットの自動登録機能があり、例えば「監視製品からOTRSに向けて、障害時にメールを発行する」ように設定すれば、障害発生を検知すると同時に、自動でチケットを発行し管理を始めてくれる。
あらかじめ設定された期間、チケットに更新がなかった場合、自動的に通知する機能もあり、「障害後にうっかり対応内容を書き忘れる」ことも防止してくれる。また、チケットには、あらかじめ設定されたフォーマットが用意されているため、担当者ごとの書き方をある程度そろえることもできる。また、チケット管理だけでなく、FAQの機能もあるので、よく起こる障害や運用での注意点をまとめておけば、さらに利用の幅が広がるだろう。
このように多くの有用な機能を持つOTRSだが、利用者が気を付けるべき点もある。例えば、前述した「メールによるチケット自動登録機能」を利用する場合、「OTRSで受信したメールの件名」がそのままチケットのタイトルとして登録されるようになっている。つまり、監視製品からメールを送信する場合は、受信者が内容を理解しやすいよう、「チケットのタイトルとして利用しやすい件名」になるように、監視検知メールの件名を設計する必要がある。
チケット管理ツールは、頻繁なアクセスが想定され、利用者にとって使い勝手がいいかどうかは特に重要だ。障害対応など迅速性が必要となる状況ではなおさらである。導入に当たっては、具体的な利用方法を踏まえて、できれば実際に利用する人とともに検討した方がよい。
さて、いかがだっただろうか。OSS製品、商用ツールの枠に関係なく、各製品にはできることとできないこと、得意な部分と不得意な部分を持っている。事例を俯瞰すると、OSSと商用ツール、それぞれの全体的な傾向としては以下のようにまとめられそうだ。
ただ、当然のことだが、商用ツールとOSSのどちらが適しているかは「それぞれの事情次第」だ。これは、商品ツールかOSSかのカテゴリの違いというよりツール個々の違いである。従って、要望や利用方法をできるだけ具体的に想定して、マッチする製品を選定することが肝要だ。
すなわち、冒頭で述べたように、まずは「運用自動化の対象となるシステム」の特徴を明確にすることが大切だ。運用対象を明確にせずに、運用自動化ツールの選択はできないためだ。もっといえば、運用自動化ツールとは、組織の業務手順や情報システムの標準化・最適化のための設計思想・基本理念である「EA(エンタープライズアーキテクチャ)」に基づいて、その位置付けを考えて然るべきものである。
参考リンク:「情報システム調達のための技術参照モデル(TRM) 平成21年度版」(出典:経済産業省、2014年/pdf)
システム運用は新しいテーマではなく、何十年のノウハウが蓄積されていることもあり、運用自動化ツールにしても、歴史の長い商用ツールの成熟度が高いのは事実だ。ただ運用自動化の個々の機能で見ていくと、OSSも完成度が高く選択肢も広がっている。
EAという、やや大げさな枠組みも持ち出してしまったが、まず何より重要となるのは「どこまでの機能・非機能を求めるのか」の検討と、「どのようなツールを採用するかという関係者の合意形成」である。ツールごとの機能比較はエンジニアなら誰でも行うだろうが、これらなしにツールを選定しようとしても、「心配だからこの機能も」と、どんどん要求レベルもコストも高くなってしまう恐れがある。
自社のビジネスと、それを支える各システムの重要度を見極め、それを支える運用自動化ツールについても適切な機能/非機能要求レベル、適用範囲をしっかりと検討・設定した上で、適切なツールを採用していただきたい。
溝口 則行(みぞぐち のりゆき)
コーポレート本部 戦略技術センター所属
勤務先でのOSS推進グループのリーダをしつつ、会社を抜け出してOSS関連のコンソーシアムなどによく出没する。得意分野は懇親会。技術系ブログサイト http://TECH-SKETCH.jp/ では、同僚のタレントたちがOSSの最新情報を書いている中で、なぜかネットワークとか性能工学とか筋違いのネタを披露している。
久保 栄子(くぼ えいこ)
IT基盤サービス第1事業部 DCアウトソーシング第1部
Hinemosサポート、および、社内向けシステムの基盤構築・保守運用業務に従事。「顧客(とできれば自分)の保守運用業務を軽減したい」というアツい想いを胸に、統合運用管理ツールの活用方法を日々模索している。
インフラ整備に一層のスピード・柔軟性が求められている今、仮想化、クラウドは企業にとって大きな武器となった。ただ運用管理を人海戦術で行うスタイルでは、そのメリットを生かし切ることは難しい。サーバー配備や監視など、あらゆる定型業務のミスを抑止し確実・迅速に行える「運用自動化」を取り入れることが、仮想化・クラウドを生かす大前提となるのだ――本特集ではツール導入の要件からOSS/商用ツールの使い方、ツール同士の比較まで、「運用自動化」を徹底的に深掘りする。
Copyright © ITmedia, Inc. All Rights Reserved.