システム運用とは？運用設計書に必要な記載項目を分かり易く解説！

一般的に「IT業界」≒「プログラマ」or 「インフラエンジニア」と捉えられることは至極普通なことだと思います。その証拠にIT業界へ転職を考えている方のほとんどが、ネットの検索蘭へ「IT プログラマ エンジニア 年齢」等の単語を入力してこのサイトへたどり着いています。

現在ではコロナ禍の影響もあり、何処の企業も積極的な設備投資を控えるようになりました。以前のような「システム導入」フェーズから、少しでも長くシステムを延命するために「システム維持」フェーズへ移行する企業が増えてきたように思います。

システムを維持するためには、必ずどこかで人手の作業が必要になります。すべてが完璧に組まれ、すべてが自動的に動いていれば問題ありませんが、そこまでは到達しているシステムなど見たことがありません。

ベテランの域に達した「プログラマ」や「インフラエンジニア」でもシステムを維持管理していく知識を持っている人はほんの一握りです。今後、日本のIT業界はシステムを維持管理するための専門職である「運用・保守エンジニア」の重要さがクローズアップされていくことになるでしょう。

システム運用とは

システム運用とは、サーバーやネットワークがトラブルで停止しないように、システムの管理・運用をすることです。ITプロジェクトにおいて「設計・構築」にかける期間は有限（期限が決まっている）に対して「システム運用」は、サービスが終了するまで続くという大きな違いがあります。

例えば、業務システムリリース後に不具合や障害が発生した場合、起こった障害に対応する人がいなければ、そのシステムが提供する様々なサービスを継続して提供することは出来ません。

つまり、システム運用を実施しないと、せっかく作ったシステムの機能が利用できず、そのシステムが存在する意味が無くなってしまうのです。こうした事態を避けるために、システムの管理・運用に必要な作業を運用設計書として作成しておく必要があります。

システム運用設計とは

システム運用設計とは、システムの運用に必要な作業を取りまとめてルール化することです。具体的には、障害を検知した場合「対応方法」や「エスカレーション先」などを予め決めておきます。

近年のシステム開発では、このシステム運用設計がキチンと作成されていないまま、システムをリリースしてしまうケースが少なくありません。何故なら、プロジェクト責任者の多くは「システム開発」出身者が多く、直接利益に直結しない「システム運用」は「特定のハイスキルな運用担当者がいれば、後でなんとかなる」という思いが心の何処かにあるためです。

小さなシステムの場合なら、それでもなんとかなることも確かにあります。が、規模が大きくなるにつれて「システム運用」が設計されていないばかりに、属人化が進み、取り返しのつかない事態にまで発展するプロジェクトが後を絶ちません。

Beエンジニア

【IT業界】他業種から運用・保守エンジニアを目指すには？【未経験】

https://www.pmi-sfbac.org/operation-engineer

これまで余り浮き彫りにされることはありませんでしたが、IT業界において、ここ数年で運用業務が大々的にクローズアップされ始めています。一人前のエンジニアでも「システム運用」について理解している人は多くありません。ITシステム≒プログラマ・エンジニアと置き換えられることが多かったこれまでと違い、これからのITシステムには運用方面でのスペシャリスト「運用・保守エンジニア」が注目されています。運用・保守エンジニアとはシステム運用は、サービスが終了するその時までシステムリプレースや機能追加などの体制を維持し、...

運用設計の3分類

システム運用は、大きく分けて「業務運用」「基盤運用」「運用管理」の3分類に分けることが出来ます。

この記事では多くを語ることは割愛しますが、各分類に対して「代表的な運用項目」について軽く言及します。

業務運用

業務運用は、主に利用者とシステム運用側とのやり取りが円滑に行われるようにすることが主な目的となります。

業務運用に携わるには、ある程度のキャリアが求められます。金融業や保険業、公官庁、自動車業、etc･･･など、同種の案件に従事していた経験があることが前提となります。業務の中心となるアプリケーション群の大半は、企業の特色に合わせたオーダーメードで作成されていることが多く、その業界 or 企業特有の業務色が色濃く反映されているためです。

