運用グランドデザインで運用設計全体のベース(前提)を可視化できたら、運用基本設計を進めていきましょう。
・作業分類・グループ
・統制が意識された運用体制図
・規定するITSMプロセス一覧と、ITSMプロセス間の連携図
・規定する作業管理プロセス一覧
・作業場所とアクセス経路の整理結果
運用基本設計では、以下のステップで人が実施する運用作業を具体的に洗い出し、作成すべき文書やツールを可視化していきます。
1.文書体系の検討
2.システム運用作業の可視化
3.運営業務作業の可視化
4利用する管理ツールの検討
なお、運用基本設計は、開発チームが実施するシステムの概要設計や基本設計のタスクと並行して行い、開発チームと認識のずれがないようにしてください。
2.1.文書体系の整理
運用基本設計ではまず文書体系の検討を行います。この段階で文書体系を決めておく事で、システム設計文書だけでなく、運用に必要となる文書の全体像を把握する事ができますので、最初に文書体系を整理する事をお勧めします。
システム設計文書については「基本設計書」や「詳細設計書」など、会社や組織で文書体系が定められている事も多いと思いますが、運用系文書については特に定められていないケースが多くあります。「何を作ればよいのか分からない」という場合には、以下のような観点で体系を整理していくと分かりやすいと思います。
- システム設計書と運用系文書とは独立した分類とする
- 利用者向け文書は独立した分類とする
- システム運用文書と運営業務文書は分類を分ける
- システム操作手順書は「どのような時に使う手順か」によって文書を分ける
以下の図は、上記の観点を考慮した文書体系の例です(外部向けサービスの例)。
こうして俯瞰する事で、ITシステム(サービス)運用に必要な文書の概観がつかめるのではないでしょうか。システム(サービス)の特性によって若干違いは出るかもしれませんが、一般的にはほぼこの体系で整理できると思います。
また、文書体系は一覧化し、各文書に記載されるべき内容についても明文化します。上の図を一覧化した例を以下に記載します。
| 文書分類 | 文書 | 記載内容 |
|---|---|---|
| 企画文書 | サービス(orシステム)企画書 | サービス(orシステム)の開発を承認するための判断材料として、以下のような内容を記載する。 (企画書自体はリリース後はメンテナンスされるものではないが、ビジネス状況については定期的な確認と見直しが必要なため、初期情報として文書管理する） ・サービス内容 ・ビジネス計画 ・システム概要/提供体制概要/ロードマップ など |
| 利用者向け文書 | サービス契約書 | サービスの契約条件を記述する。 |
| サービス仕様書 | サービス使用を記載する。 ・提供機能 ・責任範囲と利用者との役割分担 ・サービス提供時間 ・サポート内容 など |
|
| サービスレベル合意書 | 提供するサービスのサービスレベルを記載する。 | |
| サービス利用ガイド | サービスを利用するにあたってのガイドを記載する。 ・サービス申込から利用開始までの手続き ・変更/解約手続き ・問い合わせ方法 ・利用マニュアル など |
|
| 利用者向け帳票 | 手続きにあたって利用者が記入する帳票。 | |
| 販促資料 | 販促資料 | 営業活動に使用する、サービスの販促資料。 |
| システム設計書 | システムアーキテクチャ設計書 | システム全体のアーキテクチャ設計を記載する。 |
| システム基本設計書群 | システムに対する機能要件・非機能要件の実現方式を記載する。 | |
| システム詳細設計書 | システム実装にあたり、HW・SW・NW・クラウドサービス等に設定するパラメータを記載する。 | |
| プログラム設計書 | プログラムのI/O及びアルゴリズムを記載する。 | |
| システム運用文書 | システム運用規定書 | システム運用のための規定(ルール)。 ・体制と役割 ・管理プロセスフロー ・運用作業項目一覧 |
| システム運用関連帳票 | システム運用に必要となる帳票。 | |
| システム運用関連台帳 | システム運用に必要となる台帳。 | |
| 通常運用操作手順書 | 通常時の運用作業(定型作業)の操作手順。 | |
| 障害一次対応手順書 | 障害一次対応作業(定型作業)の手順。(一般的には運用オペレータ向け) | |
| 障害二次対応手順書 | 障害二次対応作業(非定型作業)の手順。(一般的には保守SE向け) | |
| 保守操作手順書 | 保守SEが保守作業を実施する際に参照する手順。 | |
| 運営業務文書 | 運営業務規定書 |
運営業務のための規定(ルール)。 |
| 運営業務関連帳票 | 運営業務に必要となる帳票。 | |
| 運営業務関連台帳 | 運営業務に必要となる台帳。 | |
| 運営業務手順書 | 運営業務の手順を記載する。 |
2.2.システム運用作業の可視化
次に、システム運用作業の可視化を行います。システム運用作業の可視化は、以下の順番で行いますので、それぞれの詳細についてご説明します。
(1)運用機能を軸に自動・手動を整理する
(2)手動作業を「運用作業項目一覧」として整理する
(3)管理プロセスから運用作業を抽出して追加する
2.2.1.運用機能を軸に自動・手動を整理する
システム開発では監視機能・ジョブ実行機能・バックアップ機能など、運用のための機能も実装されますが、システムの初期フェーズで、運用機能の利用者として積極的に要望をインプットする必要があります。
なお、システム実装機能の要求を整理するためには、運用作業(自動処理・人の作業)についても併せて検討する必要があります。
例えば、「OSのリソース状況を毎月確認して報告する」という運用作業をサンプルとして考えると、以下のようなイメージとなります。
この例では、「運用者が参照できる領域に、OSリソース情報を格納する」という所までは自動的に行われ、「分析とレポート化」は人が行う作業という事になります。
当たり前の話ですが、システム実装しない限り、自動的に処理が行われる事はありません。つまり、「システムで実装する機能」・「運用作業(自動処理)」・「運用作業(手動)で利用するツール」は、運用観点でのシステム要件として開発チームに認識してもらう必要があります。
もしこの整理を行わないままシステム開発が行われた場合、何が実装されるかは開発チーム任せになってしまい、運用への皺寄せのリスクを抱え込む事になります。
同様に、監視・バックアップ・ジョブ・リリースなど、「システム運用」に関わるものについて同じように整理していきます。
下表は、クラウド(AWS)上に構築するシステムの運用機能と運用作業(自動/手動)を整理した例です。
「どこまで自動化するべきか」、「どうやってその機能を実装するか」という事は、会社全体の環境やシステム(サービス)の特性や制約によって違ってきますので、各システム(サービス)にあわせて整理を行ってください。
繰り返しになりますが、この整理はシステム開発の上流工程へのインプットになりますので、開発チームと共同で行う事が重要です。
| 分類 | システム実装機能 | 運用作業(自動) | 運用作業(手動) |
|---|---|---|---|
| 監視 | ・システム監視 -AWS層のサービス障害監視 -NW障害監視 -仮想OS自体の障害監視(死活監視) -仮想OS内の障害監視(プロセス/サービス/ログ監視) -OSリソース(CPU/メモリ/ストレージ)使用状況監視 -DBリソース使用状況監視 -外部からの疑似アクセス監視 ・障害一次対応手順を特定するためのフィルタ機能 ・障害一次対応用のツールを監視画面から実行できる機能 |
監視基盤でエラーを検知し、監視画面に表示すると共にパトライトを鳴動させる。 | ・監視基盤上に実装されたフィルタ機能を用いて一次対応手順を特定する。 ・一次対応手順書に従い、監視基盤上に実装された一次対応ツールを実行する。 |
| 性能管理 | ・仮想OSリソース(CPU/メモリ/ストレージ)情報収集・蓄積 ・NWリソース(通信データ量)情報収集・蓄積 ・DBリソース情報収集・蓄積 ・MW/APリソース情報収集・蓄積 ・蓄積した情報を期間指定で運用領域にコピーする機能 |
・リソース情報の収集が自動で行われる。 ・月次ジョブで、先月分のリソース情報を運用者が参照できる領域にコピーする。 ・月次ジョブで先々月分のリソース情報をアーカイブ領域にコピーする。 |
先月分のリソース状況を分析し、レポート化する。 |
| ジョブ管理 | ・定期的にスケジュールジョブ(日次/週次/月次/年次)を実行する機能 ・手動実行ジョブを登録しておき、任意のタイミングで手動実行できる機能 ・ジョブの実行遅延を検知できる機能 |
・スケジュールジョブは自動実行される。 ・エラー発生時や実行遅延時には、監視基盤を通じて検知される。 |
・ジョブ異常終了時には、障害一次対応手順に従い、ジョブの再実行やスキップを行う。 ・作業手順に従い、手動実行ジョブを実行する。 |
| 構成管理/ 資産管理 |
サーバOSの構成情報(OSバージョン・パッチ情報・SW情報)の収集・蓄積 | ・構成情報の収集が自動で行われる。 ・月次ジョブで先々月分の構成情報をアーカイブ領域にコピーする。 |
年次で、別途管理しているライセンス台帳上の数量とずれがないかを確認する。 |
| バックアップ | ・仮想OSのシステムバックアップ/リストア ・DBデータのバックアップ/リストア |
DBデータは自動バックアップする。 | ・仮想OSのシステムバックアップは、システム変更時にAMIにてマシンイメージ保存を手動で実行する。 |
| ログ管理 | ・AWS層のアクセスログ・監査ログ収集・蓄積 ・仮想OSのシステムログ収集・蓄積 ・DBのログ収集蓄積 ・MW/APのログ収集・蓄積 |
全てのログ収集・蓄積を自動で行う。 | なし (必要に応じてログを参照する) |
| ウィルス対策 | 仮想OS上のウィルス対策機能(AWSのTrendMicroサービスを利用) | パターンファイル/エンジンを自動で配信する。 | パターンファイル/エンジンの更新状況を確認する。 |
| パッチ適用 | 仮想OSにパッチを適用する機能(AWSのSystem Managerサービスを利用) |
なし | ・パッチ選定ポリシーに基づいてパッチを選定する。 ・変更管理プロセスにのっとり、パッチ適用検証と適用を実施する。 |
| APリリース | APをデプロイする機能 | なし | 変更管理プロセスでリリース承認されたAPを、手順書に基づいてデプロイする。 |
| 運用アカウント管理 | 運用アカウントを払い出しできる機能 | 作業申請に紐づいて、以下が自動処理される。 -特権アカウントのパスワード払出 -特権アカウントのパスワード変更 |
・申請に基づき、個人アカウントを作成する。 ・申請に基づき、個人アカウントのアカウントロック解除を実施する。 |
2.2.2.手動作業を「運用作業項目一覧」として整理する
先ほど整理した運用機能と運用作業(自動・手動)の一覧から、人が手動で実施する作業を抽出し、「運用作業項目一覧」として整理します。
整理にあたり、以下の点を追加しておくと今後の運用作業見積もりや運用体制検討に役立ちます。
・定型作業なのか、非定型作業なのか
・定例作業(日次、週次、月次、年次等)なのか、随時発生する作業なのか
・その作業はどのグループが担当するのか
| 運用作業 | 定型/非定型 | 作業周期 | 担当グループ | 作業概要 |
|---|---|---|---|---|
| 障害一次対応 | 定型 | 随時 | 運用オペレータ | ・監視基盤上に実装されたフィルタ機能を用いて一次対応手順を特定する。 ・一次対応手順書に従い、監視基盤上に実装された一次対応ツールを実行する。 |
| 性能レポート作成 | 定型 | 月次 | 運用オペレータ | 収集されたデータを基に性能レポートを作成する。 |
| ジョブの再実行・スキップ | 定型 | 随時 | 運用オペレータ | ジョブ異常終了時には手順に従ってジョブの再実行やスキップを行う。 |
| ジョブの手動実行 | 定型 | 随時 | 運用オペレータ | 依頼に基づいて手動実行ジョブを実行する。 |
| ライセンス棚卸 | 定型 | 年次 | 運用オペレータ | 実機上の情報と別途管理しているライセンス台帳上の数量とずれがないかを確認する。 |
| バックアップデータリストア | 非定型 | 随時 | 基盤保守SE | 障害対応などで必要に応じてバックアップデータをリストアする。 |
| ウィルスパターンファイル確認 | 定型 | 週次 | 運用オペレータ | ウィルスパターンファイル/エンジンの更新状況を確認する。 |
| パッチ適用 | 非定型 | 年次 | 基盤保守SE | ・パッチ選定ポリシーに基づいてパッチを選定する。 ・パッチ適用検証と適用を実施する。 |
| APリリース | 定型 | 随時 | 運用オペレータ | リリース承認されたAPを、手順書に基づいてデプロイする。 |
| 個人アカウント作成・削除 | 定型 | 随時 | 運用オペレータ | 申請に基づき、個人アカウントを作成する。 |
| アカウントロック解除 | 定型 | 随時 | 運用オペレータ | 申請に基づき、個人アカウントのアカウントロック解除を実施する。 |
2.2.3.管理プロセスから運用作業を抽出して追加する
前の章では運用機能から運用作業項目を抽出しました。
更に、1.運用グランドデザイン内の1.2.規定する管理プロセスの検討で整理した、管理プロセス(ITSMプロセス・作業管理プロセス)から運用作業を抽出します。
まず、ITSMプロセス間関連図から人が実施する事になるであろう部分をマークします。
下図は、1.運用グランドデザイン内の1.2.規定する管理プロセスの検討でも例示したITSMプロセス間関連図の運用作業が必要となる箇所に赤丸をつけたものです。
赤丸をつけた箇所を確認し、前章で整理した運用作業項目に不足しているものがあれば追加します。この例では、以下の3点が追加となります。
| 運用作業 | 定型/非定型 | 作業周期 | 担当グループ | 作業概要 |
|---|---|---|---|---|
| 利用者の要求に基づく定型作業 | 定型 | 随時 | サービスデスク | 利用者の要求に基づき、あらかじめ定められた手順に従って作業を実施する。 |
| サービスレベルレポート作成 | 定型 | 月次 | 運用オペレータ | あらかじめ定められた手順に従い、サービスレベルレポートを作成する。 |
| アカウント突合 | 定型 | 定型 | 運用オペレータ | あらかじめ定められた手順に従い、アカウント管理情報と実機情報の突合を実施する |
同様に、作業管理プロセスからも不足している運用作業を抽出して追加します。
1.2.3. 運用シーンを想像して管理プロセスを追加するで記載した例ですと、以下のような運用作業が抽出されます。
| 運用作業 | 定型/非定型 | 作業周期 | 担当グループ | 作業概要 |
|---|---|---|---|---|
| パスワード定期変更 | 定型 | 半年毎 | 運用オペレータ | パスワードの定期変更を実施する。 |
| 不正アクセス確認 | 定型 | 日次 | 運用オペレータ | 申請作業以外のアクセスがないかを確認する。 |
| 運用作業室権限棚卸 | 定型 | 年次 | 運用オペレータ | 運用作業室の権限付与状況が適切である事を確認する。 |
これで、システム運用作業の可視化は完了です。
2.3.運営業務作業の可視化
次に、運営業務作業の可視化を行います。「運営業務」とは、サービス利用者とのやり取りを行う作業です。
下図は、1.1.運用体制(組織構造と各グループの役割)の検討を行う際に使った図です。
この図の「顧客フロント作業」部分が「運営業務」の領域です。
私は、運用設計を行うにあたり、「システム運用」と「運営業務」を意識的に分離しているのですが、その理由について少しご説明したいと思います。
以下は、一般的な運営業務の作業の例となります。
運営業務に必要なシステムやツールを会社や組織が持っていない場合には、必要機能を開発チームに要望としてインプットする必要があります。
| 運営業務作業 | 作業実施グループ | 作業概要 |
|---|---|---|
| サービス利用開始・変更・解約手続き対応 | 営業グループ | サービス利用者からの利用開始・変更・解約手続きをメールで受け付け、契約システムに入力する。 |
| 請求書発行 | 営業グループ | サービス利用者に請求書を発行する。 |
| サービス利用者からの問い合わせ対応 | サービスデスクグループ | メールもしくはサービス利用者ポータルからの問い合わせに回答する。 |
| サービス利用者への通知 | サービスデスクグループ | サービスの計画停止や障害情報を利用者ポータル・メールで通知する。 |
| サービス利用者向けサイトの更新 | サービスデスクグループ | サービス利用者向けサイトの更新を行う。 |
2.4.利用する管理ツールの検討
運用基本設計の最後の検討項目は、利用する管理ツールの検討です。
「運用管理ツール」と聞いて、みなさんはどのようなツールを思い浮かべるでしょうか？ZabbixやDATADOGのような監視ツールを思い浮かべる方もいると思いますし、ServiceNowのようなITSMツールをイメージされる方もいらっしゃると思います。
下図は、「運用ツール」として有名なツールを分類したものですが、運用設計の領域では、一般的には右の水色背景の範囲のツールについて、何を利用するかを検討します。
システム(サービス)の規模や特性に応じて、適切なツールは何かを検討します。
※会社や組織で決められたツールがあればそれを利用すればOKです
-
ITSM&チケット管理ツール
ITSMプロセス(インシデント管理等)や、作業管理プロセス(作業申請等)を管理するツールです。
ServiceNowは会社レベルの大規模サービス向けクラウドサービスです。多機能で細やかなカスタマイズも可能ですが、逆に高度な設計・構築が必要です。ライセンス費用はかなり高額です。
LMISは簡単にITSMプロセス管理が簡単に行えるクラウドサービスです。国産サービスなので画面も馴染みやすいです。ライセンス費用もお手軽です。
Redmineは有名なOSSのチケット管理ツールですが、画面を自分で作成すればITSMツールとして活用する事ができます。自社内のサーバ上に構築する事も可能ですので、セキュリティ上の理由でクラウドサービスが利用できない場合でも対応できます。
規模が非常に小さい場合には昔ながらのExcel表という選択肢もあります。 -
運用作業自動化ツール
作業自体を自動化するツールです。AnsibleやTeraformといった基盤自動構築(IaC)ツールや、Power AutomateなどのRPAツール等、運用作業を自動実行するツールの導入についても検討します。
なお、監視・検知のためのツールは開発チーム側で検討されることが一般的ですが、最近では各ツールの対応範囲が広くなった結果、境界があいまいになってきていますので、開発チームとの認識がずれないようにする事も大切です。
2章のまとめ(運用基本設計の成果物)
これで、運用基本設計は終了です。以下の成果物ができていると思いますので、今後はそれぞれを詳細化していく事になります。
- 文書体系図＆文書体系一覧
- 運用作業項目一覧
- 運営業務作業一覧
- 運用管理で利用するツール
運用設計は、上流工程のグランドデザインと基本設計さえしっかり検討されていれば、後工程で大きな問題が発生する事はほぼありません。逆に、この工程での検討をいい加減に済ませていると、サービスイン間近にシステム構成自体を見直さないといけないような悲劇を招きますので、システムの概要設計や基本設計と並行してしっかりと検討するようにしてください。
