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

事例から考える自動化

前回のおさらい

前回のコラムでは、「失敗しない運用自動化」と題して、運用自動化をすすめるに当たってのポイントを書いていきました。

理想的な場所にたどり着くためには段階的にステップアップすることが成功の鍵であるというのは自動化に限らず多くのITソリューションの要ではありますが、では実際に、自動化においては具体的にどうするか、となると一筋縄ではいきません。そこで今回は、弊社での事例をもとにして、具体的な自動化についての進め方をご紹介します。

※なお、内容については一部フィクションを含みます。

▼過去のコラムはこちら
運用自動化コラム 第1回　今から始める自動化
運用自動化コラム 第2回　失敗しない自動化とは

シナリオ「大量にやってくるメールをどうにしかしたい」

あるお客様の運用チーム（サービスデスク）では、高負荷・多残業が常態化していました。この原因を追究したところ、とりわけ時間を費やしているのが「障害対応」であることがわかりました。

通常、お客様では次のような流れで障害の一次対応を行われています。

1.監視ソフトがイベントを検知し、メールで運用チームに通知する。
2.運用チームはメールを受領し、本文や時刻、システム名称などを確認する。
3.運用チームはこのメールが障害か一過性のものかを判定する。
4.障害であれば機器にログインしてログ確認や、上級エンジニアにエスカレーション、待機系への切り替えなどを実施する。対応不要なものは無視する。

さらに調査したところ、この監視ソフトからは毎日、数百～数千通という大量のメールが送信されていることが分かりました。
どうやらこの監視ソフトからのメールの判定に時間がかかっているようです。

監視設定を見直すことができれば改善されるかもしれませんが、（よくある話ですが）組織としての問題やその他の都合から、見直しは容易に進みそうにありません。解決策としてすでに何度か人員増を行いましたが、実態としてはなかなか効果が表れず、さらなる改善策として、監視検知から一次対応までの自動化を検討されていました。

目標の共有

当初の打合せでは、やはり理想的なイメージとして「運用自動化ソフトと監視システムとを連携し、全自動で判定と対応を行い、運用チームの関与をゼロにする……」という話が持ち上がりました。

しかし、すべての障害対応を自動化するとなると、数百、数千に及ぶシステムの監視項目と、それに対応した処理をひとつずつルールとして定める必要が出てくるわけで、これは非常に困難な道のりです。

また、運用自動化ソフトと監視ソフトとを直接連携する試みも、技術上のリスクが発生するため、現実的でないという結論が出ました。

その結果、以下のような方針が策定されました。

1.全自動化は、継続的な自動化を重ねる事で到達する「最終的な目標」として掲げる。
2.まずは運用チームの負荷軽減、稼働の抑制を第一として、部分的でも効果が高く即効性のある自動化を狙う。
3.技術的には監視ソフトから送信されるメールの文面から、対応の要否を決める判定と、そこからの一次対応について自動化を進める。

アセスメント（自動化分析）の実施

次に「効果的な自動化」を考えるための分析、アセスメントを実施しました。具体的には、お客様が月次レポートなどで蓄積していた過去の障害の対応履歴をデータ化し、傾向を分析します。

その評価軸は次のようなもので考えることにしました。

①イベント別の頻度

「よく起こる障害（イベント）」と「めったに起きない、レアな障害（イベント）」の仕分け。

この調査によってお客様の環境で起こる事象を月間でランキングしてみると、起こっているイベントの1位と2位は、特定の「対応不要」の通知で、これが全体の通知の半数以上を占めていました。また、3位以下の対応が必要なものも類型的なものが多く、レアケースの障害は年に1度どころか今までに1回しか現れていないものが多数存在しました。

②障害対応の重要度

「迅速に行わなければならない重要なもの」と「急がなくてもよい、軽微なもの」の仕分け。

これは[1]と連動するものかもしれません。実際に確認をしてみましたが、迅速な対応が必要になるのは少数で、ほとんどの事象はメールの確認のみで終わるものでした。

③障害対応の難度

「オペミス（オペレーションミスの略）をしやすいもの」と「簡単なもの」の仕分け。

お客様運用チームの方々から何が難しいのかをヒアリングしましたが、ここで出てきたのは、「対応が必要な障害については、メールの判断が難しく、しかも対応も難しい」という事象の存在でした。

また、月次レポートなどで報告されたオペミスの報告も調べてみましたが、件数として圧倒的だったのは、「エスカレーション漏れ」のオペミスでした。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

