ＩＴシステム運用コンサルタント
沢田典夫氏
新年明けましておめでとうございます。本年も当サイトをよろしくお願い申し上げます。
さて、みなさんはどのようなお正月を迎えられましたでしょうか？
システムの統合や新システムの稼動、また、切り替え準備などと、情報部門にとってはむしろ連休などがこういったイベントが計画されることも多く正月とはいえ、ゆっくり休めなかった方も多かったのではないでしょうか。
昨年はオープン化が急速に進み始めた年でしたが、みなさんの会社ではいかがでしたでしょうか？
今年は特にメインフレームの更新時期の企業も多く、そのタイミングに合わせオープン化もさらに拍車をかけるものと想定され、みなさんの仕事にも大きく影響すると予測されます。また、オープン系での技術者不足も深刻な問題となって現れてきているようです。 そんな状況の中で、少しでもこのサイトを通じてみなさんのお役に立てればと思います。
新年の第一弾では、今後、運用設計を行う上でも重要なオープン系に焦点を当て考慮点をまとめます。
- コンピュータ利用の変遷
- メインフレームとオープン系の違い
- 現状の問題点
- オープン系運用の留意点
- 運用構築ポイント
-
従来からの運用との違いや現状での問題点を明らかにし、今後の運用設計の際に考慮していただければと思います。
コンピュータ利用の変遷
オープン系を語る前に、コンピュータ利用が今までどのように変化してきたかを簡単にまとめてみました。
また、その変化と供に、開発・運用の組織としての変化も重ねてみましたが、コンピュータの発達とともに生産性を重視してきたことが、今日の運用設計力を低下させてきたことがよくわかります。
メインフレームとオープン系の違い
ここでは、メインフレームとオープン系の違いをキーワードで比較してみました。
(まとめ）
★オープン系は、開発スピードが速く、標準化などはまだ当分試行錯誤（組み合わせ開発が多く参考にしにくい面もある）
★現状では、要員体制も増加傾向であるが、徐々に運用改善を実施した結果により落ち着くと思われる
現状での問題点
このような状況において、オープン系としての現状での問題点について、以下に筆者が経験した範囲でまとめてみました。（順不同）
- 相変わらず運用としての運用設計がされない
- オープン系の役割や作業範囲が不明確なまま引き渡される
- 短期間での開発が要求されるため、品質に問題があり初期トラブルが多い
- 標準化が進んでいない、組み合わせ開発なので標準化しにくい
- メインフレームがたどって来た道と同じ状態で、当初の標準化がされていない
- 個々のソフトに依存されるため、制約や制限が多い
- 多種、多メーカ、多製品での構築により、複雑なシステムになりやすい多種、多メーカ、多製品のため、操作や使い方が統一化しにくい
- 多種、多メーカ、多製品のため、多くの専門知識が必要となる
- まだまだ信頼性に欠ける
- 原因不明の障害が多く、即リブート対応となる
- リソースやパフォーマンスの設計がまだ弱い
- 運用を知らない人がシステムを開発してる、今後の基幹業務の開発時には多くの問題を発生させそうである。
- メインフレームを経験したＳＥのプロジェクトへの不参加により、ノウハウが継承されない
- 複数サーバの組み合わせが多く、サーバ間の通信異常は業務停止を招く
- 機能重視で、監視・運行・制御、スケジューラ、バックアップなどのツールの導入が考えられていない
- システム導入コストを抑えるために、監視・運行・制御・スケジューラソフトが導入されない場合もあり、オペレータ作業の手間が増加している。
- 媒体・ファイルサーバ等を利用したバックアップがまだ弱い
- オペレータありきで自動運行・監視・制御が考えられていない
- 停止、再開などリフレッシュが考えられていないケースが多数あり、計画停止ができない
- メインフレームの手順書のような作り方がしにくい
- 引継ぎがされないケースもあり、運用側はただ言われた通りの運用をするだけになっている
- サービスレベルを合わそうとするが、業務が異なるので無理がある
- サーバ上にゴミファイルが残りやすく、その削除が考えられてない
- 異常の調査、対応を行うのに複数構成のため、手間が掛かる
- プロマネの構築が多く、運用設計は開発の立場でしか実施されない
- 当初のサービス業務中心から基幹業務の処理まで対象が広がりつつある
- 基幹業務を乗せるときに、運用を知らない技術者が考えるケースが多い
- 運用業務改善で作業や要員は大幅に削減されたが、サーバ業務はむしろ増加傾向にある
- 基幹業務をメインフレーム並みにゼロから構築しようとすると、高価なシステムになる
- （リソース、クラスタ構成、ミラー化、運行・監視・自動制御・スケジューラ、レポート、バックアップ、業務パッケージ）
- 主系、従系とで設定内容やプログラムレベルなどがだんだんアンバランスになる
- 監視ツールで拾えるものと拾えないものがあり、統一しにくい
-
総合的な問題点は
個々の問題点をまとめると、以下ような問題が浮き彫りになってきます。
- プロマネ的な構築体制が多い
- 短期間での構築をしいられるため、品質に問題が多く信頼性が乏しい
- アプリケーション以外に初期環境などの構築するものが多い
- 個々の専門者の集団で、全体の把握をしきれていない
- オペレータありきで、人手のかからない運用が考えられていない
- 機能が先行され、運行・監視・制御・バックアップの基本がおろそかになる
- 標準化が確立されていない
- 多種・多メーカ・多製品での組み合わせで、システムが複雑化する
- メインフレーム並みの運用業務は高価で無理がくる
- 運用部門としての運用設計が十分にされていない
- メインフレームとオープン系と、サービスレベルの異なる運用を無理にどちらかのサービスレベルに合わそうとしている
-
オープン系運用の留意点
それでは、オープン系運用ではどのような留意点があるのでしょうか
- オープン系でも運用管理はメインフレームと同様である取りあえずの開発や運用は、後々に必ず問題になる
- 全ては管理・作業・役割・責任範囲を明確にしてから実施する
⇒作業や仕組み、管理方法が異なる - 業務ごとの開発／運用方針ではなく、共通の基本方針を立てる
⇒運行・監視・制御・出力・スケジュール・バックアップ、作業 - 基本となる運行・監視・制御・出力の方式を第一に設計する
- なんでも監視は作業負荷を高める
⇒デフォルト設定は注意が必要（無駄なものを拾いすぎる傾向がある）
リソース（回線、ＤＩＳＫ、ＣＰＵ、メモリ）、パフォーマンス、ハード、ソフト、ＡＰＬ、プロセス……
拾えないメッセージ
⇒閾値は慎重に設定（生きた監視、自社／業務に合った監視）
業務特性、重要度、必要性、連動、瞬間 - 複数サーバ構成によるサーバ間の通信異常を考慮し、代替手段を用意する
- メインフレーム運用に合わせるのではなく、新しい運用形態を構築する（さらなる自動化等）
- 複数構成による個々の運行タイムチャートをしっかり検討する
- 機能確認や異常時の検証を、一連の流れで、個々の時点ごとに検証する
- 計画停止、運用日の切り替えを忘れずに設定する
- 実績管理や課金、より自動化のために、ログの収集を実施する
- ドキュメントは作業性より、別々にはしない工夫が必要である
⇒運用作業は個別より一連の作業の流れで行う：役割にもよる - オープン化により、よりヘルプデスクの役割が重要になる
- 管理の分類が運用ではない
⇒管理を行うための作業役割を明確にし、各役割別に一日の作業タイムチャートで業務を遂行すること。また、作業は運用の仕組みや道具、その管理事項とがリンクされる -
（まとめ）
メインフレームもオープン系も、大切なのは機能よりも運用基盤としての運用設計をきちんと行うかどうかが成功の鍵！！
運用構築のポイ
オープン系ではどんな運用環境にしていけばよいのか。オープン系のメリットは構築のしやすさであるが、逆にそれが色々なツール、色々な環境が作られる結果となり統一化を大切にしてきた運用部門からすれば作業負荷を高める大きな原因にもにもなってきています。
システムを構築するに必要なことは、監視・運行・制御が最低統一されていれば、メインフレームと同様な運用形態をとることができます
しかし、問題は初期の統合環境を構築する費用を捻出できるかであり、ここに成功の鍵があるともいえます。
- オープン系は急速に発展し、まだまだ標準化や運用方式が確立されるまでには時間がかかりますが、メインフレームも初期のころは現在のオープン系と同じ状態でありそういった意味では、メインフレームが２～３０年かけて標準化や効率化を追求してきてやっと成熟してきた状態になってきたのと同じ道を、オープン系もやっと歩み始めたといえます。だからこそ、メインフレームで培ってきた運用設計、標準化、運用方式などの考え方や方法などについては、オープン系であってもそれは同様です。オープン系だからと怖がらず、メインフレームで苦労してきたことを是非オープン系で役立ててください。
コメント
投稿にはログインしてください