システム運用の勘所集



 システム運用においては、苦い経験と日々の努力の積み重ねから知恵、ノウハウが生まれてきます。当ページでは、運用のプロが現場で培った勘所(運用のポイント)をご紹介します。
公開:2008/06/18
更新:2011/12/26
最初からゴールを求めた改善だけでなく、段階的な考査を経た改善も必要 2008/06/18



 一般的にシステム運用は、構築や開発などと違い、システム本番C/O直後(あるいは本番稼動前の終盤局面からの参画)が改善スタートになるケースがほとんどです。

  • システム設計段階から参画できていればよいが、既存システムをリプレースする場合は、現業運用の兼ね合い等で充分に参画できない。
  • また、新規参画する場合でも、全体的なシステム像を把握できていることが前提であり、関係者から見た運用要員への信頼がないと参画による影響行使がむずかしい。
従って、本番C/O直後の各種混乱やクライアントよりの要望などの対応を行いつつ、不要な負荷を取り払うように運用業務上不可欠な改善から取り組まなければいけなくなります。(改善しないと運用が回せなくなる)

一言に「改善」と言っても種類は多岐にわたります。

  • システムまわりの改善
  • 業務アプリが絡んだ改善
  • オペレーション改善
  • ドキュメント改善
  • 人的改善
  • ワークフロー改善
などと、一般的な大枠で述べていますが、個々の職場でのシステム運用の範囲が違うように、改善を担当する範囲(権限)も変わります。皆様で担当されているシステム運用に当てはめてイメージしていただくとわかりやすいと思います。

ここから先は、経験上の話です。
最初に計画された改善も、時間や環境の変化で変わってきます。

  • 上席者含むステークホルダーに異動があり、以前の設定事項/方向性が覆される。
  • 上席者から追加・変更の要件を含める形で計画の練り直しが発生する。
汎用的なものとしてITILの考え方がありますが、組織の大きさや運用が任されている範囲によって計画や手法が独自なのものになると思います。

  • 独自になる要因:組織内の空気や文化、ステークホルダー間の改善に対するスキル等
「最終的なゴール」については、主に上席者に求めることが多く、上記に述べているような変更がありえますので、 運用を含むステークホルダーがそれにより近づけるために、都度柔軟な対応を行う必要があります。

システム運用に柔軟性を持つ 2008/06/18



 ご多分にもれず、現在のシステム運用は以前のシステム運用と変わりつつあります。

  • システムマチックな変化
    • OS、アプリ、N/Wなどの変容に伴う管理を含む
  • 組織の変化
    • 個人情報、SOX法などの法的規制による管理の変容
  • 予算
    • 他への計上に伴う運用関係確保分への影響
  • 人的構成
    • 要員の資質、人件費見直し、教育
