はじめに

読者のみなさんのなかには，Java EEアプリケーションサーバを基盤とした業務システムに関係されている方も多いことでしょう。構築する立場，運用する立場，業務アプリケーションを開発する立場，構築されたシステム上でサービスを提供する立場，あるいは提供されるサービスの利用者として。

いずれの立場においても，システムトラブルは避けたいものです。なかでもシステム提供側の関係者の方は「トラブルを避けて通りたい，早期に解決したい（してほしい⁠）⁠」との思いが特に強いのではないでしょうか。業務システムを安定稼働させるために，クラスタ構成などによる信頼性の向上，開発フレームワークや開発方法論を活用した業務アプリケーション品質向上のための取り組み，統合運用管理製品などを用いた高品位な運用の実現など，多くの時間と手間を掛けてきたわけですから。

身近に潜むシステムダウンの要因

サービスイン後，業務システムが残念ながら障害によって停止したとします。前節で触れたような，安定稼働のための対策は講じていましたが，それは「想定される障害に対する備え，アプローチ」であり，それだけではカバーしきれなかった障害原因があったことが推測できます。

その推測は，Gartnerグループの調査報告によって，推測ではなく統計的にも正しいことが説明できます。システムダウンの原因の約40%が運用ミスによるもの，約40%がアプリケーションの不具合（バグ）によるものと報告されています。すなわち，システムダウンの80%が，人が介在している「人的要因」であることがわかります。ここで，2つの不幸なケースを考えてみましょう。

ケース1

開発チームが納期と品質向上に追われながらも業務アプリケーションを商用システムにリリースした。しかし，運用チームによるデプロイ（配備）ミスが原因でシステムダウンに陥った。すでに業務データは不完全な状態で完結しており，関連データすべての解析・復旧のため，開発チームに総動員の号令が掛かった。業務アプリケーションに不具合はなく，正しくデプロイしていれば発生しなかった問題である。

ケース2

システムの業務アプリケーションの保守と運用に精通したメンバーが，そのシステムから離れることとなった。あるとき，後任のメンバーによる単純なデプロイミスが原因で業務システムを停止させてしまう。お客様から，人的要因によるデプロイミス防止対策を求められ，システムへの作り込みを追加で行うことで対処した。割いた工数は小さくなかったが，作り込みは嫌いではないし，再発防止のためには仕方がなかった。ただし，業務アプリケーションの機能強化ではないので，費用は自部門が負担した。

みなさんの周りではいかがでしょうか。人手に頼っている，ノウハウ（のみ）によって成立している「危うい領域」はありませんか？ 可能な限り俗人性を排除して，人的要因による障害が起こらないよう障害が発生する前に何らかの「しくみ」をもって対策すべきと考えます。

そこで本稿では，予期せぬ障害の引き金ともいえる人的要因に着目したしくみによって業務システムを安定稼働に導くためのアプローチを紹介します。

人的要因へのアプローチ

人的要因に起因するトラブルに対して，弊社のミドルウェア「MCOne」によるアプローチを紹介します。MCOneとは弊社が提供する，Java EE向け業務構築運用基盤製品です注1。

デプロイ運用ミスは防止できる

まずアプリケーションのデプロイに関して考察します。サーブレット，JSP，EJBといった，Java EE環境で使用するアプリケーションをアプリケーションサーバ上で利用するためには，デプロイ（配備）といった作業が必要となります。デプロイを正しく行わなければ，アプリケーションを正常に稼動させることはできません。しかしながら，実際の，特に大規模なシステムではデプロイのミスは発生しがちです。

アプリケーション配備の問題

Java EE環境ではアプリケーションを実行するために，一般的に，アプリケーションをEAR，JAR，WARといったアーカイブファイルに格納し，これらのアーカイブファイルを適切なアプリケーションサーバのインスタンスに配備する必要があります。

アプリケーションサーバのノードには複数のアプリケーションサーバインスタンスが稼動していることも多いので，この配備先はサーバ台数よりも多くなりがちです。このため，アーカイブファイルの数が膨大であったり，アプリケーションサーバの台数が多い場合，これらの作業をアプリケーションサーバごとに手作業で行っていると作業ミスを起こす確率も高まります。特に，アプリケーションの配備は最初に一度だけ行えばよいというわけではありません。実システムではサービスイン後でも，バグ修正や新サービス対応のための機能追加，サーバ追加・統合などのハードウェア構成変化などに対応するために，何度も行うことがよくあります。