エンジニアの知識

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

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

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

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

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

システム運用とは

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

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

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

システム運用設計とは

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

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

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

運用設計の3分類

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

システム運用の3分類

  1. 業務運用
  2. 基盤運用
  3. 運用管理

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

業務運用

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

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

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

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

業務運用の主な運用項目

  • システム利用者の管理運用
  • サポートデスク運用
  • 貸与PC等のライフサイクル管理運用

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

基盤運用

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

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

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

基盤運用の主な運用項目

  • バッチ適用等の管理運用
  • ジョブ・スクリプト等の運用
  • バックアップ・リストア運用
  • 監視運用
  • ログ管理
  • アカウント管理
  • 保守管理

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

運用管理

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

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

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

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

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

運用管理の主な運用項目

  • 運用維持管理
  • 運用情報統制
  • 定期レポート

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

システム運用設計の目的

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

システム運用設計の目的

  • 運用範囲の明確化
  • サービスレベルの安定
  • 属人化の排除
  • サービス品質の安定
  • ドキュメントの可視化

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

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

運用設計書

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

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

運用設計書必須記載事項

  • 運用に求められていること
  • 知っておくべきシステムの知識
  • 登場人物(アクタ)とその役割
  • 運用項目ごとの目的とゴール
  • 各運用項目で利用するドキュメント
  • 採用されなかった運用方針とその理由

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

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

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

「はにめに」の記載例

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

章立て構成例

1.本書の目的

    • システムを安定稼働させ、かつ効率的にサービスを提供する仕組みの構築
    • システム運用作業において担当者が変わっても常に同じ結果が出せる仕組みの構築

2.本書の対象読者

    • 本システムに関わるすべての関係者

3.本書の構成(1)

    • はじめに
    • システム構成
      • 「システム構成」の記載例参照
    • 共通運用
      • 「共通運用」の記載例参照
    • 通常運用
      • 「通常運用」の記載例参照
    • 障害運用
      • 「障害運用」の記載例参照
    • 保守運用
      • 「保守運用」の記載例参照
    • セキュリティ運用
      • 「セキュルティ運用」の記載例参照

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

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

「共通運用」の記載例

1.システム全体図

本書の対象とする●●システムにおける全体図を以下に示す。

