概要
2005年10月から2006年3月に、システム管理者の会サイトの前進である”カイゼン活かす”サイトに掲載され、その後も根強い利用がある「運用規約、運用設計書」の筆者である「運用ゲンジン」ことＩＴシステム運用コンサルタント沢田典夫氏のコーナーが復活します。今回は、より具体的な内容で運用設計のポイント、運用の管理項目とプロセス、運用設計基準書内容等について、テンプレートを多数公開していただきます。
皆さんの運用カイゼンにお役立てください。
はやいもので
早いもので、ついこの前新年の挨拶をしたばかりなのにカレンダーはもう二月。
この分なら今年も早く終わってしまいそうな勢いです。
新種のウイルスが流行り始めているようですが、みなさんはいかがお過ごしでしょうか？ 一昔はマスクをしていれば風邪をひいてる人だとすぐわかったもんですが、最近では風邪をひいてる人はもちろんですが 風邪が移らないようにと予防でつけるかた、あるいは花粉症でつけるかたと様々で、 なんでマスクをしているのか聞かないとその事情が分からないものです。
ウイルスといえば、アメリカから端を発した１００年に一度という不況の波は日本だけでなく世界中に広がり、 歯車が噛み合わなくなった世界経済への特効薬もなく、この底の見えない状態はこれからさらに下降に向かい、 専門家の話ではこの状態が数年続くとも。
１００年に一度という不況の中、日本では消費税率を上げるための路線作りだの来年度予算の審議をどうするかだの、やれ二院制の見直しだとか、 職を失う人や倒産に追い込まれる企業もこれからさらに増えるというのに、ただ保身や政党を守りたいだけの日本の政治家の次元やレベルの低さにガッカリもし、 世界からも取り残され始めてる日本がこの不況を乗り切れるのかつい不安になるのは私だけでしょうか？
さて、愚痴はこのぐらいにし、今回のテーマは運用と開発という観点で話を進めてみましょう。
開発と運用
今でも多く残ってはいますが、担当者が開発しながら運用してた時代とは異なり、システムの生産性を追及し開発と運用が分離し始めてからは 開発と運用は犬猿の仲の関係で言われるようになりました。
開発からすれば、「なんでこんなことまでシステムで？」とか、「運用の仕事だろ？」とか、 運用からすれば、「開発なのになんで考えてない？」とか、「仕事やトラブルを増やすだけ」とか、 お互い立場や役割が相反するだけにどちらも譲らず。
掲載資料①【開発と運用】にもあるように、当時業務内容からして開発と運用を別けることは必然的なことだったとは思いますが、 その時の作業を単に開発と運用に分類したことが大きな間違えで、 分離しても両者が関わる移行や保守、また運用しない人がシステムを作るうえで統一した作りや運用を考えたシステムになるよう 開発標準や運用設計は取り残されたまま分離されたことが今日の開発と運用に大きな溝を残す結果になったといえます。
一昔は作りながら運用もしていたため、担当としてトラブルは出したくないし、オペレーションは楽にしたいため、必然的に運用設計をしてきたが、 開発と運用が分離され、運用設計のスキルは運用に残り、開発は運用から離れたことで運用の状態も見えなくなり、運用を考えたシステム作りは全くされなくなった。
標準的な運用設計の確立もこれからのオープン系の急速的な広がりで、最近でこそ運用設計の重要性が問われるようになり、 一昔の運用をしていた人たちを呼び戻す企業やメーカさえ現れるようになってきたが、当分試行錯誤が続くような気がします。
そもそも開発と運用という出し側、受け入れ側の立場の違う部門であり、運用からすると押し付けられ感が強く、運用設計支援をするにも日常業務で手一杯で工数を避けない、 また、開発からすると運用設計スキルは運用にあり、開発は運用を知らないのだからどんな設計すれば？という言い分があります。 まるでねじれ国会みたいですが、いいシステム、いいサービスを提供するのはどちらが主体ということはなく、両者で作り上げるものだと思いますが、 動きが見えない側よりも動きや作業を体感してる側が一番よく分かっていることですし、システムがどのような状態であってほしいのか、どうあるべきかは 運用がリーダシップを取って動くことがいいシステムを作り上げる鍵だといえます。
今実験的に試行しているのが、掲載資料①【開発と運用】の今後のイメージにもあるように、従来運用側で独自に行ってきた運用設計や移行機能を分離し、開発と運用を中継する部署（移行・運用）を儲け 運用設計、あるいは運用設計支援、リリースの判定や移行、全体的な運用状況を把握し、標準化などを随時改定する役割を専任化する体制です。 また、この機能を活かすためにも開発の作業工程では各フェーズでの運用設計の計画化やその審査という手続きなどがオーソライズされる必要がありますが、 今後ますます運用設計が重要になりますし、この試行状況や試行結果についてはこのサイトでご報告させていただきます。
みなさんの中で同様の体制を組まれてるかた、また別な方法を取られてる方がいらっしゃいましたら、ぜひ参考にさせていただきたいので運用ゲンジンまでご連絡ください。
掲載資料①
運用設計の領域とその作業役割分担
いつ運用設計をするのか
さて、前項では運用設計はみんなで検討し、みんなでいいシステムを作り上げるものとお話ししましたが、 運用が開始される直前に運用設計をしても時すでに遅しで、システムは運用設計がされないままリリースを待っている状態で、 この時点で騒いでも変更は間に合いませんし、結局は運用対処や手間のかかる運用をせざるを得ません。
一昔であればシステムを作りながら運用もしており、同時に運用設計もしていたのと同じで、作る人自身が楽するために自然にしてきたことですが 今では経験させる機会はあったとしても役割が分離されてる部署がほとんどで、見受けられることが余りない体制だと思いますが、 もし作りながら運用する体制を取ってる部署がありましたら、生産性や効率、またセキュリティー面は別としても、是非その設計スキルを大切にしていただきたいと思います。
つまり、運用の状態はほとんどシステムを設計する段階で決まるもので、上流で運用を意識していないと煩雑な運用、作業負荷が高くミスを発生させやすい運用になりやすいため、 運用設計は上流段階で実施することを鉄則としてください。
運用設計は誰が行うか
システムを作る上流段階で運用設計を行いますが、上流だから開発というわけではありませんし、運用設計だから運用が行うものではありません。 大きくは業務や機能要件から発生する業務的な運用設計、そのシステムを動かすことで発生する管理や作業面としての運用設計に分かれ 業務的な運用設計は開発、管理作業面での運用設計は運用が受け持ち、両者の得意分野でシステムやその運用を構築することがいいシステム作りに繋がります。
運用設計の領域は
両者で運用設計を行うとして、どちらがどの範囲の運用設計を行うのか、 掲載資料②【運用設計の領域】にもあるように、開発側ではシステムやサービスに関わる範囲、 運用は他のシステムやサービスを含めて預かるシステムの全体の側面から運用を考えなければなりません。
開発は作るシステムやサービスの面で考えますが、運用はその作られるシステムだけを預かるわけではなく、 他の同居するシステムや預かってるシステム全ての運用と合せて考える必要があります。
なぜ運用は作られるシステムの範囲ではなく預かってるシステムの全体で考えなければならないのか？ 預かってるシステムだけを運用するのであればそれでいいのですが、運用は預かってるシステム全ての運用を任されてるわけで、 そのシステム独自の運用をすれば運用方法は他のシステムとは異なり、バラバラな運用になることで作業の負荷や手間、また、 使用するＩ／Ｏも競合したりと、計画的な作業も行えず人手不足を招きやすくもなります。
この点が開発と運用の大きな違いであり、開発側では分からない設計ポイントでもあります。
掲載資料②
できない運用設計
システムの範囲での運用設計はだいぶ行われるようにはなりましたが、運用全体での運用設計という面では手が届かないところも多いようです。 それは急速なオープン化により短期間で構築されることで全体での運用設計が追いつかないことや、運用情報が不足していることにより、 全体の運用状況が見えない、また、どんな設計をすればいいか分からない、 運用全体を分かって運用設計が行える要員やスキル不足が大きな原因なようです。
特に急速なオープン化では運用が運用設計に参画できる機会もかなり減ってきており、一昔のシステム毎のバラバラな運用が増加しつつあるようですが、 運用の力でこういった傾向にブレーキをかけたいものです。
そのためにも日ごろから運用設計ガイドラインや運用設計チェックシート、運用情報の蓄積、設計できる運用者のスキルアップは欠かせません。 今後運用設計事項に触れていきますが、ガイドラインや設計チェックシート、あるいは設計者のスキルアップなどでなにかありましたら前項同様運用ゲンジンまでご連絡ください。
目指す運用の姿
掲載資料④および第二話で簡単に運用の姿の変化をまとめてありますが、 初期のころはいかに大量の処理や媒体、ＭＳＧ類を正確・確実にさばくかが運用に課せられた役割でしたが、 技術の進歩や運用ツールの出現により自動化が急速に進み、運用の姿は一変し監視することに重点が置かれるようになりました。 ただ、それにはコストやアプリの改修が伴うため改善によって徐々に削減はされてきてはいるものの、 操作やハンドリング作業を今だオペレータに依存せざるを得ない運用も多く残っています。
【監視】
この状態で改善が進めば監視が運用の主な作業になるはずでしたが、統一化や標準化がされないまま急速にオープン化が進んだことで煩雑な運用が広がり、 安定したホストとバラバラなオープン系の運用を見直したり統一化したり、オペレータ作業の削減のための改善がしばらくは続きそうです。 また、監視も見直され、単なる監視・通報だけでなく、異常時のアクションやリカバリーもだいぶ自動化が進むが無人化にはならず、まだまだ人の判断は残るものと思われます。
【管理】
初期のころの運用とはだいぶ姿は変わりますが、単なる労力としての作業は今後も削減され、近い将来オペレーションやオペレータという言葉は変わったりなくなるのかも知れませんが、 運用で一番重要なのはシステムを自動化や安定稼動させるために多くの管理・作業がきちんとなされてこそ成し遂げられるものであり、 システムが動いてる間はこういった管理は確実に残り、また自動化が進めば進むほど管理することは増加し、運用のほとんどは維持するための管理が主体になっていくものと思われます。
また、管理していく上ではＩＴＩＬやＪＳＯＸなどの基準や法的な手続き／手順の基での管理・作業が求められるため、従来の作業中心型の体制より管理中心型の体制にスライドが必要になるはずです。 ただ、これらの多くの管理・作業を人手で行うには限界があり、今後は人の作業に対するシステム化や管理ツールが多数出てくるものと想定されます。
【運用設計】
管理中心型の体制作りでは、ホストおよびオープン化が混在した煩雑な運用の見直しや、運用する側としての運用設計力が今まで以上に必要となり、 インフラ担当と共同による運用設計役割や専門チームが結成されるようになり、従来の運用担当者のスキルアップが重要な鍵になってきます。
連載一覧
筆者紹介
沢田 典夫（さわだ のりお）
１９５１年生まれ。運用との出会いは某銀行でのオペレータに始まり、７年間富士通 フィールドＳＥとして多くのメインフレームの導入の企画提案、移行、ＯＳ試験、環 境設計や構築～チューニング、また業務システム開発などを手掛ける。また、某大手 トレーディングスタンプ会社で１３年間、コンピュータの導入、業務システムの開発 （物流・販売・財務・経営）および運用を行い、この時に開発の標準化、自動運転環境構築、運用設計や運用改善、また、運用ツールの開発などを手掛け、運用の基盤を 確立する。その後ＢＳＰ一期生として入社し、運用診断や運用企画、また、運用設計 を重視した運用ツールの導入などを行い、コンサル事業の基盤作りを行う。その後運用コンサルとして独立し、これまでの経験を生かし、運用する人の立場に立ち、ま た、運用改善は永遠のテーマを掲げ、１６年間一匹狼で運用と向き合ってきました。
コメント
投稿にはログインしてください