当社エンジニアによる書き下ろし技術レポート Close-Up IT

技術レポート 新着RSS（Atom）

この記事に関連するサービス
センター運用業務の継続的実施
この記事に関連するお問い合わせ
お問い合わせ

第3章 ：モデルケース

9モデルケース[2] システムは生きもの、トラブルは起こるもの 実施内容

ARK太郎「リンクをクリックすると、新規ウィンドウを開いて表示します。」

1. 事業計画とシステム運用計画の連携

項目 内容 備考
稼動管理に審査機能を追加 稼動管理
性能管理レポートの改善と事業計画を意識した評価 性能管理
事業企画部門との定例会の実施 【目的】事業計画・システム化計画を含め、総合的に評価する
【内容】次のような情報の共有、影響確認、システム対応、スケジュール変更の検討と決定 【参加者】
  • 事業企画部担当者
  • IT推進部IT企画室、開発技術課、運用推進課各担当者

2. サービスレベルにあったシステム構成への変更

項目 内容 備考
最適な冗長化構成への変更 すべて主系・従系であったシステム構成を、負荷分散装置 (CSS) を導入することで、2台で処理できる構成に変更した。障害発生時には、処理効率は半減するが、変更前と同等の処理能力は確保されており、サービスレベル面でも現状の想定で問題ないことが確認された。
必要に応じたシステム増強

ARK太郎「この構成変更は、ARKのシステム構築の部隊が、プロジェクトとして対応しました！」

3. 回復管理におけるユーザー広報の徹底

項目 内容 備考
障害発生時のプッシュ型広報の実施
コールセンターとの連携と影響範囲・広報手段の早期把握
  • 障害対応のワークフロー化
    障害発生時には、必ず発生状況やユーザー影響、影響範囲、回復予定時間を明確にし、コールセンターへ連絡するよう障害対応フローを整備し、新たにワークフロー化した。
  • 影響範囲マトリックスの作成
    障害時の影響範囲を即座に把握することが目的。ソフトウェアとそれを使用している業務アプリケーションとの関連を、マトリックスとして管理すると、変更時や障害時の切り分けがしやすく便利である。また、障害箇所 (システムやサーバー) と影響範囲、広報ツールの関連をマトリックスとして管理すると、障害時広報を迅速に行うことが可能となる。
回復管理

ARK太郎「上に挙げた以外に、ネットワーク部分についても対応の余地があると思われます。ネットワーク帯域の確保に関しては、現在、選択肢が増えてきており、セキュリティレベル、コスト、スピードの掛け合わせで、その企業に適したものを選ぶことが重要です。ただ、選択やネットワーク構成設計には慎重な検討が必要で、少し時間がかかってしまうと思われますが、どうしましょうか？」

Z社担当課長「とりあえず今回の性能管理の対応をヒントに回線使用率レポートの改善からやってみます。現状の回線サービス・品目で対応可能であれば、順次増速していくつもりです。VPNなど大規模な変更が必要になりそうなときは、別途ご相談させてください。」

このページの先頭へ