業務運用は、企業特有のノウハウを中心的に扱うため、スクリプトによる自動化や、システマチックな仕組みを作りずらい傾向にあります。また、企業特有の業務を中心にアプリケーションが作成されているため、障害時の対応方法や対策をネットから検索することは出来ません。

アプリケーションを介して直接利用者とつながるため、業務運用で発生した障害は、必然的に緊急度「高」として即座にサポート管理の対象となります。業務運用の良し悪しによって、企業としての「信頼性」「技術力」が問われる非常に重要な業務となります。

実際に手掛ける業務の内容は、構築するシステムの内容によって大きく変動します。

基盤運用

基盤運用は、一般的な基盤に関する知識さえあれば業務知識は特に必須ではありません。業務アプリケーションが稼働する土台（サーバ機器・ネットワーク機器）等の「H･W（ハードウエア）」及び「OS（オペレーティングシステム）」「M/W（ミドルウエア」の安定稼働が主な目的となります。

システム基盤は、アプリケーション等とは違って非常に高額な機器を必要とします。一度導入すると簡単には載せ替えることが出来ず、古い技術が継続的に使用され続けていく特徴があります。

基盤運用の主な業務は、日々システムの監視を実施します。ネットワーク切断の原因調査や、アップデートなどで不具合が発生した場合、バックアップデータからリストア・リカバリまでカバーします。

「基盤運用」は、定期的なデータベースの自動バックアップや、一定期間を超過したログの自動退避スクリプト実行等、一度仕組みを確立することで運用項目への増減は発生しません。

運用管理

運用管理とは、運用に関わる人が守るべきルールと基準を決めることです。「業務運用」「基盤運用」が統一した基準で行われるようにすることが目的となります。

例えば、主にリソース（CPU、メモリ、ディスク）使用率やシステムの稼働状況など、運用維持に必要とする情報を定期的に自動で収集します。

また「Aサーバのメモリ使用率が80%を超えたら異常、Bサーバのメモリ使用率は90%を超えたら異常」と言ったように、サーバ毎に閾値を設定していたのでは、管理上、混乱を招きます。

収集した値が一定の基準値を上回った場合「異常」それ以外は「正常」などをプロジェクト全体でルール化しておきます。

共通のルール、測定基準を適用することによって、システムを横断して運用状況を比較することが可能になります。

「基盤運用」と同様に、一度仕組みを確立することで運用項目への増減は発生しません。

システム運用設計の目的

システム運用設計の目的は「システムを安定稼働させて効率的にサービスを提供する」こととなります。また、システム運用設計は、さらに下記の５項目に分類することが出来ます。

上記5項目について、しっかりとした取り決めが行われていない場合、想定外の問題が次々と発生し、最終的に現場が混乱し始めます。一度混乱が始まるとその対応と再発防止策の検討で残業・徹夜が日常化してしまい現場は完全に疲弊してしまいます。そこで済めば良いのですが、大抵の場合、追い打ちをかけるように更なる障害（2次・3次）へとつながりデススパイラルが始まります。

運用の改善を行うにしても、「なぜ」その作業が必要だったのか・・、「誰」がその作業を行うべきだったのか・・など、どのような「ルール」で運用しているのかがわからなければ右往左往してしまいます。

運用設計書

運用設計書は運用設計内容を発注者側と合意するために作成する資料です。運用設計書がないプロジェクトは、運用方針があやふやになりがちです。中でも運用設計書は、いわば当該プロジェクトにおける「憲法」とも呼ぶべき存在です。

運用設計書に必須記載事項を如何に例示します。

どのような構成でシステムをくみ上げるのかは、プロジェクト毎にそれぞれの方針があると思いますが、一般的に運用設計書に記述するべき章立て構成は決まっています。

とは言え「理屈はわかるけど、実際何を書けば良いのか分からない」という方が大半なのではないでしょうか？ポイントは、関係者全員の「目線」を合わせるための資料だと言うことです。

下記に簡単に例を記載してお行きます。

「はにめに」の記載例

