運用自動化の必要性
近年注目されているDevOpsは、アプリケーションを短期間かつ頻繁に開発・リリースし、ユーザーからのフィードバックを利用して改善を重ねることで、ユーザーのニーズに沿ったアプリケーションを提供するという取り組みである。
そのためDevOpsにおける運用（Ops）では、ツールを使ってインフラのデプロイを自動化することが求められる。またレスポンスタイムといったユーザーが体感するサービス品質を維持するために、手作業による対応だけでなく、オートスケーリングなどの自動化・省力化された対策が必要になる。
このようにDevOpsでは、アプリケーションの企画・開発段階から運用を考慮し、運用負荷を減らすためのインフラや自動化技術の利用が推奨される。そして運用（Ops）には、従来から言われているような安定稼働だけでなく、開発（Dev）と一体になったサービスの品質改善や運用自動化の推進という役割が求められる。
一方、Google社は従来の運用担当者に代わる新しい役割として、「Site Reliability Engineer」（SRE）を提唱している。これは、ソフトウェア開発とインフラ双方のスキルを備える技術者である。
SREは、自ら「運用の自動化」を開発する。これにより運用業務を効率化し、空いた時間でさらなる自動化の推進や先進技術の適用を進める。そして、できるだけ運用コストを削減して競争力を高め、サービスの信頼性を向上させ、最終的には自社の収益やブランド力強化に寄与することが求められている。
DevOpsやSREといった取り組みからもわかるように、昨今は運用に求められる役割が変化するとともに、運用自動化の必要性が高まっているのである。
RPAとRBAの運用自動化技術
IT運用では監視、ジョブ管理、バックアップ管理、サービスデスクなどのツールを利用して、プロセスの自動化を推進してきた。しかし、システム間をまたがる作業やデスクトップ操作などは、まだ手作業が中心である。これらの操作を自動化するツールが「Robotic Process Automation」（RPA）であり、「Runbook Automation」（RBA）である。
ここではまず、類似する運用自動化ツールと比較しながら、RPAとRBAの特徴を見ていこう（図表1）。
い歴史をもつツールとして、ジョブスケジューラがある。これは複数サーバーをまたがるバッチ処理を制御するもので、強力なスケジュール機能が特徴である。
一方、RBAは（一見すると、ジョブスケジューラに近いように思えるが）、人が手順書を見ながら実施していた作業を自動化するツールである。たとえば監視システムからのアラート通知を受けて、インシデントチケットを起票し、承認フローを回したあと、初期対応手順を実施するといった作業を自動化する。
構成管理ツールは2005年ころに登場し、Puppet、Chef、Ansibleといったツールが提供されている。これらはテキストファイル（コード）に構成情報を記述し、インフラの導入・設定を自動化するツールであり、コードでインフラ構成を管理する「Infrastructure as Code」を実現する。
RPAは、PCのデスクトップ操作を自動化する汎用的なツールである。GUI操作を自動化できるのは、RPAだけになる。
次に、こうしたツールの利用場面を見てみよう（図表2）。
クラウドでもオンプレミスでも、本番システムに対するアクセスは特定のユーザーに限定される。一般的には、IT部門の運用担当者および保守担当者である。また、本番のネットワークセグメントは高いセキュリティに守られており、物理的なアクセス制限を設けることもある。
前述のジョブスケジューラ、RBA、構成管理ツールはこうした環境下で、本番システムの操作を自動化するために利用される。またこの環境で使用されるPCのなかで、ジョブスケジューラ、RBA、構成管理ツール以外のデスクトップ操作で定型化が可能であれば、RPAにより自動化できる。
一方、保守担当者がオフィス・セグメントで実施する運用作業には、キャパシティや障害事象の分析・レポーティングなどがあり、多くの作業時間を要している。これについても定型化が可能であれば、RPAで自動化できる。
RPAとRBAの利用シナリオ
IT運用ではRPAとRBAの特性と違いをよく理解し、うまく使い分け、組み合わせることで、より効果的な自動化を実現できる（図表3、図表4）。
本番システムの操作には、多くの事前定義タスクがテンプレートとして提供されるRBAが優れている。テンプレートを利用することで、タスク処理の開発負荷を低減し、標準化や属人性を排除できる。たとえばファイル転送を行う、仮想マシンのスナップショットを取得する、Active Directoryのユーザーを作成する、tracerouteをかける、といった事前定義タスクが用意されており、タスクの定義または実行時にパラメータを設定することで、さまざまな場面で実行できる。タスク内容のカスタマイズや複数タスクをフローでつなぐことで、連携実行させることも可能である。
ただし、本番システムの操作でもGUI操作を伴うものはRPAでしか自動化できないので、RPAを利用する。また本番システムの操作以外でも、GUIを含むデスクトップ操作の自動化にはRPAを利用する。
ここで、RPAとRBAの双方を組み合わせたIT運用のシナリオ例を紹介しよう。図表5では、保守担当者による障害時の情報収集を自動化している。自動化前に、保守担当者は次の作業を実施していた。
・ インシデントチケットが通知されると、入室申請システム経由でコマンドセンター入室の承認を得て、コマンドセンターに入室する（①～⑧）。
・ 障害が発生したシステムにログインし、コマンドなどを実行して情報を収集する（⑨）。
・ 収集情報をオフィス・セグメントに持ち出して、Excelで加工・分析したり、Wordで資料を作成する（⑩）。その後、必要に応じて初期回復作業や恒久対策を実施する。
これらの作業をRPAとRBAで自動化することで、保守担当者は障害発生直後に対象システムから収集され、適切に加工された情報を迅速に入手できるようになる。
以下に、自動化後の作業の流れを示す。
・ インシデントチケットの内容（対象システム、障害箇所など）をもとに、事前定義された情報収集タスクを実行する（RBA）。
・ 収集情報を添付して、インシデントチケットを更新する（RBA）。
・ インシデントチケットの内容と収集情報をもとに、事前定義された加工処理を実施し、報告資料を作成する（RPA）。
・ 保守担当者に報告資料をメールする（RPA）。
・保守担当者は、報告資料をもとに状況把握や分析を実施する。その後、必要に応じて初期回復作業や恒久対策を実施する。
こうした自動化により、障害対応の迅速化、保守担当者や承認者の省力化、情報収集における操作ミスの削減といった効果が得られる。同様の方式で、「障害時の一時回復作業の自動化」や「イベント発生時のリソース拡張などの自動アクション」などのシナリオが考えられる。
RPAとRBAの適用アプローチ
自動化を推進するためのタスクの流れを、図表6に示す。
タスクの流れは、「PoC（1～3）」「ツール選定、システム構築（4～7）」「本番自動化の繰り返し（8～11）」「ユーザー教育／支援（12～13）」の4つのブロックに分けて考える。
PoC（2、3）では、迅速に効果が期待できるプロセスや作業を対象に選定し、自動化効果の確認だけでなく、ツールの難しさや限界、RPA／RBA化タスクで実施すべき作業内容やワークロードを各当事者が識別して、後続のツール選定や本番自動化に役立てることが推奨される。
また最も重要と考えられるのが、自動化ノウハウの蓄積（6、10、11、12、13）とユーザーへのフィードバックである。ここでは、ITサービスマネジメントにおける「ナレッジ管理」のプラクティスが適用できる。
以上、RPAとRBAの運用自動化技術および適用アプローチを見てきた。実際に運用組織に自動化を導入していくには、費用対効果の明確化や新たな投資が必要となる。しかしDevOpsが注目され、働き方改革による生産性向上が求められている今こそ、運用自動化を推進する大きなチャンスである。自動化にいち早く着手し、自社の自動化ノウハウを蓄積していくことが、他社との差別化要素になると考えられる。
著者｜伴 俊秀
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・イノベーション
シニアITスペシャリスト
1991年、日本IBM入社。監視やジョブ管理を中心にシステム管理分野での技術支援やプロジェクトでの設計・構築を実施。近年はインフラ運用設計や運用プロセス改善に携わり、ITサービス管理の価値をユーザーに提供するための取り組みを展開している。