など様々ありますが、上記はすべてつながっています。

  • システマチックな変化に伴い
    • 運用を含む組織を再構成する必要性
    • 予算(現状分維持/新規システム分の計上/経営判断による削減など)
    • 人的構成(新システム運用や技術習得/把握、予算上の要員体制変更)
  • 組織の変化に伴う
    • システム改変による修正
    • 予算(管理体制の変更、経営ポリシー変更に伴う経費削減など)
    • 組織の再構成(管理体制の変更
    • 人的構成(他部門への配置換え/退任などの入替によりスキル維持など)
  • 予算見直しによる
    • システム改変(統合/分散/削減など)
    • 組織の再構成(管理体制の変更、経営ポリシー変更に伴う経費削減など)
    • 人的構成(現状要員の見直し、教育経費など)
  • 人的構成変化による
    • システム構成のスキル維持/向上
    • 組織への影響(スキル維持/向上、管理者の場合は対外折衝を含む)
    • 予算(要員に関する変更など)
上記については簡単に述べていますが、他にも様々な部分で密接につながっています。
基本的に、これらは運用管理/統括を含むマネジメント層などで考えていく事項ですが一般的な運用管理者であっても、現状ある程度把握しておくべき内容になりつつあります。

但し、厳密に運用統括/管理とオペレーション担当で役割を分割している場合は該当しないのですが、組織やシステム環境が分散していくと、管理者がすべてを把握できなくなる場合もあり、一部を作業者に管理を委託することもあります。この場合、その職場での管理内容もある程度把握しないといけなくなります。

このようにシステム運用を取り囲む環境は変化し続けていき、それに合わせて柔軟に対応する必要があります。 これに慣れば、今後起こりうる変化にもある程度予測を立てて対応することも可能となります。 結果、システム運用に対する評価にも変わってくことになるかも知れません。

異常監視だけでは、本当の監視にならない。 2008/08/22



 監視ツールを導入し、異常監視を自動化すればそれで万全かと言えばそうではない。
定常監視、障害監視、リソース監視などはわざわざ人間がやる必要はないかと思うが人間でないと判断できない監視がある。
  • 今日は、いつもとちがう動き方(処理の遅延など)をしている。
  • 常駐しているタスク数が異常に多い(あるいは少ない)。
  • 連休明けでデータ量が膨大になっている。
  • テレビコマーシャルの影響で大量受注が来ている。(または可能性がある。)
正常時と異なる動きをつかむのは、人間の「カン」でないとできない。
その「カン」を養うには、定期的に正常時の動き(クセ)をつかんでおく必要がある。
そうすればトラブルを未然に防止することができる。

属人化はなぜいけないのか 2008/10/16



 企業(システム)が存続する限り、システム運用は継続するがそれを担う人の方は環境変化に伴って時々刻々と変わっていきます。
  • 分社化
  • 会社の移転
  • 運用担当者の退職
  • ERPへの移行
  • アウトソーシング
人に依存した運用(=複雑な運用)は、どこかで破綻をきたすことになる。最初から引継ぎがし易い、自分以外でもかんたんにできるような仕組みを作っておく必要がある。そうしないとまわりまわって、自分のところにお鉢がまわってくることににもなりかねない。

システム運用の「幅」 2009/03/23



 運用のノウハウレベルを「広く浅く」と表現する事が多いのですが、
これは標題の通り、
  • 「運用の幅」を持たせることによって、案件に対して柔軟な姿勢で向かう。
と言う意味もあるかと思われます。
現状のシステム運用は、
  • 機種の分散化
  • 運用範囲の拡大
  • 知識の習得要求
  • 対外部門などとの折衝
など様々な要件追加や、これらに対応する能力を求められてきています。
例えば、専門職のエンジニアとの折衝において、
  • 相手の専門知識を浴びせかけられた結果、主導権を握られてしまう。
  • 双方の論点が噛み合わず、運用側の成果が挙げられない。
  • 結果、運用側より相手側の論法が常態化してしまう。
という苦い経験は、運用側で経験した事は意外と多いのではないでしょうか?
とは言え、何から何まで全てを完璧に把握する事も、当然ながら難しいです。

ここで言う「広く浅く」の「幅」とは、
  • 担当システムに関する基本設計レベルをイメージ化できるまでの比較的緩い知識を持つ。
  • アプリケーションやプログラムに対する基本的部分の把握(ロジックや言語特有の論法など)
  • 重要なステークホルダーへの対応ができる範囲の諸知識把握

等々、書き出したらキリがないような「幅」もあると言えます。

しかし、少しでも幅を持たせた知識を持っていれば、
「知識の引き出し」を持っている事にもなり、
問題が発生した場合の対処、及び改善を行う際、容易に対応可能となります。

そして、ステークホルダー等に「奥行き」を求められたら、その時に専門職やドキュメントなどで
より深い知識を深めればいいのではないでしょうか・・・

 

システム運用の勘所集 2009/12/28



昨今、「クラウドコンピューティング」や「シンクライアント」
などの新しい考え方が出てきています。

既に一部の企業では随時適用していく所もあるようで、
システム周りの再編などにも波及する可能性もあり、
既存のシステム運用の概念が変わってくる事も考えられます。

一方で、企業(ユーザ)毎の方針にもよりますが、

  • 機密性の保持または向上
  • ネットワークの品質
  • 諸々の変更に伴う費用

上記の要因など、今までとは違う大規模な変化も考えられます。

企業のシステム環境は千差万別の為、一概には言えませんが、
そうなった場合、今後おき得るかも知れない変化に
運用担当も対応する場面に出くわすかも知れません。
(特にインフラ関係についての知識/理解が、
今まで以上に求められる場面が出てくる。)

今からでも、運用周り以外への理解や知識習得の為、
学習する事も必要な時期かも知れません。

運用は広く浅く、という意味で言うと、
大まかな部分までで良いとは思いますが。。

 

システム運用の勘所集 2010/12/27



昔から外注オペレータというのは存在していました。初期のころは本当のオペレータであり、決められた操作をまちがいなく遂行するのが主な業務内容でした。 しかし、業務量の増大、オンラインの導入などにより手作業によるオペレーションでは手がまわらなくなり、またミスも続発するようになりました。当時は、運用ツールとか自動化ツールはまだ出回ってはおらず、自分たちでどのようにしたらミスを削減できるかを日々格闘していたかと思います。単なるオペレータではなく、いっしょに問題解決を図っていく必要がありました。

そのためには、社員、外注の境界を作らずに同じ立場で仕事をしてもらう環境作りを行いました。問題を共有化し、同じ目標(想い)を持つことにより、オペレータ自身が直面する問題、課題に積極的に挑戦していたように思われます。また、部内での発表会ではオペレータにも参加してもらい発表する場を作りました。自分自身をアピール(わかってもらう)することの重要性をわかって欲しいと思っていました。

昨今は、アウトソーシング等の普及などにより担当業務が細分化、制限され、担当業務以外の業務については興味を抱かなくなり、淡々と業務をこなしており活気に満ちあふれた職場を見受けられなくなり寂しい感じがしています。

 
システム運用の勘所集 2011/12/26



弊社で提供している、ツール(System Index)はメインフレーム時代に開発したものをベースとしています。
当時はバッチ処理しかなかったのでバッチで作成したデータを参照するような仕組みでした。また、関連情報は自動的に取得されるものではなく人間が関連データを作成し、パンチして更新するようになっていました。

プログラムを本番にリリースする場合は、このインプットを作成するのが条件になっていました。今思うと大変な労力のような感じがしますがこのツールがあるおかげでコンバージョン(マシン変更、OSのバージョンアップ)がスムーズに行うことができました。

AS/400の場合は、様々な情報がシステム内に存在するために、コマンドを駆使すれば欲しい情報を見ることはできます。しかし、残念ながら担当者の経験および手作業に頼る部分が多いように見受けられます。
プラットフォームが変わり、人が変わり、テクノロジーが進化しても実際の現場で必要とされるツールは時代を超えても生き続けるものだとひとり自画自賛しています。

 


Copyright (C) 2010 Cyflex. All Rights Reserved.