IT運用設計の進め方

~運用設計ってどうするの~

IT運用設計の世界へようこそ

このサイトをご覧になっているという事は、もしかしたらあなたはITシステム(orサービス)の運用、または運用設計で困っている方でしょうか。

  • 日々の運用業務がうまくいかず、何とか改善したい…
  • 新規システムの開発プロジェクトで、「運用設計チーム」のリーダーになったけど、どう進めてよいか分からない…

いや~、「運用」って、本当に難しいですよね。

「24時間正常に稼働していて当然」、「セキュリティは守られていて当然」と言いながら、「運用に金はかけられない」、「運用なんて誰でもできるでしょ」と考えている人の多さには、怒りを取り越して悲しみすら覚えます。

本来、ITシステム(orサービス)における「運用」は、「開発」と同じくらい重要なものです。いや、セキュリティやコストの観点ではむしろ「運用」の方が重要度は高いかもしれません。
また、適切な運用スキームを設計し、実行し続けるためには、非常に高い専門性が必要です。

しかし、残念ながらこの「運用の重要性・専門性」が不当なほどに理解されていないのが、日本のIT業界の実態だと思います。

「運用」とは何か?

日本のIT業界において、なぜこんなにも「運用の重要性・専門性」が理解されていないのでしょうか。私は、「運用」いう言葉の曖昧さが大きな要因の一つではないかと考えています。

少し具体的な例で考えてみましょう。

みなさんは、ITシステム(orサービス)の「運用」というと、どのような事をイメージされますか?
経験や状況によって様々だと思いますが、以下のような事をイメージされる方が多いのではないかと思います。

一般的な運用のイメージ・ジョブの実行状況の定期的確認などの、手順書に従ったシステム操作
・システムのエラー通知に対する、手順書に従った一次対応作業と連絡
・新規利用者の登録作業や、商品マスターの入れ替えなどの業務運用操作
・開発したアプリケーションを本番環境にリリースする、APリリース作業
・利用者からの問い合わせ対応や、利用者への請求などのサービス運営業務

上記の例だと、「運用」とは単なる「作業」です。「作業」なので「運用なんて誰でもできる」、「運用に金はかけられない」という話になる訳です。

・・・本当にそうなのでしょうか?

あなたが運用者として、実際に作業を行う事を想像してみてください。

個人的に運営しているWebサイトの作業を行う訳ではないのですから、組織のルールに従う必要がありますよね。ルールの例としては以下のようなものをイメージして頂くと、分かりやすいのではないかと思います。

運用作業に必要となるルールの例 ・何をきっかけに作業するのか
・どこから作業するのか(作業場所・作業端末)
・誰(どのチーム)が作業するのか
・作業にあたってチェッカーは必要か
・どの手順書で作業するのか
・手順書は誰が作成するのか
・最新版の手順書はどこで管理するのか
・作業内容や作業結果はどのように記録するのか
・作業中に発見した問題はどのように管理するのか
・作業実施にあたっての申請や承認はどうするのか
・作業者のアカウントはどう管理するのか
・特権アカウントはどう管理するのか
etc...

そうなんです!お気づきの通り、日本のIT業界では「運用」について語る際に、上記のようなルール決め・ルールの遂行管理が含まれていない事が多いのです。しかし、運用は開発のように一過性のものではなく、長期にわたって実行し続けるものですから、明文化されたルールを作って、その遂行を管理する事が必須となります。

この「ルール決め(運用設計)」や「ルールの遂行管理(統制)」は単なる「作業」ではありません。非常に高い専門性が必要です。

ITに関する全般的な知識・運用関連技術に対する深い知識はもちろん、セキュリティ・内部統制などの知識も必要です。また、開発チームに対してはシステム設計の段階から運用観点での要件をインプットしていくコミュニケーション能力も必要です。さらに、障害発生時には全体をコントロールするリーダーシップも必要になります。

