メインフレームの道のりをオープン系もたどる

オープン系での問題点

＜品質：２点＊６＝１２点＞

1. □ 信頼性、安定性に欠ける
2. □ 短期間での開発を要求されるため、品質に問題があり初期トラブルが多い
3. □ リブートせざるを得ない原因不明な障害が発生する
4. □ 複数サーバの組み合わせのため、二重化構成を取らないと業務停止を招く恐れも
5. □ 複数の組み合わせで構築するため、障害時での調査・対応に時間や手間がかかる
6. □ 主系や従系、正・副の構成で、設定内容やバージョンレベルなどがバラバラになってることも

＜設計・構築：３点＊８＝２４点＞

1. □ 運用設計がされていない
2. □ 標準化が進んでいない
3. □ 色々な組み合わせでの開発なので標準化しにくい
4. □ 標準化や運用設計がされてもバラバラ
5. □ リソースやパフォーマンスの設計がまだ弱い
6. □ 開発やインフラが主体となった設計・構築に運用が考えられていない
7. □ 運用を知らない人が開発しているため、オペレータありきの手間のかかるシステムになりがち
8. □ メインフレーム時代を経験してきた技術者がいないため、ノウハウが継承されない

＜構成：２点＊６＝１２点＞

1. □ 個々のソフトに依存されるため、制約や制限が多い
2. □ 多種・多メーカ、多製品での構築になり、複雑なシステムになりやすい
3. □ 多種・多メーカ、多製品での構築になり、操作や使い方がバラバラで統一しにくい
4. □ 多種・多メーカ、多製品での開発になり、開発には幅広く多くの専門知識や技術者が必要
5. □ 多種・多メーカ、多製品のため、操作することも多く、指示書での作業項目も多い
6. □ 自動化したり基幹業務をメインフレーム並に構築すると高価なシステムとなる

＜体制・役割：４点＊３＝１２点＞

1. □ オープン系での役割や体制が不明確なまま引継ぎされる
2. □ オープン系を維持するために、従来の組織体制、あるいは役割だけでは維持が難しい
3. □ 引継ぎがされず、言われた通りのことをするだけのシステムも

＜運用：４点＊１０＝４０点＞

1. □ 機能やコスト重視で、監視・運行・制御、スケジューラ、バックアップなどのツールが考えられていない
2. □ オペレータありきで自動運行・監視・制御が考えられていない
3. □ 監視ツールも色々あり、監視の仕方や監視するものも様々で統一がされていない
4. □ 監視・運行・制御、スケジューラなどのツールがなく、オペレータ作業が増加している
5. □ 監視ツールは搭載されているが、監視すべきメッセージが整理・保守されてないため、ツールが役立っていない
6. □ 多メーカ、多製品の組み合わせのため、監視できないものもあり、結局はオペレータの目に頼ることも
7. □ 監視するもの、監視方法もバラバラ
8. □ バックアップなどで使用する媒体も多く、その交換や定期クリーニング作業も増加してきている
9. □ 不要ファイルの削除が考えられていないため、ゴミファイルが多く残り、消す作業もオペレータで
10. □ メインフレームで作業や要員を大幅に削減してきたのに、サーバー業務では増加傾向にある

オープン系での留意点

運用ポリシー

次回は