【運用自動化コラム】第1回

今から始める自動化

まえがき――自動化ってなに？――

近年、クラウドやビッグデータなど大量のサーバを必要とするシステムの構築の労力を、「自動化」で軽減するのが流行です。このような自動化を実現するソフトウェアとして真っ先に上がってくるのはChefやPuppet、AnsibleなどのOSS（オープンソースソフトウェア）ですが、一方で、環境構築の運用自動化だけにとどまらず、システムの障害対応や日常の運用業務全般を自動化する汎用性の高い商用自動化ソフトウェアも注目を浴びています。

それぞれ特徴や機能に違いがあり、選定するのは悩ましいものですが、それよりも恐らく、多くの情報システム部門の方々が自動化によって業務改善を行う際に頭を抱えるのは、自動化というキーワードで自分たちの業務を見たとき、「何を自動化したらいいのか？」「どのように自動化を進めるべきなのか？」という事ではないかと思います。

本コラムでは、そういったお客様の悩みに応えるべく、商用自動化ソフトウェアを主体に、どのように自動化を進めるべきかを考えてみたいと思います。

商用の自動化ソフトウェアとその特徴

自動化をどのように進めるべきかを語る前に、商用自動化ソフトウェアの共通した特徴を少しだけ説明させてください。

商用自動化ソフトウェア、たとえばHPE社の「Operations Orchestration（HPE OO）」や、日立製作所の「JP1/Automatic Operation（JP1/AO）」などが有名ですが、これら多くの商用ソフトは、手順化された作業（オペレーション）を１つずつ処理パーツに置き換えて「自動化フロー」と呼ばれるものを作成し、管理サーバ上から実行することを「自動化」と呼んでいます。

それだけなら自動化というのは単なるジョブ実行のように思われますが、これらの自動化ソフトウェアの優れている点は、処理パーツの種類が非常に豊富なのと、様々な判断や分岐を増やすことができる柔軟性にあります。このような柔軟性と、直感的に素早く自動化フローを作成できる機能の豊富さが、様々な企業ごとに異なる運用の自動化を可能にするものなのです。

何を自動化するか？　を考える

まずは「何を自動化するか？」、自動化を行う運用業務の選び方、自動化のやり方を考えてみましょう。

いまこれを読んでいる読者の方が思い浮かべるシステム運用で、もっとも稼働を押し上げている作業はなんでしょうか？ 仮想環境の自動構築、障害の一次対応、定常作業の実行……様々な作業がイメージされるかと思いますが、やはりなんといっても自動化したいのは「長時間を要する作業」「複雑な判断を要する作業」ではないでしょうか。

これらの作業を自動化することは効果があるように思われます。理想的な自動化とは、そうした手間のかかる作業を完全に人の手をわずらわせることなく、コマンドの実行や様々な処理、判断がすべて自動化フローの中のパーツに置き換わり、オペレータは定期的に実行される自動化フローの実行の結果だけを受け取るだけ、というものです。

しかし、実はこれらの作業を自動化するのは困難な課題が伴います。

そのもっとも大きなものは、長時間の業務を自動化フローに置き換える時、「異常が出た場合にどうするか」を定義する手間がかかる、ということです。

手順書に隠れている「人間の判断」

もう少し詳しく考えてみましょう。

通常、自動化フローを作成するにあたり最初に見る資料、それは、自動化のターゲットになる作業の手順書です。手順書に書かれた操作ひとつずつを自動化ソフトウェアが提供する処理パーツに置き換えることができるか・できないかを調査することが最初のプロセスになるのですが、その場合、手順書に記載されていない操作や判断をつい見落としてしまうことが往々にしてあります。

たとえば、操作の失敗と、その失敗時の対応を考えてみましょう。

人間が手動で操作を行っている時、ある処理を失敗したり、エラーが表示された場合に応じて「ただちに操作をやめる」「関係各所にエラー内容を記載したメールを送信」「復旧処理を行って再実行」「無視して続行」など、ケースに応じて様々な判断と操作を行っているはずです。

しかし、多くの手順書では、ある特定の（予期されるエラーの）部分を除けば、作業全般の起こるかもしれないエラーや失敗全部の対応まで細かく記載していないものがほとんどです。（その理由の大半は「少しでもおかしな動作を起こしたら操作を止めるのが当たり前」、「連絡するのが当たり前」というのは、IT運用を行う人間としての基本動作だからでしょう） ところが、自動化はそうはいきません。人間にとって当たり前の判断、当たり前のエラー対応であっても、何を、誰に、どうするか（あるいは、何もしないか）は、大きな設計上の課題として、一つ一つ定義し、設計する必要があります。

もちろん、このようなエラー対応の自動化も、商用ソフトウェアではお手の物です。多くのメーカーではエラー発生時にメールを送信したり、警告メッセージを画面に表示したり、監視ソフトウェアと連携する操作の自動化パーツを提供していますし、パーツが無い場合でもカスタマイズ可能です。

しかし、そのようなカスタマイズが大量に発生する場合、エラー対応の処理パターンが大量に存在する場合はどうでしょう？ そして、自動化フローを作成する場合、これら一つずつに要件定義や設計を行い、書類に残す必要があるでしょう。エラーごとの自動化フローの動作テストを行う必要もあります。

このように、効果の大きな自動化は、コストやリリースまでの時間も大きくなりがちであり、時として困難な場面に直面することがあります。

さて、このような問題が生まれたとき、どのようなアイデアが有効でしょうか。

エラー発生時の対応方法は絞る

たとえば、エラーが発生した時は、一部の重要な部分以外すべて同じ警告メッセージをメールする、といったように、対応動作を複雑にせず、また、仕様を統一すれば、検討やドキュメント作成、作成後のテストの時間は削減できるでしょう。

ただし、警告メッセージを出力するだけにとどめた場合でも、メッセージを処理ごとに変更する、人間が理解しやすいようなメッセージに作り変える、といった要望が発生する場合、それぞれの処理の失敗の理由やその意味を理解する作業や、そうしたメッセージの一覧を作成し管理する必要が生まれることに注意して下さい。

「全自動化」より、「部分自動化」を目指す

理想的な自動化とは、「自律的な全自動化」です。しかしここであえて、作業全体の工程のうちいくつかを自動化するだけでも効率が良くなるのではないか、という視点で考えてみてはいかがでしょうか。

たとえば長時間の作業の中でも最も時間がかかる部分や、複雑な判断の作業の中でもオペレーションのミスが発生する部分などの、重要で、技術的にも比較的自動化し易いところから自動化を行うのです。

（次回はこのお話の続きを中心に、失敗しない自動化の進め方を述べたいと思います）

＜著者＞
谷川　晋悟

＜経歴＞
プログラム開発やインフラシステム運用の経験を活かし、お客様の自動化要求に対するコンサルティング業務を担当。現在は、仮想化基盤（プライベートクラウド）の自動化案件に対する提案を中心としたプリセールスエンジニアとして従事。AIS認定 HP Operations Orchestration資格保有。