運用グランドデザインで運用設計全体のベース(前提)を可視化できたら、運用基本設計を進めていきましょう。
・作業分類・グループ
・統制が意識された運用体制図
・規定するITSMプロセス一覧と、ITSMプロセス間の連携図
・規定する作業管理プロセス一覧
・作業場所とアクセス経路の整理結果
運用基本設計では、以下のステップで人が実施する運用作業を具体的に洗い出し、作成すべき文書やツールを可視化していきます。
1.文書体系の検討
2.運営業務作業の可視化
3.システム運用作業の可視化
4利用する管理ツールの検討
なお、運用基本設計は、開発チームが実施するシステムの概要設計や基本設計のタスクと並行して行い、開発チームと認識のずれがないようにしてください。
2.1.文書体系の整理
運用基本設計ではまず文書分類の検討を行います。この段階で文書体系を決めておく事で、システム設計文書だけでなく、運用に必要となる文書の全体像を把握する事ができます。最初に文書体系を整理する事をお勧めします。
システム設計文書については「基本設計書」や「詳細設計書」など、会社や組織で文書体系が定められている事も多いと思いますが、運用系文書については特に定められていないケースも多く、「何を作ればよいのか分からない」という声をよく聞きますが、以下のような観点で体系を整理していくと分かりやすいと思います。
- システム設計書と運用系文書とは独立した分類とする
- 利用者向け文書は独立した分類とする
- システム運用文書と運営業務文書は分類を分ける
- システム操作手順書は「どのような時に使う手順か」によって文書を分ける
以下の図は、上記の観点を考慮した文書体系の例です(外部向けサービス)。
この図を見るだけでも、ITシステム(サービス)運用に必要な文書の概観がつかめるのではないでしょうか。システム(サービス)の特性によって若干違いは出るかもしれませんが、一般的にはこの形で整理しておけば問題ないと思います。
また、文書体系は一覧化し、各文書に記載されるべき内容についても明文化します。上の図を一覧化した例を以下に記載します。
文書分類 | 文書 | 記載内容 |
---|---|---|
企画文書 | サービス(orシステム)企画書 | サービス(orシステム)の開発を承認するための判断材料として、以下のような内容を記載する。 (企画書自体はリリース後はメンテナンスされるものではないが、ビジネス状況については定期的な確認と見直しが必要なため、初期情報として文書管理する) ・サービス内容 ・ビジネス計画 ・システム概要/提供体制概要/ロードマップ など |
利用者向け文書 | サービス契約書 | サービスの契約条件を記述する。 |
サービス仕様書 | サービス使用を記載する。 ・提供機能 ・責任範囲と利用者との役割分担 ・サービス提供時間 ・サポート内容 など |
|
サービスレベル合意書 | 提供するサービスのサービスレベルを記載する。 | |
サービス利用ガイド | サービスを利用するにあたってのガイドを記載する。 ・サービス申込から利用開始までの手続き ・変更/解約手続き ・問い合わせ方法 ・利用マニュアル など |
|
利用者向け帳票 | 手続きにあたって利用者が記入する帳票。 | |
販促資料 | 販促資料 | 営業活動に使用する、サービスの販促資料。 |
システム設計書 | システムアーキテクチャ設計書 | システム全体のアーキテクチャ設計を記載する。 |
システム基本設計書群 | システムに対する機能要件・非機能要件の実現方式を記載する。 | |
システム詳細設計書 | システム実装にあたり、HW・SW・NW・クラウドサービス等に設定するパラメータを記載する。 | |
プログラム設計書 | プログラムのI/O及びアルゴリズムを記載する。 | |
システム運用文書 | システム運用規定書 | システム運用のための規定(ルール)を記載する。 ・体制と役割 ・管理プロセスフロー及び実施内容 ・作業項目一覧 |
システム運用関連帳票 | システム運用に必要となる帳票。 | |
システム運用関連台帳 | システム運用に必要となる台帳。 | |
通常運用操作手順書 | 通常時の運用作業(定型作業)の操作手順を記載する。 | |
障害一次対応手順書 | 障害一次対応作業(定型作業)の手順を記載する。(一般的には運用オペレータ向け) | |
障害二次対応手順書 | 障害二次対応作業(非定型作業)の手順を記載する。(一般的には保守SE向け) | |
保守操作手順書 | 保守SEが保守作業を実施する際に参照する手順を記載する。 | |
運営業務文書 | 運営業務規定書 | 運営業務のための規定(ルール)を記載する。 ・体制と役割 ・運営業務一覧 ・運営業務フロー及び実施内容 |
運営業務関連帳票 | 運営業務に必要となる帳票。 | |
運営業務関連台帳 | 運営業務に必要となる台帳。 | |
運営業務手順書 | 運営業務の手順を記載する。 |
2.2.運営業務作業の可視化
「運営業務」とは、サービス利用者とのやり取りを行う作業です。
下図は、1.1.運用体制(組織構造と各グループの役割)の検討を行う際に使った図ですが、この図の「顧客フロント作業」部分が「運営業務」の領域です。
私は、運用設計を行うにあたり、「運営業務」と「システム運用」を意識的に分離しているのですが、その理由について少しご説明したいと思います。
2.3.システム運用作業の可視化
次に、システム運用作業の可視化を行います。システム運用作業の可視化は、以下の順番で行いますので、それぞれの詳細についてご説明します。
(1)管理プロセスの中から運用作業を抽出する
(2)運用機能を軸に自動・手動を整理する
(3)手動作業「運用作業項目一覧」として整理する
2.3.1.管理プロセスの中から運用作業を抽出する
まずは、管理プロセスの中から運用作業を抽出しましょう。
1.運用グランドデザイン内の1.2.規定する管理プロセスの検討で整理した、管理プロセス(ITSMプロセス・作業管理プロセス)から運用作業を抽出します。
2.3.2.運用機能を軸に自動・手動を整理する
この作業では、以下の3点を軸に整理します。
・システムに実装すべき機能
・運用フェーズにおいて、自動的に実行される事
・運用フェーズにおいて、人が手動で実行する事
例えば、「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.3.3.手動作業を「運用作業項目一覧」として整理する
近日公開予定
2.4.利用する管理ツールの検討
近日公開予定