第10回 システム開発は最初に運用まで見通すべし：キーワードでわかるシステム開発の流れ（1/2 ページ）

せっかく作り上げたシステムも、動かなければ意味がありません。今回は、実運用してからのトラブルについて解説していたいと思います。

[高田淳志，株式会社オープントーン]

「アクセスできない！」――ログの重要性――

　「『インターネットショップ』はすぐには作れない」から前回の「テストで重要なのは見極めること」まで、「インターネットショップの開発」という仮想プロジェクトを題材として、新システムの構想・開発着手から開発完了までの間に登場するさまざまな技術キーワードを紹介・解説してきました。いよいよ最終話です。今回は、本番サービスが始まってから青木室長と赤井君が直面した2つの出来事を題材に、システム開発にとって準備作業や機能設計の段階から運用面へ配慮しておくことが、いかに大切かをお話ししていきます。

青木室長　「赤井君！　いま、お客さまから電話があって、インターネットショップへのアクセスが急にできなくなったとのことだ」

赤井君　「本当ですか？ おかしいですねぇ……。ここからだといまも普通にアクセスできますし、障害通知のメールも届いていないんですが……」

青木室長　「確かにアクセスできるねぇ。お客さまがいうには、昨日までは普段通り利用できたそうなんだよ。ところが、今日になって配送状況を確認しようとしたところ、何度試してもログイン画面から先に進めないそうなんだ」

赤井君　「ログイン画面にはアクセスすることができるけれど、その先の画面に進めないということなんですね」

青木室長　「あ、そうだな。そういうことのようだな」

赤井君　「青木室長、落ち着いて考えてみましょう。原因は必ずしもインターネットショップのシステム側にあるとは限らないんですよ。ひょっとしたらお客さまがログイン・パスワードを間違っているのかもしれないし、お客さまが使用しているパソコンの設定が変わったことが原因かもしれません。正確に聞いてもらわないと、いつまでも解決できませんよ」

青木室長　「いや……、それが……、てっきり……」

赤井君　「ともかく、まずはサーバのログを確認してみます」

　青木室長を残し、操作端末へと向かう赤井君。

　Webブラウザでアクセスする形態のシステムの場合、利用者側のパソコンに、そのシステムを利用するためのソフトをインストールする必要がないことがほとんどです。そのため、一般的に利用者のパソコンの状態によってシステムは影響されにくいのです。

　それでも、すべての利用者がまったく同じ中身（WindowsのOSやWebブラウザの種類、バージョンなど）のパソコンを使用しているわけではないため、利用環境や設定内容に起因したトラブルが発生する可能性はあります。

　そのようなトラブルの解決手段として、「システムが出力するログ（記録）」の活用が大切になるのですが、前の青木室長と赤井君はシステムログを基に、今回のお客さまの状況を把握することができるでしょうか？

　多くの方が使用しているWindows OSでは、どのようにログが記録されているでしょうか。

　Windows OSには、各種アプリケーションやセキュリティ面についてのイベント（出来事）を記録する『イベントビューア』というアプリケーションが用意されています（画面1）。

画面1　Windows系OSのイベントビューアの画面の例。この画面はWindows ＸＰのもの

　画面1では、「アプリケーション」という分類に属するイベント情報が、「エラー」「情報」「警告」などの種類ごとに表示されていることが分かります。では、これらの区別はどのようになっているのでしょうか。

　この点については、マイクロソフトのWebサイトに、次のような説明がありました。以下の文章は、編集したうえで掲載しています。

エラー	データや機能の損失などの重大な問題。例えば、起動中にロードに失敗した場合、エラーのログが記録されます。
警告	必ずしも重大ではないが、将来的には問題となる可能性のあるイベント。たとえば、ディスク空き領域の減少時に警告のログが記録されます。
情報	アプリケーション、ドライバ、またはサービスの成功した操作について説明したイベント。例えば、ネットワーク・ドライバのロードに成功した場合、情報イベントが記録されます。

　このような説明を読むと、エラーや警告という分類で出力されたログの内容は、「何か重大な問題が起きている、調査しなきゃ」と判断すべき情報のようです。

　一方、情報という分類で出力された内容についてはどうでしょうか。説明によると「成功した」操作についての記録ということなので、異常事態として対応が必要な出来事を示しているのではなく、何かに備えて念のため記録しているものであることが分かります。

　さて、Windows OSの場合、このようにイベントの種類分けがされてログとして記録されていることが分かりました。インターネットショップのようなサイトの場合もログが重要であることは間違いありません。むしろ、不特定多数の利用者がさまざまな利用環境からサイトを利用するという特性から考えると、ログがより重要なものとなります。

　障害などの異常な出来事の発生だけでなく、前のイベントビューアの種類である情報で出力されるような正常に完了した処理記録はされているか、または出力情報はきちんと分類されて体系化がなされているかということが、そのまま運用のしやすさへとつながっていきます。

　前述の青木室長、赤井君に寄せられたお客さまからの問い合わせの原因を、ログを基に調査することにします。

ログの内容その1

……（省略）

[2008/05/22 11:19:31] [IPアドレス=100.XXX.XXX.103] ログイン画面へのアクセス成功

[2008/05/22 11:19:42] [IPアドレス=100.XXX.XXX.103] ログイン認証失敗（ユーザーID：hanahana　パスワード不正）

