月別アーカイブ: 2016年9月

自動化の手順書はどう作るか?

2016年9月30日

ワイドテックプロダクト企画担当のYです。

運用自動化ツールを指して「Runbook Automation(ランブック・オートメーション、手順書による自動化、ランブック自動化などの日本語訳あり)」、略して「RBA」という呼称がよく使われています。Runbookとは「手順書」を指します。

POLESTAR Automationを含め、RBAでは手順書を元に運用作業の自動化を行います。逆に手順書がない状態では、何もできません。

では、その手順書はどうやって作るのでしょうか。今回はRBAにおける手順書の作成についてご紹介して行きます。

RBAと手順書

何か決まった内容の業務・作業を、第三者が見てもその通りに実施できることを趣旨として、何か決まった内容の業務・作業を実施するための手順をまとめたのが、私たちが普段イメージする「手順書」でしょう。

運用自動化ツールにおける手順書は、ワープロソフトで手順書を作る要領で、手順を文章で箇条書きにして書いて行くわけではありません。作業は人ではなくコンピューターが行うわけですから、コンピューターが認識できる言語、つまり「プログラミング言語」を使って書かれることになります。

世間には既に多種多様な運用自動化ツール・ソリューション製品が提供されていますが、弊社のPOLESTAR Automationのように商用(有償販売)で提供している製品以外に、オープンソースのものもいくつか存在しています。その多くは、プログラミング言語に近い独自のスクリプト(書式)、ないしはプログラミング言語そのものをスクリプトとして利用し、手順書を書いて行くことが前提になっています。

自動化製品のお客様にヒヤリングしてみると、Perl、PHP、Ruby、Pythonといったプログラミング言語でそのまま手順書を書けることをメリットと考えているケースもありました。オープンソースのRBAの多くが当てはまります。しかし、運用のプロフェッショナルがプログラミングの知識を兼ね備えている例は、そう多くありません。となると現場で導入しやすいのは、できるだけプログラミング言語に頼ることなく、手順書をなるだけ簡単に作って適用できる製品、ということになります。

大まかに言って、商用製品ではオープンソースに比べ、手順書の作成過程をGUIなどの導入によって簡素化することに力が注がれており、そこが商用製品のオープンソースに対する差別化ポイントとなってもいます。

POLESTAR Automationでは、GUI上で目的に応じた手順書(「ジョブ」と呼んでいます)をウィザード形式で必要事項を入力して行く方式で、手順書を作成できるようになっています。またはシェルスクリプトやWindows PowerShellなどで提供される既存の業務テンプレートのプロパティを、自社のシステム構成に合わせて修正・適用することも可能です。

また、他社製品の中にはアイコンをドラッグ&ドロップして行き、プログラミングでいうフローチャート(流れ図)を作成する要領で、アイコンの間に線を引くことで手順書を作成できるものもあります。

GUIは万能ではない?

ところで、このコラムをお読みの方の中には、Webサイトの構築、Webページ(ホームページ)の作成経験をお持ちの方もいらっしゃるかもしれません。Webページは「HTML」という書式で作成されていますが、HTMLとはHyper Text Markup Languageの略で、言語を意味する “language” の語が含まれています。つまり、広い意味でHTMLもプログラミング言語の一種といえます。

初期のWebページは、文章にテキストエディターで直接、「タグ」という画面に出てこない書式情報を埋め込んで行く、いわゆる「手打ち」で作成していましたが、後にワープロソフトのごとく、WYSIWIG(画面上での編集がそのまま結果に反映される)タイプのWebページ作成ツールが出回るようになりました。凝った作りのWebページが増えるにつれて手打ちでは間に合わなくなったこともあり、今では趣味のWebページ作成者からプロのWebデザイナーに至るまで、そうしたWYSIWYGツールを利用するのが一般的になりました。

しかし、文字や画像を数ドット上げたり下げたりとか、左や右に寄せるとかといった細かい調整となると、HTMLやCSS(スタイルシート)のテキストソースを直接参照・編集して行う方が手っ取り早いケースも多く、今も昔もHTMLタグやCSS書式についての知識は欠かせないといえます。

GUIを使った手順書の作成も同様で、GUI上でのドラッグ&ドロップや線引きだけで、手順書が完成するわけではありません。IPアドレスやディレクトリ情報をはじめとして、手作業で入力すべき情報は数多く、ネットワークの構成や、自動化ツールからシステムを操作するのに必要なOS/ネットワークコマンドなど、それなりの知識はどうしても求められます。加えて、自動化を無駄なく、より効率的に行うために手順書の最適化を行うには、自動化スクリプトを手打ちできるレベルの知識が求められることもあるでしょう。