しかし、この重要性・専門性があまり認知されていないせいか、運用設計の進め方について、体系的に書かれてる日本語の書籍やサイトは非常に少ないように思います。
もっとも、この分野の専門書籍としてはITIL®が存在します。しかし、あまりにもカバーする範囲が広い事と、学術的すぎて既に知識がある人にしか理解できないという点で、あまり実用的ではないと思います。
※もちろん個人的には ITIL® は大好きですが(笑)

本サイトの目的

本サイトでは、私のIT運用・運用設計の経験と、ITIL ® ・VeriSM™・SIAM™から得た体系的な知識をもとに、「日本のITシステム(サービス)の実態にあった運用設計」として、以下のような内容を中心にご紹介していきたいと思います。

  • IT運用設計の全体像を可視化する
  • IT運用設計でやるべき事を体系だって説明する
  • IT運用設計のアウトプットのサンプルを提供する

また、IT運用に関わる方のキャリアパスや、関連する認定資格などについてもご紹介していきたいと考えています。

本サイトが、IT運用で困っている方の助けになると共に、IT運用に関わる皆様の地位向上につながれば、これほど嬉しい事はありません。

 

2.運用基本設計

運用グランドデザインで運用設計全体のベース(前提)を可視化できたら、運用基本設計を進めていきましょう。

運用グランドデザインでは、以下の資料を作成しました。もしまだの場合は1.運用グランドデザインのページをご覧ください。
・作業分類・グループ
・統制が意識された運用体制図
・規定するITSMプロセス一覧と、ITSMプロセス間の連携図
・規定する作業管理プロセス一覧
・作業場所とアクセス経路の整理結果

運用基本設計では、以下のステップで人が実施する運用作業を具体的に洗い出し、作成すべき文書やツールを可視化していきます。

1.文書体系の検討
2.運営業務作業の可視化
3.システム運用作業の可視化
4利用する管理ツールの検討

なお、運用基本設計は、開発チームが実施するシステムの概要設計や基本設計のタスクと並行して行い、開発チームと認識のずれがないようにしてください。

2.1.文書体系の整理

運用基本設計ではまず文書分類の検討を行います。この段階で文書体系を決めておく事で、システム設計文書だけでなく、運用に必要となる文書の全体像を把握する事ができます。最初に文書体系を整理する事をお勧めします。

システム設計文書については「基本設計書」や「詳細設計書」など、会社や組織で文書体系が定められている事も多いと思いますが、運用系文書については特に定められていないケースも多く、「何を作ればよいのか分からない」という声をよく聞きますが、以下のような観点で体系を整理していくと分かりやすいと思います。

  • システム設計書と運用系文書とは独立した分類とする
  • 利用者向け文書は独立した分類とする
  • システム運用文書と運営業務文書は分類を分ける
  • システム操作手順書は「どのような時に使う手順か」によって文書を分ける

以下の図は、上記の観点を考慮した文書体系の例です(外部向けサービス)。
この図を見るだけでも、ITシステム(サービス)運用に必要な文書の概観がつかめるのではないでしょうか。システム(サービス)の特性によって若干違いは出るかもしれませんが、一般的にはこの形で整理しておけば問題ないと思います。

文書体系例

文書体系例

また、文書体系は一覧化し、各文書に記載されるべき内容についても明文化します。上の図を一覧化した例を以下に記載します。