[2008/05/22 11:19:55] [IPアドレス=100.XXX.XXX.103] ログイン認証失敗（ユーザーID：hanahana　パスワード不正）

[2008/05/22 11:20:07] [IPアドレス=100.XXX.XXX.103] ログイン認証成功（ユーザーID：hanahana）

[2008/05/22 11:20:09] [IPアドレス=999.XXX.XXX.996] ログイン画面へのアクセス成功

[2008/05/22 11:20:17] [IPアドレス=100.XXX.XXX.103] 商品一覧画面へのアクセス成功

[2008/05/22 11:20:34] [IPアドレス=999.XXX.XXX.996] ログイン認証成功（ユーザーID：yamayama）

……（省略）

　お客さまからのヒアリングでは、次のことが判明しています。

• ログイン画面にアクセスしたのは5月22日の11時20分ごろであること
• そのお客さまのユーザーIDは「kawakawa」とのこと
• IPアドレスは「550.XXX.XXX.553」であること

　さっそくログを確認してみると、ログにはヒアリング結果に該当するアクセスの記録が存在しません。とするとこのお客さまは、サーバにアクセスすらできていない状態にあり、にもかかわらずログイン処理を行おうとしているために、インターネットショップを利用できていないのではないかという推測にたどり着くことができます。

　一方、もしもこのログが成功した操作の記録を取らず、異常操作だけを記録するような作りになっているとしたらどうでしょう。先ほどのログ記録の例から、正常な動作の記録を取り除き異常操作の記録だけにすると、次のようなログ内容となります。

ログの内容2

……（省略）

[2008/05/22 11:19:42] [IPアドレス=100.XXX.XXX.103] ログイン認証失敗（ユーザーID：hanahana　パスワード不正）

[2008/05/22 11:19:55] [IPアドレス=100.XXX.XXX.103] ログイン認証失敗（ユーザーID：hanahana　パスワード不正）

……（省略）

　このログでは、問い合わせを受けたお客さまだけでなく、IPアドレス[999.XXX.XXX.996]からアクセスのユーザーのアクセス記録もここまでのところでは確認することができません。

　インターネットショップのサイトにすらアクセスできていないユーザーと、すべての機能を操作ミスなく利用しているユーザーの区別がつかない状態になっています。ということは、インターネットショップ側のトラブルかもしれないし、お客さまの間違いかもしれない、そんなあいまいな状態のまま解決を目指さなければいけない状況が生じます。そのため、お客さまとのやりとりが増え、解決までの道のりが長引くことは間違いありません。

　どのようなログ出力を行うかという仕様は、設計内容の確認時には見落とされがちな（もしくは重要視されないことが多い）部分のようです。

　しかしながら、開発作業が1年ほどで終わるようなシステムであっても、その後の運用は何年も続いていくわけですし、障害発生時の復旧時間を短縮すること、平均故障間隔の長い安定したシステムを構えることは、素早いビジネス展開を維持し続けるうえで重要な要素です。

　ですから、要件定義書や設計書のレビュー時に、画面などの表面上の仕様だけでなく、どのようなログ出力が想定されているかということもしっかり確認しておくことが重要です。

青木室長　「赤井君、君のいう通りにお客さまにご説明したら、納得してもらえたし解決もできたよ」

赤井君　「それは良かったです。原因が分かってしまえば確認方法は簡単になるのですが、お客さま自身もてっきりインターネットショップ側の問題だと思い込んで連絡してくることは多いんです。そのようなときに、的確な回答を迅速に示せるということは、顧客満足度の向上にもつながると思いますよ」

青木室長　「確かに、そうだな。今回は、ログ出力仕様がしっかり設計されているから、起こり得るパターンを想定して対応マニュアルを作成することも可能だな」

赤井君　「そうですね。さっそく計画してみましょうか」

　意気揚々と、ミーティングスペースに向かう2人。

ここまでのキーワード

【ログ】　 Windows、UNIX、LinuxなどのOSや、ソフトウェアが出力する動作記録のこと。ログの名称や種類に絶対的な定義はないが、プログラム開発者が参照するためのものを「デバッグログ」と呼んだり、エラー情報を集約したものを「エラーログ」と呼んだり、おおよその名称は共通しているようだ。選択可能な出力手段はOSによって異なるが、開発ソフトウェアから出力する場合は、テキストファイルで出力することが多い。いかに活用しやすいログを出力するかは、設計担当者の腕の見せどころの1つといえる。

　

【平均故障間隔時間（MTBF：Mean Time Between Failure）】　ある障害発生時から次の障害発生時までの時間の平均値で、システムの安定性を表現する指標の1つ。この値が大きければ大きいほど、次の障害発生までの期間が長いことになるから、より安定したシステムといえる。

　

• MTBFが1週間：平均して約1週間に1度のペースで障害が発生
• MTBFが1年間：平均して約1年間に1度のペースで障害が発生

　

【平均復旧時間（MTTR：Mean Time To Repair）】　障害が発生してから回復が完了するまでの平均時間で、システムの保守性を表現する指標の1つ。この値が小さければ小さいほど、障害からの回復所要時間が短いことになるから、原因解明から回復策の選択・実施に至るプロセスを迅速に実施可能であることを示しているといえる。

　

• MTTRが1時間：障害復旧に平均して約1時間が必要
• MTTRが1週間：障害復旧に平均して約1週間が必要