結局、Webページ同様、GUIツールでの手順書作成といっても、スクリプトの知識が全くない状態では難しいといえそうです。

導入してすぐに使える「Enterprise RBA」

POLESTAR Automationは「Enterprise RBA」を謳っています。

運用業務の豊富なノウハウと経験が活かされた、導入してすぐに適用できるレベルの手順書を最初から取り揃えて提供しようという考え方、つまり最初から運用自動化のベストプラクティス提供を目指し、導入のハードルを可能な限り下げようというコンセプト、それがEnterprise RBAです。

ある自動化製品では、とにかくテンプレートが豊富であることを謳っています。その数、なんと数千種類。確かにテンプレートをうまく組み合わせれば、自動化の枠組みを手軽に組み立てていくことができます。しかし、実際に各々の運用現場で必要とされるテンプレートの種類というのは、そのうちせいぜい数十種類ではないかと思います。

POLESTAR Automationのテンプレートは、量よりも質と実用性を重視して作成・提供しているものですので、簡単な手直しだけで業務に適用し、本格的な運用自動化を手軽に行うことが可能です。

Enterprise RBA – POLESTAR Automation、一度トライしてみませんか?



運用自動化ツールって何?

2016年9月30日

ワイドテックプロダクト企画担当のYです。

弊社で初めて運用自動化ツールの事業企画に着手したのは、約2年前に遡ります。その間、技術的検討と並行し、市場調査も進めてきましたが、企画着手当初ズブの素人だった自分が業界や市場を調べる上で当初悩まされていたのが、市場に出回っている数多の運用管理製品のうち、「運用自動化ツールって、いったいどの製品?」ということでした。

今回は運用自動化ツールのアウトラインを理解する上で欠かせない市場状況、ジャンル分けなどについてご紹介します。

(2022年9月27日追記)こちらの原稿を公開してから6年の時を経て、新たに「2022年最新バージョン」を公開しました。なんとこの記事を執筆してからもう6年が経っていました。早いものです。最新版では運用自動化のマーケットやツールがどのように変化を遂げているのかをめぐりながら、改めて「運用自動化」について考えています。「2022年版 運用自動化ツールとは?」もぜひご参考ください。

運用管理製品と運用自動化ツール

現在、IT製品市場全体において、運用自動化ツールというのは運用管理(システム管理)製品の1ジャンルと位置付けられるのが一般的です。つまり、運用管理という大分類のもとに、小分類としての自動化ツールの市場が存在しているわけです。

国内シェア上位の各ベンダーの場合、もともとNMSのようなシステム監視機能中心のツールからスタートし、後にジョブスケジューラやIT資産管理、そして自動化へとラインナップを拡張して行ったためと考えられます。自動化ツールは運用管理分野にあって、最も新しい市場といえます。

とある運用管理製品のシェア調査によれば、国内では上位の3社だけで市場の65%を占めている、いわば寡占状態にあるそうです。そんな寡占市場に、弊社が新規参入して勝ち目はあるの? と、社内でも疑問の声が上がったものですが、65%というのはあくまで運用管理製品という大分類全体での話であり、自動化に絞って見てみると、事情は異なるようです。

大手のSIerさんからお聞きした話では、シェア上位の運用管理製品の新規導入案件で、同製品のラインナップに自動化機能が含まれているにもかかわらず、自動化については別の製品を組み合わせて提案するケースが結構あるそうです。

つまり、運用管理全体では寡占市場ながら、自動化製品のシェアについては、必ずしも同様な寡占は起きていない、ともいえます。

ジョブスケジューラと運用自動化ツール

IT運用自動化、英語で「RBA(Runbook Automation)」とか「ITPA(IT Process Automation)」といった用語が登場したのは比較的新しく、2000年代も半ばに入ってからのことですが、RBA登場以前から運用業務の省力化を目的に広く使われていた「ジョブスケジューラ(ジョブ管理ツール)」は、メインフレームからの長い歴史を持っています。

運用の現場に携わっている弊社の外勤社員にヒヤリングしてみると、「自動化ツールは触った経験がないけど、ジョブスケジューラなら日常的に触っている」という例が少なくありませんでした。

ジョブスケジューラの役目は、「ジョブ(仕事)」として定義される作業を、あらかじめ定めた日時や頻度・間隔で実施することにあります。ある条件でのみジョブを動かしたり、逆に定期的に実施しているジョブを特定の条件では行わないようにしたり、といったジョブの例外的な制御も、一般に可能です。

