運用規約、運用設計書

第8回 『コンピュータの成長の道のり』

概要

システム運用改善一筋に30年!!人生を運用改善にかけた「運用ゲンジン」のノウハウを大公開します。 現場での経験をいかしたカイゼン実行のコツと事例を掲載します。

厳しかった寒さもやっと峠を越え、あちらこちらと梅の開花の声を聞くようにもなり、明るさを感じる季節になりました。でも、それとは裏腹に景気はまだまだと感じるのは私だけでしょうか? 年度末をすでに迎えられた企業、そして、これから迎える企業も、この数ヶ月間は皆さんのこの一年の方向性が、新年度の予算などから読み取れる重要な時期だと思います。皆さんの会社ではどんな傾向だったでしょうか? 運用は成長し続ける生き物であり、改善は運用部門にとっては永遠のテーマです。長年の間運用改善を見てきましたが、改善することで金が入るわけでもない以上どの企業でも改善には余り金をかけずに、と考えるのは当然なことです。初期の頃ならまだしも、今はシステムの規模も大きく複雑になり、しかも急速なオープン化の最中での改善は手間隙も掛り、改善のためのコストも以前にも増して掛るのが実情です。結局はどこかの政治の話ではありませんが、先延ばし、あるいは小手先の改善ですましてしまい、以前の大きな改善効果を上げてきたときと比べれば、はっきりと見える効果も出せず、なかなか改善が進まないのが現実なようです。 
まして急速に進むオープン化の中では、メインフレームを維持するだけでも精一杯で、ほとんど手がかけられない、あるいはオープン化が落ち着いたら運用の再検討をするという企業も多く、しばらくは我慢の運用を強いられそうです。こうなる前にやっておけばと気づいたときは時すでに遅しと思うほど、変化のスピードは目をみはるものがあります。もしかしたら、この時期に中途半端に手をかけるよりも、かえって何もせず、じっくり状況を見据えることも一つの手なのかも知れません。
さて、愚痴っぽい話はこのくらいにして、この投稿も8回目を迎えましたが、このコーナーで皆さんが参考にされたことが少しはありましたでしょうか?100社あれば100通りの運用がある中で、当たり前のような話ばかりで、皆さんに満足していただける、あるいは喜んでいただけるような情報がなかなか提供できず、回を重ねるごとに題材に苦慮する毎日です。しかし、使う道具が違うだけで、新鮮味もなく、何年たっても当たり前の話がまかり通るのが運用なのかも知れませんが(笑)。

今回は堅苦しい設計の話ではなく『コンピュータの成長の道のり』について、当たり前の話かも知れませんが、私なりに簡単に話をしてみたいと思います。 多くの事故やミスからの教訓の基に今日の人類の発展があるように、コンピュータの世界でも同じことがいえると思います。コンピュータの歴史は、大きな物から小さな物へ、高価なものから安価なものへ、遅いものから速いものへ、容量の少ないものから多いものへ、信頼の低いものから高いものへと進化し、昔の能力では考えられなかったことが今では簡単にできるようにもなりました。技術の進歩の積み重ねが今日のオープン化を広める大きな原動力にもなったのです。

今では考えられませんが、だいぶ昔のメインフレームがたどった道のりも今のオープン化と同様です。初期の頃は運用ツールはもちろん、標準化や運用という言葉すらありませんでした。産まれたばかりのコンピュータから、技術の進歩によってシステムの規模やネットワークが急速に拡大され、次第に標準化や統一化が叫ばれるようになりました。運用コストも拡大から一転運用コスト削減に転じ、それ以来今日までの運用部門に永遠のテーマのごとく運用改善が課せられてきました。 オープン化は急速に進んではいますが、現在のメインフレームとは違い、多種・多様なハード、ソフトの組み合わせによる環境の中では、統一化・標準化するには複雑で、意識は高まってきてはいるものの、まだまだ時間は掛ると思われます。

現在のオープン系に、安定したメインフレームの方式を適用しようとすると、現在のオープン系技術では無理がきたり、構築する上で手間もコストもかなり掛ってしまうため、運用はどうしても人手に頼らざるを得なくなるのが実情です。従来、問題は開発の上流段階に起因していることが多かったのですが、オープン系ではシステムの能力や信頼性は機器類の選定の段階でほぼ決まると言っても過言ではありません。

オープン系を大きく左右する鍵としては

    (1)ハードのスペック
    • 基幹業務かWeb系業務か、選定するCPUの特性で大きな差が生じる価格のみで選定すると大きな選定ミスを引き起こす
    • メインフレームと同様にベンチマークでスペックや位置づけを明確にする
    • 大量、集中処理では負荷分散を考慮する
    • ホスト並みの信頼性を保障するためにはクラスタ構成を検討する(但し、仕組みは複雑)
    • 機能や役割でのサーバ分散も考慮する(何もかも押し込むのは間違い)
    (2)選定OS
    • Unix、Windows、Linuxなどにより搭載できるプロダクトが決まる
    • 技術者、スキルが限定される(現時点でもかなり技術者不足状態)
    • 開発言語が限定される
    • 信頼性には差が生じる
    (3)運用ツール
    • スケジュールツールによりJOBネットの構造や管理上での特性がある
    • 複数のスケジュールツールを利用することを前提にした環境づくりも必須である
    • 監視運用設計がオープン化の最重要設計事項である
      「監視するもの、情報の拾い方、通知の仕方、通知できるもの、通知できないもの」の明確化が重要であり、監視システムのフィルター設定の良し悪しで運用は決まる
    • 管理(ログ収集~分析,課金、セキュリティー)も必須機能である
    • レポート管理機能もメインフレームと同様に導入する
    1. (4)バックアップ

 

    • ストレージや媒体管理がバラバラだとすれば運用コスト、開発コスト、維持コストの増加につながる

 

今後は、各企業の中でもこれらが徐々に統一化されてくるものとは思います。ただし、すでにバラバラになっている企業も多く、当面は統合化よりも、メインフレームがたどって来た道と同じように、徐々に改善されながら標準化や統一化や統合化が進むものと思われます。メインフレームシステムも一気に安定してきたわけでもなく、技術の進歩の裏での長年の改善を繰り返してきた結果として今日の安定したメインフレームシステムがあります。いずれオープン系も今のメインフレームのように安定化・標準化された時代がくるとは思いますが、そのころにはまた次の新しい世代のコンピュータが出現しているかもしれません。使う道具は違えど、この同じ道のりと改善の繰り返しは変わらないと思います。

まだまだ時間はかかりますが、メインフレームがたどって来た道のりと同じであれば、今までの改善してきたこと、あるいは考えてきたことは、これから必ず生きてきます。成熟したメインフレームと比べるとオープン系の運用は時代が逆行しているようにも思えますが、メインフレームの初期の頃を考えれば実は同じなのです。それを改善によってメインフレームのように成熟させていくのは皆さんです。

連載一覧

コメント

筆者紹介

ITシステム運用コンサルタント

沢田典夫氏

バックナンバー