一般的に「はじめに」の章では、本書の「目的」と「対象読者」、「本書の構成」を記載します。

※１ 本記事の構成例は、あくまでも例示です。章立て項目の指定がある場合は、それに従ってください。

「システム構成」の記載例

※２：システム全体図は、運用対象となるシステムの全体像を把握するため、一目で俯瞰してみることができるイメージ図及び、各所の役割などを記載します。また、運用体制図、システム構成図、ネットワーク構成図、システムが実装している運用対象のハードウエア及び、運用対象のソフトウエアなどを転載します。 上記はあくまでも例示です。

「共通運用」の記載例

以下に共通運用の中からアカウント管理運用を抜粋して記述例を示します。

上記は「アカウント管理」を例に記載しましたが、共通運用には「アカウント管理」の他にも「役割」や「運用時間」「サーバ起動・停止」等、共通運用として記載されるべき項目が存在します。※ 上記はあくまでも例示です。

「通常運用」の記載例

以下に共通運用の中からバックアップ・リストア運用を抜粋して記述例を示します。

※ 上記はあくまでも「バックアップ・リストア運用」の例示です。通常運用には「バックアップ・リストア運用」の他にも「監視運用」や「ジョブ運用」「ログ運用」等、通常運用として記載されるべき項目が存在します。

ちょっと尺を長くとりすぎた気もしますが、バックアップ・リストア運用で重要なことは、保管領域として、1次保管領域と2次保管領域の概念を取り入れることです。

「障害運用」の記載例

※ 上記はあくまでも「障害運用」の例示です。現在では設備の多様化により、ここで挙げた以外にも障害運用として定義する項目が増えつつあります。対応の良し悪しで社の評価が決まってしまうほどシビアな項目ですので、システムにあった障害運用を定義して下さい。

「保守運用」の記載例

※ 上記はあくまでも「保守運用」の例示です。他にも「パッチ適用」や「リリース運用」「機能」など、記載する内容は多岐にわたります。

「セキュリティ運用」の記載例

※ 上記はあくまでも「セキュリティ運用」の例示です。

ここまで運用設計書を中心に記載してきましたが、運用設計で必要とするドキュメントは他にも存在します。

運用設計で必要な作成ドキュメントについては、下記リンクページを参照願います。

Beエンジニア

【作業品質改善】運用設計に必須な作成ドキュメントとは？【属人化排除】

https://www.pmi-sfbac.org/work-quality-improvement-equation

以前、システム運用とは「サーバーやネットワークがトラブルで停止しないようにシステムの管理・運用を行うこと」と述べました。まぁ、あながち間違いではないのですが、業務改善のコンサルを依頼されるたびに思うのは「その定義を少し改める必要があるのではないか？」と感じている事です。非情にジレンマに苛まれますが「顧客第一主義目線」の改善提案では、9割がた不採用となってしまいます。そこで、企業側の意図を見定めるために目線を変えたアプローチを行ったところ、某上場企業の社長様まで参加した一大プロジェクトになったこ...

まとめ

ざっと運用設計書の記載例を例示してきました。いくら良いシステムを構築しても、その後の運用設計次第で使えないシステムが出来上がってしまうことが実に多い気がします。

どんなシステムであっても、それを作り上げるアーキテクチャが同じなら、必ず運用に使用可能な方程式が見つかるはずです。学校で習った数学と同様に運用に必要とする最大公約数を求めることができれば、最適解は簡単に導き出すことが出来ます。

運用設計で重要なことは、公約数を求めやすくするために運用を仕組化して方程式発見までの導線を確保することにあります。

メインフレームの時代からダウンサイジングの号令を受け、進化し続けるIT業界の波は、今後も「AI」の登場によってますます発展していくと思われます。ですが「AI」に代表する技術の発展をもってしても、サービスを提供するための仕組化を設計することは、まだまだ先の話になりそうです。

恐らく、完全に自動化するまでには、もうワンステップ、「現状システム」の運用を分析して仕組みを公約数で管理するフェーズを得た後のことになるでしょう。今後は「運用・保守」のスペシャリストが益々求められる時代になると確信します。