名古屋大学における情報サービスの運用改善を目的としたシステムトラブル対応 DB の構築
瀬川 午直*1, 出口 大輔*2, 渥美紀寿*2, 加藤芳秀*2, 嶋田創*3

荻野 正雄*3, 小川 泰弘*3, 大野誠寛*3, 川田良文*1, 山田一成*1*1 名古屋大学

情報連携統括本部情報推進部情報基盤課
情報連携統括本部情報戦略室*3 名古屋大学 情報基盤センター
segawa@nagoya-u.jp*2 名古屋大学

概要：名古屋大学情報連携統括本部は、学内構成員を中心にキャンパスネットワークや大学ポータルなど、様々な情報サービスを提供している。本稿では、これらの情報サービスの多様化におけるシステムトラブルに対する取り組みと今後の展望について報告する。

1. はじめに

2. システムトラブルのデータベース化

名古屋大学情報連携統括本部は、情報サービ

多様なシステムトラブルを管理するために、スの企画立案から運用までを一元的に統括するトラブルの詳細情報とその対応状況に関する項組織として平成 18 年度に発足した。平成 21 年目を設け、データベースで管理することとした。

度には、情報連携基盤センター及び情報メディ具体的に用意した項目とトラブルへの対応状況

ア教育センターの統廃合を経て、現在に至ってを以下で詳しく述べる。

いる。情報連携統括本部が提供する情報サービ

2.1 トラブルの詳細情報の登録

スの運用管理は、主として情報推進部が担ってシステムトラブルの詳細を記録するデータベ

おり、日々サービスの充実と安定稼働に向けてースの項目として、「サービス名」「発生日」「発さまざまな取り組みを行っている。しかしなが生時刻」「完了日」「完了時刻」「障害件名」「影ら、サービスの多様化に伴って発生するシステ

響範囲」「障害詳細」
「投稿者」
「状態」
「緊急性」

ムのトラブルも複雑化している。これらのトラ「重要度」「メモ」等を用意している。構築した

ブルは、サービス毎の運用ポリシーに従って管データベースは WEB ブラウザを用いて入力と理され、サービス担当者内で情報共有がなされ閲覧が可能である。入力画面の例を図１に示す。ている。しかしながら、異なるサービス間、さらには情報連携統括本部全体に亘って情報を共有する仕組みは実現されていなかった。そこで、全てのサービス運用関係職員での情報共有と技術の蓄積、さらには今後のサービス改善を目的として、平成 24 年 7 月以降のトラブルに関するデータベースを整備し、システムトラブルの一元管理を行うこととした。これにより、蓄積されたデータを通してトラブルの対応状況や傾

2.2 トラブルへの対応状況
平成 24 年 7 月から平成 26 年 9 月までに発生したシステムトラブルの年度別発生件数を表 1に示す。ここでデータベースに登録するトラブ
ルは、利用者に与える影響が比較的大きな障害のみに限定している。利用者への影響が少ない
軽微な障害や課題等に関しては、サービス毎に管理を行っている。

向を的確に把握し、再発に向けた対策を明確化
表 1 年度別発生件数することを目指した。以降、構築したデータベースに関して、トラブルの対応状況とトラブル

年度

24 年度

25 年度

26 年度

合計事例の紹介、データ活用について報告する。

件数

41 件

31 件

21 件

93 件

表 2 トラブル対応状況
新規対応中

解決
済み

解決
（原因不明）

対応不要

1件

1件75 件

9件

7件

図 3 解決に要した日数ことが一因と考えられる。メディアサービスとスパコンサービスについては、平成 25 年 10 月
図 1 入力画面のシステム更新に起因する初期障害が多く含まれている。
 解決に要した日数

トラブルの解決までに要した日数をサービス別に集計したグラフを図 3 に示す。
ネットワーク系に関しては装置そのものの交換等により、トラブルが発生した当日もしくは翌日までに多くが解決している。一方、1 か月以上に亘って障害が続くトラブルの多くはソフ
図 2 サービス別発生原因トウェア障害であり、現在もトラブルの発生原因を調査中のものも存在する。

 サービス別の発生件数