これらの調査を行った結果から、私たちは以下のような結論に達しました。

・稼働を押し上げ、負荷を高めている原因は、障害発生時に大量に通知される、特定の「対応不要」メールの判定作業である。

・対応不要メールの判定は簡単だが、数が多いため注意力が落ちてしまい、本当に対応が必要な障害メールの判定を誤ってしまう。

結果、エスカレーション漏れというオペミスが発生している。

次に「ナレッジ管理台帳」を確認しました。

「ナレッジ管理台帳」とは、メールの文面から障害を判定するルールと、その判定結果から対応するべき処理の手順が「ナレッジ」として記載されているものですが、長年の運用の結果、これらが大量に存在していました。

ナレッジが沢山あるというのは良い事のように見えますが、メール判定のルールが増えるという事は、1件のメールに対してのルールの照合も増えるということです。

このような場合、判定を人の力で手早く照合するには「よく発生する障害」の傾向をつかむ必要が出てくるため、ある程度の経験が必要になることがわかりました。「増員をしても効果が表れない」という原因はここにあったのです。

自動化フローの要件定義と作成

さて、以上までのアセスメントで、大まかに何を自動化すればよいかが見えてきました。目標が見えてきたら、それらの自動化が技術的に可能かを判断します。事例では、次のような2つの自動化のフローを作成する要件定義をお客様と共に行いました。

監視メールの自動判定フロー

この自動化フローは、以下のような動作をするものです。

1.監視ソフトからのメールを定期的に受信し、文面や発生時間などの情報を取得する。
2.[1]の情報から、そのメールが対応不要のものであるかを判定する。
3.対応が不要な場合は、件名に「対応不要」の文字を追加し、運用チームに転送する。それ以外の場合は、そのまま何もせず転送する。
4.運用チームは、転送されてきたメールを、メールクライアントの振り分け機能を用いて「対応不要」の件名のものを除外する。
5.運用チームは、転送されてきた「対応が不要ではない」（対応が必要と思われる）メールのみを確認し、ナレッジから対応を検討する。

なお、このフローを作成する際、すべての対応不要なメールを判定するようなルールを一度に作るのではなく、現時点でもっとも多く通知の来る（ランキング1位と2位の）イベントの判定ルールを作成することにしました。（手早く実装でき、しかも効果が高い）

一次対応自動化フロー

このフローは、【監視メールの対応不要判定フロー】から転送された、対応が必要と思われるメールから、時間のかかる、オペミスが起こりやすい作業を自動化するフローです。このフローの実行判断は複雑なため、無理に自動化しようとせず、オペレーター（＝人間）が行うようにします。

効果の測定と今後のプラン

結論から言うと、この自動化フローを作成したことにより、お客様では大幅な稼働が削減可能になりました。とりわけ対応不要メールの判定と除去は非常に効果的で、運用チームは大量の障害が発生しても対応が必要な問題にのみ集中して取り組むことが出来るようになったとのことです。

現在、お客様では削減できた稼働をさらなる自動化改善に向けられています。具体的には最初に作った2つの自動化フローを拡張させてお互いを接続する、すなわち、「対応不要かを判定する」だけでなく、「特定の対応が必要かを判定したら、その対応作業の自動化フローを呼び出す」機能を実装することで、将来的な完全自動化を目指されています。

おわりに：部分的な自動化の課題と対応

このように、部分的・段階的な自動化は即効性の高いものですが、デメリットも存在します。

第2回で記載した自動化の進め方は、いわゆる「アジャイル開発」に限りなく近いものです。社内の変更承認プロセスが複雑で、小刻みな自動化による改善修正が認められない場合、こうした内容は絵空事になることも多々あるでしょう。

また、手順書などのドキュメント修正も頻繁に発生するため、デメリットがメリットを上回る場合もあります。

さらに、「自動化できるところから行う」という自動化は、得てして「虫食い」になってしまいます。手動と自動が交互に入り混じった対応は、操作を行うオペレータにとっては混乱する可能性も出てくるかもしれません。

このように細分・断片化された運用業務（操作や処理）については、混乱なく、一つの順序として人間がわかりやすく管理する方法が別に必要になります。

さて、次回のコラムでは担当者が替わり、これら自動化の部分的・段階的な導入にかかわる手順の管理と非常に相性の良い運用支援ツール「Navigation Platform」についてご紹介します。

＜著者＞
谷川　晋悟

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