文書分類 文書 記載内容
企画文書 サービス(orシステム)企画書 サービス(orシステム)の開発を承認するための判断材料として、以下のような内容を記載する。
(企画書自体はリリース後はメンテナンスされるものではないが、ビジネス状況については定期的な確認と見直しが必要なため、初期情報として文書管理する)
・サービス内容
・ビジネス計画
・システム概要/提供体制概要/ロードマップ
など
利用者向け文書 サービス契約書 サービスの契約条件を記述する。
サービス仕様書 サービス使用を記載する。
・提供機能
・責任範囲と利用者との役割分担
・サービス提供時間
・サポート内容
など
サービスレベル合意書 提供するサービスのサービスレベルを記載する。
サービス利用ガイド サービスを利用するにあたってのガイドを記載する。
・サービス申込から利用開始までの手続き
・変更/解約手続き
・問い合わせ方法
・利用マニュアル
など
利用者向け帳票 手続きにあたって利用者が記入する帳票。
販促資料 販促資料 営業活動に使用する、サービスの販促資料。
システム設計書 システムアーキテクチャ設計書 システム全体のアーキテクチャ設計を記載する。
システム基本設計書群 システムに対する機能要件・非機能要件の実現方式を記載する。
システム詳細設計書 システム実装にあたり、HW・SW・NW・クラウドサービス等に設定するパラメータを記載する。
プログラム設計書 プログラムのI/O及びアルゴリズムを記載する。
システム運用文書 システム運用規定書 システム運用のための規定(ルール)を記載する。
・体制と役割
・管理プロセスフロー及び実施内容
・作業項目一覧
システム運用関連帳票 システム運用に必要となる帳票。
システム運用関連台帳 システム運用に必要となる台帳。
通常運用操作手順書 通常時の運用作業(定型作業)の操作手順を記載する。
障害一次対応手順書 障害一次対応作業(定型作業)の手順を記載する。(一般的には運用オペレータ向け)
障害二次対応手順書 障害二次対応作業(非定型作業)の手順を記載する。(一般的には保守SE向け)
保守操作手順書 保守SEが保守作業を実施する際に参照する手順を記載する。
運営業務文書 運営業務規定書 運営業務のための規定(ルール)を記載する。
・体制と役割
・運営業務一覧
・運営業務フロー及び実施内容
運営業務関連帳票 運営業務に必要となる帳票。
運営業務関連台帳 運営業務に必要となる台帳。
運営業務手順書 運営業務の手順を記載する。

 

2.2.運営業務作業の可視化

「運営業務」とは、サービス利用者とのやり取りを行う作業です。
下図は、1.1.運用体制(組織構造と各グループの役割)の検討を行う際に使った図ですが、この図の「顧客フロント作業」部分が「運営業務」の領域です。

私は、運用設計を行うにあたり、「運営業務」と「システム運用」を意識的に分離しているのですが、その理由について少しご説明したいと思います。

IT運用 = 「運営業務」+「システム運用」

2000年代頃までは、IT運用というと、障害の監視対応・バックアップ取得・商品マスター更新などの「システムを維持するための作業」と考えていれば十分でした。
しかし、2010年頃からの「サービス化」や「デジタルトランスフォーメーション(DX)」の流れの中で、ITが「システム」から「サービス」の位置づけに変化する中で、「サービス利用者とのやり取り」を意識する事が必須となりました。

サービス利用者とのやり取りの例としては、以下のようなものがあげられます。改めて挙げてみると当たり前の事ですね(笑)

・サービス利用/解約の申し込みに対応する
・サービス利用者からの問い合わせに回答する
・サービス利用者からのメニュー変更依頼に対応する
・サービスの計画停止や障害情報を通知する
・マニュアルの最新版は常に最新化してポータルに掲載しておく
・利用量に応じて請求書を発行する
etc...

このような「サービス利用者とのやり取り」のプロセスや体制(ヘルプデスク等)を、会社などの組織全体として持っている場合にはそれに乗っかればよいのですが、個別のITシステム(サービス)側で新たに用意しないといけないようなケースも多くあります。

しかし、ITシステムの設計は一般的に「機能要件」・「非機能要件」を軸に設計されるため、「サービス利用者のやり取り」を行うための機能設計や運用設計が完全に漏れてしまい、サービス提供開始間際になって「これどうするんだ?」となってしまうサービスを多く見てきました。

こういった事を防ぐために、「サービス利用者とのやり取り」を「運営業務」として定義し、「システム運用」とセットで設計を行う事をおすすめしています。
(「運営業務」という言葉は、ITIL®などで定義された用語ではなく、私が個人的に用いている言葉ですのでご留意ください)

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.利用する管理ツールの検討

近日公開予定