運用自動化製品の中には、既存のジョブスケジューラがバージョンアップする形で自動化の概念を持つようになったものもあれば、同じシリーズ製品の中に、ジョブスケジューラと自動化ツールがそれぞれ独立して存在しているケースもあります。

POLESTAR Automationを含む商用の運用自動化ツールの多くも、こうしたジョブスケジューラの機能を持っていますが、ハードウェアやソフトウェアの状態を取得して構成・設定を変更したり、適切なコマンドを自動実行したり、リブートを掛けたり、といったところまでカバーし、多少なりともインテリジェントな要素を持ったものを、運用自動化ツールと定義することができると思います。

エージェント vs. エージェントレス

POLESTAR Automationでは、管理対象のサーバー(PC)ごとに「エージェント」というソフトウェアをインストールしていただく必要があります。

エージェントの役割は、サーバーの構成情報や稼働情報(CPU使用率、メモリやストレージの使用量、インストールされているアプリケーション…)をPOLESTAR Automationの管理サーバーでリアルタイムまたは定期的に取得できるようにしたり、必要に応じて管理サーバーから自動的に、または手動で送信されるコマンドを実行したり、ファイル配布を行ったり…といった、高度な自動化機能の実現に欠かせないものです。

一方で、他社の自動化製品には「エージェントレス」を謳うものがあります。文字通り、管理対象のPCにエージェントをインストールする必要がなく、サーバー側からの情報取得や自動化コマンドの実行を、SSHなどを使って行うものです。

エージェントを組み込むことで、アプリケーションのインストール状況を含めたより細かいPCの構成情報を把握し、不要・危険なアプリのアンインストールなどのコンプライアンス対策や、逆にアプリを含む各種ファイルの配布とインストールといった、より多彩で細かな制御を行うことができるようになります。管理対象のPCでエージェントソフトウェアのインストール以外に行うことは、基本的に、エージェントが通信するのに必要なTCPポートの開放だけです。

こうした機能の中には、エージェントレスでは実現できないものが少なくありません。POLESTAR Automationではエージェントを組み込む方式とすることで、多様な自動化機能をよりシンプルに実現できるのだとご理解いただければ幸いです。

エージェントが実現するPOLESTAR Automationの多機能

POLESTAR Automationは自動化ツールですが、ハードウェアの状態管理、OSのEOL管理やアプリケーションソフトウェアのインストール管理、コンプライアンス対策といった、監視ツールや資産管理ツールの領域に含まれる機能も実現しており、その多くにはエージェントプログラムが関与しています。

先達の各社様とは異なり、弊社では今のところ、運用管理領域においてはわずかなラインナップしか持っていません。そこで、日常的な運用に関する多くの業務を、POLESTAR Automationという単一のシステムで実現し、自動化可能とすることに注力しました。

既存の統合運用管理を導入済みながら、自動化はまだ、というお客様はもちろん、運用管理ツールを一切導入されていないお客様でも、POLESTAR Automationだけでかなりの運用業務負担を減らすことが可能かと思います。

POLESTAR Automation、きっと貴社の運用業務のお役に立ちます。

ぜひともご検討ください。



『なぜ今、自動化なのか?』プロローグ~運用の現場から~

2016年9月30日

はじめまして。ワイドテックプロダクト企画担当のYです。

POLESTAR Automation公式Webサイトの片隅で、運用自動化にまつわるコラムを連載して行くことになりました。更新は不定期になりますが、どうかよろしくお願いします。

初回は自動化の本題に入る前に、弊社がIT運用自動化製品を取り扱うに至った経緯を、簡単にご紹介します。

弊社の原点「NMSスーパーバイザーシステム」

弊社、ワイドテックという会社は、とある大規模なお客様のために開発した「NMS(Network Monitoring System、またはNetwork Management System)スーパーバイザーシステム」からスタートしています。NMSというのはネットワークの運用状況を監視・管理するためのシステムですが、巨大なデータセンターにおいては、ネットワークの規模が莫大なのはもちろん、NMS監視端末の数も非常に多くなり、1か所で管理するのは難しい状況でした。

そうしたお客様の課題を解決すべく、遠隔操作技術を応用し、複数のNMSを束ねて統合・集中的に管理するとともに、障害アラート機能などを連携させることで、ネットワーク障害の早期発見と迅速な復旧を目指したのが、弊社の開発したシステムです。統合監視がメインのシステムですが、自動化のコンセプトも含まれています。

しかし、NMSにせよ、弊社のシステムにせよ、操作するのは結局「人」です。障害の発見から通報までは自動で可能ですが、通報に気付いて障害からの復旧に至るまでの作業は、人がすべてやらなければなりません。自社システムの運用のため、そのお客様のもとに社員を常駐させたことが、結果的に技術人材派遣事業への進出となり、今では同事業が、弊社の売上のかなりの部分を占めるに至りました。

