Top / システム保守・運用

システム保守・運用

目次 †

はじめに †

　稼動を始めたシステムは、長いものは10年以上に渡って使い続けられる。この間システムに対して、様々な変更が発生する。
　また、テストで発見できなかった不具合が運用後に発見される。

　これらに対してプログラムを変更して、システム改善を続けていく作業をシステム保守という。

システム保守・運用 †

　システムの保守・運用は、システムを正常に動作し続けるために行う作業で、次の作業を行う。

1. ハードウェアやソフトウェアの定期的な点検
2. エラー発生時の補修、およびレグレッションテストの実施
   • エラーの修正などでプログラムを変更した場合

システム保守 †

システム保守の問題点 †

　システム保守にあたり、次のような問題点があるため、保守費用が膨大にかかっているのが実情であり、いかに効率的に保守を行うかが大きな問題である。

• 保守機関が長いため、開発に携わったメンバーがいなくなる。
• 他人のプログラムの解読・変更が困難である。
• プログラム修正後の検証が難しい。
  • 修正が別の不具合を発生させる。
• ドキュメントが保存・更新されていない。
  • ドキュメントとプログラムの不一致。
• 短時間での不具合修復が要求される。
• 保守ルールが明確でないため、システムの大局的見地からの変更が行われない。

　これらの問題を改善するために、システムやプログラムの標準化・部品化、ドキュメンテーションの標準化などが推進されなければならない。

保守の実施手順 †

1. 保守計画の立案
   • 完全化保守などのあらかじめ定められたプログラムを、定められた期日に行うものについては、短期・長期の保守計画を立てる。
2. 変更要求の受付と担当者割り当て
   • 変更要求やトラブルシュートを受け付け、その解析を行う担当者を割り当てる。
3. 分析と実施可否の決定
   • 変更の可能性・妥当性、緊急度、効果と費用などを分析し、その結果を基に変更作業を行うかどうか、行う場合のスケジュールを決定する。
4. 変更の実施
   • 変更要求やトラブルシュートに基づいて、実際にシステムを修正する。
   • プログラムの変更と同時に、ドキュメント（仕様書）の修正も行わなければならない。
5. テストと教育
   • 修正が正しく行われたかどうかをテストし、変更内容によっては利用者を再教育する。
6. 変更ソフトウェアの導入
   • 変更され、テストされたプログラムを本番の運用環境に導入する。

システム保守の種類 †

時期による分類 †

• 予防保守
  • システムの故障や障害が発生するのを未然に防ぐための保守のこと。
• 定期保守
  • あらかじめ計画されて、定期的に行われる保守のこと。
• 事後保守
  • 障害が発生した後に障害を取り除くために行われる保守のこと。

発生理由による分類 †

• 修理保守
  • 不具合を修正するための保守のこと。
• 適用保守
  • 環境の変化に対応してシステムを変更する保守のこと。
  • 業務実施手順の変更や、組織変更、法律改正、業界標準化などに対応して発生するシステム変更である。
• 完全化保守
  • より完全なものに改善するための保守のこと。
  • 応答時間の改善、マンマシンインタフェースの改善、ハードウェアの効率的な利用などを目的に実施するものである。
• 拡張保守

活動による分類 †

• 応急保守
• 予防保守
• 計画保守

実施場所による分類 †

• 現地保守
• 遠隔保守
  • 通信回線を用いて、遠隔診断を行い保守対象のシステムの障害個所を指摘する保守のこと。
  • 保守員を配置する必要はないが、現地派遣による修理・派遣がまったくなくなるわけではない。
    • 分散システムにおいては修理時間を短縮できる。

保守契約 †

　保守契約書には、低機保守の実施周期、費用、障害時の保守・対応などについて記載する。そもそもコンピュータソフトウェアは未完成のまま販売され、作成後実際に運用していくにしたがい徐々に完成度を増すために、販売時は内容を保証しない。未完成が前提だからこそ、保守契約を別途結ぶのである。