表 1 の 93 件のトラブルをサービス別に見る トラブルの対応状況と、その内訳はネットワーク系が 29 件、統合・各トラブルの対応状況を表 2 に示す。表中で仮想サーバ系が 20 件、メディアサービスが 17「解決済み」となっているものは、トラブルの件、スパコンサービスが 6 件、その他サービス原因を把握し、正しく対応できたことを示してで 21 件であった。サービス別の発生原因を図 2いる。一方、「解決（原因不明）」は、現象やロに示す。

グデータ等からは原因を特定することは出来なネットワーク系のトラブルの多くは、ハードウェア障害である。統合・仮想サーバ系やそのかったものの、その後同じトラブルが再発していない障害である。

他サービスにおいては、ソフトウェア障害が比次に「対応不要」となっているものは、メー較的多くを占めている。これは、独自に構築しカーへの問い合わせを経ても原因を突き止めるたシステムを利用したサービスが含まれていることができず、機器更新や部品交換等を行うことでトラブルそのものを回避したものである。
このように、発生したトラブルをデータベーなソフトウェアの導入を検討する必要があると考えられる。

ス化することにより、どのサービスでどのよう3.3 原因不明の事例②な障害が発生しているのか、さらには、トラブ

統合サーバサービスにおいて、1 台のブレールへの対応は十分なされているのか、といったドサーバが VMware 管理コンソールから参照ことを全員で情報共有し、確認ができるようにできない（管理できない）状態となった。このなった。これにより、トラブル発生傾向の分析

トラブルの影響範囲は、当該ブレードサーバ上が可能となり、分析結果に基づく継続的なサーで動作している仮想マシン利用者である。そのビス提供が可能になると考えている。

後の調査により、具体的な障害の原因は

3. トラブル事例
代表的なトラブル事例を以下に紹介する。
3.1 対応不要となった事例
統合サーバサービスにおいて、サーバの動作異常が頻繁に発生するというトラブルが確認された。このトラブルの影響範囲は、部局ドメイ

VMware ESXi のバグと考えられた。しかしながら、サポート契約が切れていたことからパッチの適用ができないという問題が発生した。そのため、サポート契約を早急に進め、パッチを当てることで経過観察するという対応をとった。

4 サービス機器のデータベース化

ンのメールサービス利用者であり、具体的な障名古屋大学情報連携統括本部では、これまで害は、「ls -l が応答しなくなる」、「ssh で接続に様々な情報サービスを構築し、運用を行ってできない」、「ldap へ接続できなくなる」といっいる。情報サービスの運用には多種多様な機器た現象であった。同様のトラブルが 4 回発生しが必要であり、保守契約期間や耐用年数は機器たため、詳細にトラブル原因の調査を実施した。

毎に様々である。特に、ブレードサーバのようその結果、OS のディレクトリサービスの不具に複数のハードウェアで構成されるような機器合であることを突き止めた。しかしながら、修の場合は、全体として同じシステムであったと正パッチを入手することができず、該当するデしても、各部分の導入時期が異なる可能性があーモンの定期的な再起動でこのトラブルへの対る。そのため、資産管理システムの資産番号を応を行った。最終的には、システム全体の更新用いた「ハードウェア台帳」という新たなサーを行うことで、このような継続的に発生するトビス機器情報管理データベースの構築を行った。

ラブルの回避を行った。

このハードウェア台帳では、各情報サービスで3.2 原因不明の事例①使用しているハードウェアを一括管理すること

仮想専用サーバホスティングにおいて、仮想が可能であり、機器毎に異なる保守契約期間や基盤である XenServer がハングアップし、耐用年数を一覧で確認することが可能である。

XenServer 上の仮想マシンが全て停止するとい構築したハードウェア台帳の機器情報管理メニうトラブルが発生した。このトラブルの影響範

ューの例を図 4 に示す。

囲は、仮想マシン利用者であり、応急処置とし