IT運用の現場体験で知った「属人化」の実態

このコラムを執筆しているのは、今回のPOLESTAR Automationの製品化にあたり、技術以外の実務全般を担当した、末端の一社員です。縁あってこの会社に入る前から、ずっとIT系の商品企画(主にBtoC、いわゆるコンシューマー畑)に携わってきたのですが、実はバリバリの文系(社会学部)出身で、各種の技術は上っ面でしか理解していません。しかし、現場が忙しくて人手不足の時にはそんな文系の自分ですら、ITサービスの運用現場に駆り出されるのが、この会社なのです。

とある現場で、文系でもできる手順書などの資料整理のお手伝いを担当しつつ、日常業務として従事していたのが「目視点検」です。毎日2回、朝と夕方にマシンルームにあるサーバー、ルーター、ネットワークスイッチ、ファイアウォールなどが正常に動作しているかどうかを、目で見て確認する業務です。

他に、毎日決まった時間に作業部屋のPCからスクリプトを走らせ、ネットワーク経由で各機器の稼働をチェックする業務もありました。点検用のスクリプトは自動で走るのですが、集計は手作業です。

連日、こうした作業の繰り返しです。決して難しい作業ではないのですが、来る日も来る日も同じ作業。正直、単調、退屈です。しかし、障害はいつ起きるかわかりませんから、決して疎かにはできません。

幸い、自分がその現場に出ていた間、大規模障害は発生しませんでしたが、ITサービスの運用現場においては、トラブルと100%無縁ということはありえません。何かあれば休日や、深夜の就寝中であるにもかかわらず、電話で現場に呼び出されて復旧対応に当たったというインフラエンジニアの経験談は、何度も耳にしました。しかも、そういう緊急対応に従事するのは、システム全体を理解し、1人で問題解決に当たれるレベルの、上級スキルを持つエンジニアであることが多いようです。

運用の現場においては、こうした上級エンジニアへの負担が非常に大きくなりがちです。知識と経験、そしてスキルを後進の人たちに伝え、個人への負荷を分散するためにも、行うべき業務をきちんと手順書にまとめておくことが重要でしょう。しかし、現実には業務に時間を割かれ、そうした手順書を書いたり、後進を教育したりする時間は取りづらいようです。結果、ハイレベルな業務ほど特定の人に依存しがちになってしまう、いわゆる「属人化」に至るわけです。

その人が病気になったり、何らかの理由で職を離れることになってしまったり…と考えると、なんだかゾッとしてきませんか?

エンタープライズRBA「POLESTAR Automation」が、運用業務を属人化から救う

「RBA(RunBook Automation=手順書による自動化)」という用語と出会ったのは、現場から本社に復帰してきて間もない頃です。手順書とか属人化とか日常点検とか、まさに自分がつい先日まで経験してきた数々のキーワードにピンと来たものです。

いろいろ調べて行くうちに、RBAこそが属人化を解決し、単調な日常作業の多くを自動化できる画期的な解決策、文字通りの「ソリューション」であると確信し、運用現場経験者の多い弊社の経験も活かせるプロダクトとして、商品化を目指して行くことになったのです。

日常点検のような、シンプルながら日頃の運用管理に欠かせない業務から、高度なスキルの求められる障害復旧手順まで、運用業務におけるさまざまな作業を手順書として記述しておけば、その通りに実行してくれる運用自動化システムがRBAです。しかし、前述のように多忙で責任も重い上級エンジニアには、手順書を書く時間がありません。そこで、想定される業務手順を可能な限りテンプレート化された手順書として提供し、そのまま、あるいは多少の手直しだけで適用できるのが、エンタープライズRBAソリューション・POLESTAR Automationです。

実は、このPOLESTAR Automationも、冒頭で触れた弊社のNMSスーパーバイザーシステムと同様、ある大規模顧客の運用自動化への要望に応じるために開発に着手したのが原点となっています。もちろん、性能や機能が優秀で使いやすいことが最優先なのですが、現場の声に耳を傾けてニーズを確実に汲み取り、ソリューションとして作り上げて行く開発元の姿勢に、同様な原体験を持つ弊社としても大いに共感し、共に事業を進めて行くことになったものです。

次回からは、運用自動化製品全般やPOLESTAR Automationについてのご紹介、そして、ひとつひとつのケースを掘り下げながらの自動化が必要な理由と、そのメリットについて書いていきます。