忙しい人にこそ導入してほしい運用自動化への道のり#1

こんにちは、寺尾です。

クララオンラインでは、4月20日よりMSPサービスの一部の契約をフィックスポイントのバーチャルオペレータに載せ替えを始めています。先週行われたクラウドコンピューティングExpo2015春でも、フィックスポイントブースにて同サービスを展示・説明させていただきました。

cloudexpo2015-fixpoint-s

これから数回にわたって、クララで取り組んできた運用自動化への道のりについて書いていこうと思います。(まだ道半ばですが)

運用自動化について、その意義についてはいろんなところで言われていますが、忙しいから導入できないというのは本末転倒で、忙しいからこそ導入して欲しいと考えています。

一言に運用自動化と行っても、いろんなソリューションがあります。少しでも候補に挙がったものを列挙してみます。

カバーするレイヤーや商用・OSSと様々なモノを検討しました。比較検討を進める中で、いろんな障壁があります。

その最も大きいモノが、今動いている運用を止めずにどうやって切り換えるかです。これにはそれなりのカスタマイズや、データ構造を変換するための中間レイヤーに相当する部分を開発する必要があったりします。この辺の柔軟性は商用製品の方が高かったです。また、前述の通り、今時間が無いところで大規模な開発は現実的にはリソース的にも時間的にも難しいものがありました。ということで、自然と候補は商用製品に絞り込まれていきました。

各製品のとても主観の入った感想を書いてみます。

  • NRI Senju Family
    • NRIの運用の歴史をくぐり抜けてきただけ有って、かなりできが良い物でした。GUIは古いなと思いましたが、ほとんどがCLIからコントロール出来るため他システムとの連携も容易です。Runbook Automationを備えておりとても柔軟な処理を定義できる事が分かりました。
    • 監視を担うSenju Operation Conductor(OC)と、監視メッセージを判断・処理するSenju Enterprise Navigator(EN)を導入すれば良さそうである事は分かりました。しかし出来れば監視は現状利用しているNagiosを引き続き使いたいという想いがありました。良く話を聞いてみると、プラグインを購入すると監視をNagios、メッセージの判断・処理をENが担当するという構成も可能だという事が判明。この構成は費用的にもおさえられますし、とても魅力的でした。
    • 結果、断念してしまいました。ENは、判断・処理する部分が優秀なわけですが、JavaScriptライクな言語で処理を記述する必要があったのです。これを社内で続けるためのリソースの確保が難しかったのです。
  • ManageEngine
    • 弊社内の担当が過去に利用した際のトラウマがあり、断念。今は解決されているかも知れません。
  • Fixpoint Kompira/Virtual Operator
    • 詳細は後述しますが、クララオンラインではこれを採用する事になりました。
  • Fujitsu SystemWallker
    • Runbook AutomationをGUIで記述する事ができ、とても期待しました。
    • あまり本質的なところでは無いのですが、ホスト名に8文字くらいの制限があり、通常のFQDNが登録できませんでした。おそらくホスト名を社内でコントロール出来る会社内での使用をメインに想定しているためでしょう。「XXXXX.clara.jp」のXXXXX部分を登録して使うイメージなのでしょう。こういった仕様面で目的に合わない点が多く導入を断念しました。

 

出会いは偶然。社内の別の担当からフィックスポイントという運用自動化ツールを開発している会社があるから話を聞かないか?という誘いがきっかけでした。聞いたこともない会社だったので最初は大丈夫かな?まあ、話を聞いてみてだめそうなら断ればいいか。という軽い気持ちで最初のMTGに望みました。

最初のMTGはある程度予想通りで、あまりできることがよくわかりません。最初に話をした2014年2月頃は、Kompira(コンピラ)という、我々が導入したバーチャルオペレータのベースになっている製品の話がメインでした。この製品は開発プラットフォームのようなもので、コード(ジョブフロー)を書けば何でもできます。いろんな可能性があります、といった物でした。やはり、コードを書くリソースをどうやって確保するかが一番の課題でした。

当時の運用の現場はというと、コードを書いている余裕はなく、導入は難しいかなーというのが正直な感想でした。

その後、何度かMTGを繰り返すうちに、Kompiraを発展させてバーチャルオペレータという製品を作っているという話が出てきました。バーチャルオペレータはKompiraをベースにしながら、ジョブフローを新たに書くのではなく、ジョブフロー自体をフィックスポイントから提供してもらい利用できるといったコンセプトでした。しかもフィックスポイントは元々運用をやっていた経験から開発をしています。最初からある程度作り込まれたジョブフローが使える事がメリットでした。これならば、今の運用の現場でも導入可能ではないかという思いで、導入計画がスタートしました。

我々が利用しようと考えたのは、いくつもあるジョブフローのうち FaultNotification という障害対応ジョブフローでした。

このジョブフローの代表的な機能を紹介します。

  • アラートをホストごとにまとめる機能
    • 多重アラートが発生しても通知は1通にまとめて通知されます
    • この機能はクララオンラインからのリクエストで実装されました
  • 柔軟な通知ルートの設定
    • 複数の担当者にループで電話をかけることが可能
    • 通知メールは全担当者にメール
    • 電話をかけない担当者も設定可能
  • 障害検知時の自動復旧コマンド投入
    • サービスに対応した自動復旧コマンドを投入することが可能
  • 選択可能な復旧モード
    • 電話を先にかける(通知優先)と、先に復旧コマンドを投入する(復旧優先)
    • この機能もクララオンラインからのリクエストで実装されました

このジョブフローを使い、クララオンラインのMSPサービスとして作り上げていきました。そのためには、実際の監視設定を適用していって課題になったことを、フィックスポイントに修正や改善をしていただいて対応する事が可能でした。狙い通り、導入する社内のリソースを最小限にリリースまでこぎつける事が出来ました。

現在のシステム構成はこんな感じになっています。

vo01

 

今日はこの辺で。次回は、クララオンラインのMSPサービスの導入前と後でどのように対応フローが改善されるのかをについてご紹介したいと思います。

 

 

Share on LinkedIn
LINEで送る
Pocket

吉村

吉村

クララオンライン グローバルビジネスストラテジー部でマーケティング担当として働いています。 クラウド関連技術と中国関連の情報をお届けしてます。 たまに DJ とかします。日本語RAPが大好きです。