　検収後に有償のメンテナンス契約を締結する方法が瑕疵担保責任を最大限免れる最良の方法である。こうしておけば、ユーザーは一定料金で保守サービスを受けられ、ソフトウェア会社側も瑕疵担保責任をとりあえず断絶できる。ただし、瑕疵担保世金を完全に負わないというわけではなく、また保守を行うと保守契約の瑕疵担保責任が新たに発生する。

保守の効果 †

　稼働率（availability）は、予防保守によってMTBF（平均故障間隔）を長く、遠隔保守や保守センターの分散配置によりMTTR（平均修理時間）を短くすることを目指す。

稼働率＝MTBF/(MTBF＋MTTR)

　なお、故障時の臨時保守では、この稼働率は変化しない。

各種保守とMTTR/MTBFの関係 †

• 遠隔保守を実施することにより、MTTRを短くすることができる。
• 故障発生時に行う臨時保守によって、その時点でのMTTRは短くなっても、その後のMTBFは長くなるとは言い切れない。
• 保守センターを1ヵ所集中から分散配置に変えることによって、システムのMTTRは短くなる。
• 予防保守を実施することにより、MTBFを長くすることができる。

ヘルプデスク †

　システム運用サービス基準の策定の際は、サービス基準を設定する項目について次のようなプロセスの順序で行われる。

1. 利用部門と提供部門との折衝
2. サービス項目別のサービス基準の目標値と保証値を設定
3. 予防保守目標の作成
4. エラー時の対処法などを問い合わせるためのヘルプデスクの明確化

ヘルプデスクの手順 †

　ヘルプデスクは次のような手順で問題解決する。特にエンドユーザーから報告を受けた障害の原因は不明であるが、応急処置を必要としているとき、このようになる。

1. 受け付けと記録
2. 問題の判別
3. 応急処置
4. 原因究明への優先度設定
5. 原因究明と問題解決

[補講]この手順は「ソフ開発　平成11年度春　午前問82」で出題されたことがある。

時間経過と故障頻度の関係 †

　大抵の場合、次の図のように、運用開始直後と一定期間経過後に故障が多く発生する。運用開始直後では初期故障が頻発し、一定期間経過後では磨耗による故障が頻発するのである。

　この曲線は形がバスタブに似ているので、バスタブ曲線と呼ばれる。

障害管理 †

　システム障害は業務に多大な影響を与える。そのため、障害が発生したときにはシステムを迅速に復旧できるようにしておくことが重要である。障害への迅速な対応と回復処理が正しく行われるようにするには、次のような運用上の方策が必要である。

• 障害発生時の連絡ルートや責任者などの連絡体制の確立
• 障害個所の特定のための切り分け手順の確立
• ハードウェア障害時の縮退・代替・切替えなどの回復手順の確立
• ソフトウェア障害時の修正、旧世代への戻しなどの回復手順の確立
• データベースのバックアップと回復手順の確立
• ソフトウェアのバージョンや更新履歴の管理方法の確立

　こうした方策の立案においては、システム開発担当者などの協力を得て、システム全般に渡った検討を行うことが重要である。また、回復手順の訓練、データベースの保存といった日常業務における着実な実行を管理することも必要となる。

障害発生時の対応手順 †

1. 障害発生
2. システム監視時に発見、ユーザーからの報告
3. 障害の範囲の特定
4. 障害部分の切り離し
5. 一時対応・暫定的な措置
6. 恒久的な措置
7. 一時対応の整理

障害発生時の対策 †

　障害が発生した場合、システムコンソールメッセージをチェックして、障害の現象・範囲・大きさ・頻度を把握する。そして、他のシステムへ被害が拡大することを防ぐために、障害システムを切り離す（アイソレーションという）。

　一時的な暫定処理を行った後に、原因を究明・再発を防止する恒久的処理を行って、暫定処置を解除する。

参考文献 †

• 『超図解mini　基本情報技術者試験　平成19年度版』
• 『ソフトウェア開発技術者　合格エッセンシャルハンドブック』
• 『ソフトウェア開発技術者　午前対策（基礎編）　テキスト』
• 『応用システム開発の重点解説』