2.運用体制図

 運用体制図を記載したイメージを貼り付けます。(

3.システム構成図

 システム構成を分かり易く記載したイメージを貼り付けます。

4.ネットワーク構成図

 ネットワーク構成を分かり易く記載したイメージを貼り付けます。

5.運用対象のハードウエア

 システムが実装するハードウエアの一覧表を記載します。

6.運用対象のソフトウエア

 システムが実装するソフトウエアの一覧表を記載します。

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

「共通運用」の記載例

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

「共通運用」の記載例

アカウント管理運用

1.基本方針

  • 必要最低限のアカウント構成とする。
  • 使用しないアカウントについて速やかに削除する。
  • 用途に応じたアカウントの分類ごとにアカウント一覧を作成する。
  • 準拠すべきアカウント管理ポリシーを定義する。

2.アカウントの分類

  • 用途に応じたアカウントの分類ごとにアカウント一覧を作成する。

3.管理ポリシー

  • WindowsServerでのアカウントポリシーは、サーバ毎にローカルポリシーを適用する。
  • アカウント、パスワード、ロックアウトなどアカウントに関する設定項目を定義する。
  • 用途に応じたアカウントの分類ごとに項目を定義する。
  • 用途に応じたアカウントの分類ごとにアカウント一覧を管理する。

4.アカウントフロー

 下記に基本的なアカウント(作成・変更・削除)の運用フローを示す。

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

「通常運用」の記載例

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

「通常運用」の記載例

バックアップ・リストア運用

1.基本方針

  • 本システムに障害が発生した場合に備え、早期に復旧することを目的とする。
  • バックアップ処理は原則ジョブ管理orバックアップ管理ソフトウエアにより自動化する。
  • 保存対象を分類し、指定した保管領域に指定期間保存する。
  • バックアップデータを保管するフォルダの構成はルール化する。

 バックアップ・リストア運用を設計するにあたり、いかに用語を定義する。

(1)リストア・リカバリイメージ

 リストア・リカバリの関係性を例示する。

 ※ リストア・リカバリイメージに記載はあくまでも暫定時間です。

(2)リストア・リカバリと保管領域

 リストア・リカバリ取得元領域の関係を示す。

2.バックアップ対象環境

 バックアップ運用対象環境を定義する。

 バックアップ運用の対象環境は、本番環境とし検証環境は必要に応じて取得することとする。

3.バックアップの種類

 バックアップの種類を定義する。

4.バックアップの採取

 バックアップの採取はバッチで制御し、ジョブ or バックアップ管理ソフトウエアにてスケジュール実行する。

5.バックアップの目的

 バックアップデータは用途に合わせて1次保管領域と2次保管領域で管理する。

(1)1次保管バックアップ

  • 情報システムに障害が発生した場合に備え、システムや重要なデータを出来るだけ早く復旧させることを目的とする。

(2)2次保管バックアップ

  •  使用頻度の低いデータや、法令や規定で一定期間、保存を義務付けられたデータを保存・保管することを目的とする。

6.世代管理

 世代管理を定義する。

(1)1次保管バックアップ

 以下に1次保管のバックアップ要件を示す。

(2)2次保管バックアップ

 以下に2次保管のバックアップ要件を示す。

7.バックアップ処理方式

 バックアップ処理方式を定義する。

(1)適用するバックアップ処理方式

(2)1次保管領域へのバックアップ処理方式

 情報システムに障害が発生した場合に備え、システムや重要なデータを早期に復旧させることを目的とする。

 ※3 対象のデータベースによって、どちらかの方式を選択する。

(3)2次保管領域へのバックアップ処理方式

 使用頻度の低いデータや、法令や規定で一定期間、保存を義務付けられたデータを保存・保管することを目的とする。

8.バックアップ保管処理フロー

 バックアップ保管処理フローをファイルバックアップにて例示する。

 データベースバックアップ、システムバックアップも同様とする。

9.パックアップデータ保管フオルダ

  •  保管領域のフオルダパスは、中分類、小分類の組み合わせにより決定する。
  •  2次保管領域については、保管するデータ量が膨大になることが予想されるため、年月毎にフォルダを作成し分類し、さらに、年月日毎のフォルダに圧縮して保管する。

 バックアップデータ保管フォルダを定義する。

10.リストア処理方式

 リストア処理方式は、適用したバックアップ処理方式によって決定する。

11.バックアップ・リストア管理台帳の管理(追加・変更・削除)フロー

 バックアップ対象の管理を行うバックアップ・リストア管理台帳の管理(追加ヽ変更・削除フローを示す。

 

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

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

「障害運用」の記載例

「障害運用」の記載例

障害運用

 障害発生時の迅速な対応による業務サービスヘの影響を最小化する為、障害時の運用を定義する。

1.基本方針

  • システム復旧対応時は、迅速な対応、正確な対応、運用負荷軽減を図るため、可能な限り自動化する。
  • 復旧作業は状況に応じて自動または手動で行うか判断する。
  • ハードウエアに障害が発生した場合、HW保守にて復旧作業を行う。ソフトウエア及びアプリケーションに障害が発生した場合、SW保守及びAP保守にて復旧作業を行う。

2.台帳管理

  • 対応中の障害情報を管理することを目的に「障害連絡票」で管理する。
  • 検知した障害情報は「障害管理台帳」で管理する。

3.障害運用フロー

  • 障害の現象・発生タイミング・メッセージ内容をもとに障害の原因を特定する。
  • 復旧対応・処理は障害対応担当者と連携を図り適正な障害復旧方式で対応を行う。

 障害検知時の処理フローを如何に示す。

4.障害復旧方式

  障害分類に適用する復旧方式については、物理設計工程で定義する。

(1)障害分類

 障害分類と障害分類を回復する復旧方式を定義する。

(2)復旧方式

 障害時の復旧方式を定義する。

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

「保守運用」の記載例

「保守運用」の記載例

保守運用

 システムを安定稼動させるため、保守運用を定義する。

1.基本方針

  • サービス継続の観点から、保守作業においてシステム停止を伴う場合には、その都度システム影響範囲を最小限にとどめる為に修正作業時間帯の調整を行う。
  • 予防保守において、セキュリティ対策として、定期的なセキュリティパッチの適用を実施する。適用の判断を協議し、検証環境での適用・動作確認を行った上で運用環境に適用する。必要に応じて計画停止も含んだ作業時間帯の調整を行う。
  • 保守作業実施時は、セキュリティの観点から各サーバへ直接接続は行わずに、踏み台サーバを立て、踏み台サーバを経由し各サーバへリモート接続を行うこととする。

2.保守の種類

 保守運用要件として定義した項目を保守作業の種類の分類とする。

3.保守の対象

 保守対象による分類を定義する。

(1)ハードウェア保守

 オンプレミス環境設置のサーバ機器、ネットワーク機器、ディスクファームウェアの保守について定義する。

(2)ソフトウェア保守

 サーバOS、ミドルウェアなどのソフトウェアの保守について定義する。

(3)アプリケーション保守

 開発の伴うアプリケーション保守について定義する

4.保守の定期実施

 保守作業の定期的な実施による分類を定義する。

5.保守管理台帳

 保守作業を管理する管理台帳などの管理書式を定義する。

6.保守運用フロー

 障害対応は障害時運用とし、保守は、あらかじめ決められた作業と位置づける。 

 保守管理台帳記入フローを示す。

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

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

「保守運用」の記載例

セキュリティ対策運用

1.アクセス制限運用

 ホワイトリスト・アプリケーション権限・共有フォルダなどの権限変更運用フローを示す。

 

2.セキュリティパッチ適用・セキュリティ定義情報適用

 セキュリティパッチ適用・セキュリティ定義情報適用については、「セキュリティパ ッチ適用」参照。 

3.セキュリティ監視運用

(1)不正侵入対策 (lDS/!PS)

  • システム内へ外部からの進入を検知した場合、「不正侵入対策 (IDS/IPS)」 が進入行為を検知し、監視サ ービスよリメール通知を行う。 

(2)ウィルス対策・改ざん検知

  • データセンタに展開するクラウド環境・オンプレミス環境のサーバを対象にウィルスが侵入しようとした際、DeepSecurityのリアルタイム検索が進入行為を検出し、アラートログを出力する。
  • ZabbiXのログ監視機能によリアラートログを検知し運用管理サーバよリメール通知を行う。

4.セキュリティインシデント運用

  • セキュリティインシデントは不正侵入及び、ウイルス感染などを指し、システムを復旧させるまでの管理を行う為に運用する。
  • セキュリティインシデント発生時は、障害区分をセキュリティとして、本書『別紙22_障害管理台帳』にて管理する。
  • 不正侵入の検知時は、「障害時の運用フロー」に従う。

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

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

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

まとめ

まとめ

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

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

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

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

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

よく読まれている記事

1

Shellとは? Shellとは、人間の理解できる言葉を機会へ伝えるプログラムです。 Linux環境でコマンドプロンプト画面を開いているとき、常にShellは起動している状態です。 「Shell」とは ...

2

Linuxは主にサーバー用として利用されるOSです。大規模な基幹システムの開発者、ロボットや家電開発等の組み込み系エンジニア、ネットワーク機器やデータベースに携わるインフラエンジニアは触れることが多い ...

3

プログラミング言語を習得しようと思った時、必ずと言っていいほど候補として挙げられるのが「Java」というプログラミング言語です。 「Java」は、現在日本で最も使われている言語であり、非常に人気のある ...

4

この記事は、Linuxについて勉強している初心者の方向けに「Shellスクリプト」について解説します。最後まで読んで頂けましたら、Shellスクリプトはどのような役割を担っているのか?を理解出来るよう ...

-エンジニアの知識