図 4 に示す機器管理メニューでは、検索対象て XenServer が動作しているブレードの電源をの機器を、「機器一覧」「アドレス一覧」「機器検強制的に落とした後、システムを再起動するこ

索」「アドレス検索」から探すことが可能である。とで復旧を行った。その後、ハングアップの原これらの機能に加えて、「保守期限切れの機器」因を詳細に調査しようと試みたものの、無償の「来年度保守期限が切れる機器」「保守期限未設XenServer であったことからサポートを受ける定の機器」「廃棄可能な機器」「廃棄可能日未設ことができず、原因を突き止めることはできな定の機器」をトップページ上で一覧表示する機かった。このような基幹システムとして動作す能も備えている。

るものに関しては、正式なサポート契約が可能「機器一覧」や「アドレス一覧」を参照することにより、これまでサービス担当者が独自に管理していたサービス機器の情報（設置場所、保守期限、等）を担当者間で共有することが可能となる。また、IP アドレスや MAC アドレスを登録することにより、セキュリティインシデント等のトラブルが発生した場合においても、即座に機器を特定することが可能である。
ハードウェア台帳に登録する機器情報は、「資産番号」「物品名」「シリアル番号」「構成内訳」「管理部署」「管理者」「設置場所」「ラック名」「取得日」「廃棄可能日」「保守開始日」「保守終了日」「機器バーコード」「IP アドレス」「MACアドレス」など多岐に亘る。具体的な機器情報の登録画面を図 5 に示す。
ハードウェア台帳を導入することにより、「保守期限切れの機器」や「来年度保守期限切れの機器」を一覧で確認することが可能となった。これにより、サービス機器の保守契約や機器更新に向けた予算確保のスケジュールが立てやすくなり、事務の効率化につながっている。
今回構築したハードウェア台帳を用いて保守期限切れの機器、来年度保守期限が切れる機器、それぞれを確認した例を図 6 と図 7 に示す。

図 5 登録情報の例

図 6 保守期限切れの機器の例

図 4 機器情報管理メニュー

図 7 来年度保守期限が切れる機器の例

５ 今後の展望
近年のサービスシステムは、C/S 方式でシス情報機器への予算投資戦略への貢献にも期待したい。

テムが構築されることが多い。また近年の仮想化技術の進歩により、サーバ、ストレージ、ネ謝辞ットワークなどが仮想化され、これらが複雑に

本報告の執筆にあたり、名古屋大学情報連携絡み合い、ハードウェアとソフトウェアの境も統括本部情報戦略室、情報基盤センター、情報曖昧になりつつある。このような状況から、実基盤課の方々には多くの助言をいただいた。こ際にトラブルが発生して現場に駆けつけたとしこに深く感謝する。ても、どの機器でどのサービスが運用されているのかを即座に判断することが難しくなってきている。トラブルを早期に解決するためには、問題の発生したサービスがどの機器で運用されているのかを的確に把握することが重要である。
今後は、これまでに整備したハードウェア台帳を柱として、各サービスがどの機器で運用されているのかを確認するためのサービス台帳を整備していく予定である。
また、実際に機器が設置されている現場において、それぞれの機器上でどのようなサービスが運用されているのかが把握できると、必要な対応、さらには復旧作業における人為的ミスを避ける事が可能であると考える。今後、バーコードや QR コード等を機器に張ることにより、スマート端末でハードウェア情報とサービス情報を簡単に確認できるシステムを検討したい。

６ まとめ
本報告では、情報サービスを運用する上で発生するインシデントに対し、原因の究明と対処の方法を関係者間で共有するシステムを構築し、それを活かした運用改善方法について報告した。
中長期的な展望に沿って安定的かつ継続的にサービスを提供するためには、このようなインシデントへの適切な対応が不可欠である。今後は、これまでに構築したシステムトラブル対応デー
タベースとハードウェア台帳を活用し、これらをさらに拡張していくことで、多様な問題へと対処していく予定である。また、これらのデー
タベース化を実施することにより、サービス機器の管理状況が見える化され、業務の省力化を図ることも可能であった。また、計画的な予算執行や予算獲得にも活用可能であることから、