読書メモ「運用設計の教科書」その 1

「運用設計の教科書」を読んだメモです。運用設計全体のイメージがつかめ、プロジェクトを想定して各フェーズで行うべきことがまとめられているのでわかりやすかったです。

運用設計の教科書 ～現場で困らないITサービスマネジメントの実践ノウハウ

created by Rinker

• Kindle
• Amazon
• 楽天市場

運用設計とは

運用とは

システムもしくは提供するサービスの利用開始から終了まで必要となる業務のこと。

• サービスを安定して提供する
• システムを正常に保つ
• サービスを効率的に提供できるよう運用を改善する

運用設計の目的

運用に必要な仕組みを決めるために行う。システムの重要度に合わせて最適化することも必要となる。

• 運用範囲の整理：システムを維持管理するために必要な作業
• サービスレベルの維持：システム異常時の最適な連絡経路を整備
• 標準化：オペレーターなら誰でも操作できる手順書や台帳の作成
• ドキュメントの可視化：作業に必要な運用ドキュメントを明確に整理

運用設計で決めるべきこと

運用業務の中で、「誰が」「どんな役割で」「どんな業務を」「どのシステムに対して」行うかを決定する。1つの作業の中で複数の関連部署が関わる場合は、「どんな情報を」「どのように」連携するかも決定する。

• システム運用に関わる人の範囲
• 導入するシステムの運用業務の範囲
• 周辺システムと連携する範囲

運用に関わる人には次のようなものがある。

運用で目指すレベル

運用はその習熟度に合わせていくつかのレベルに分類することができる。運用設計で目指すのはレベル 3 までがよい。 それ以上は運用開始後に最適化していく。

運用の分類

運用には大きく3つの分類がある。

• 業務運用：サービスを提供するアプリケーションと利用者に関する業務
• 基盤運用：サービスを安定して動作させるためのシステム基盤に関する業務
• 運用管理：運用全体を管理して全体ルールと方針を決定する業務

業務運用

業務運用の目的

サービスを安定して提供するために利用者とシステムのやりとりが円滑に行われるようにする。利用者が起点となる項目が多い。

業務運用の代表的な項目

• 利用者管理
• サポートデスク
• デバイスライフサイクル管理

基盤運用

基盤運用の目的

システムを正常に保ち、アプリケーションなどの提供が継続されるようにする。システムが起点となる項目が多い。

基盤運用の代表的な項目

• パッチ適用
• ジョブ / スクリプト運用
• バックアップ/ リストア運用
• 監視運用
• ログ管理
• 運用アカウント管理
• 保守契約管理

運用管理

運用管理の目的

業務運用と基盤運用が統一した基準で行われるようにする。プロジェクトやシステムごとに個別に設計するのではなく、全社統一ルールとして定めている場合が多い。

運用管理の代表的な項目

• 運用維持管理
• 運用情報統制
• 定期報告

運用設計で作成するドキュメント

運用設計ではプロジェクト全体を通して次のようなドキュメントを作成する。このうち一部は作成されない場合もあれば複数種作成することもある。

プロジェクトフェーズごとの運用設計

プロジェクトの各フェーズごとに運用設計の観点で行うべきことをまとめる。

システム化計画

発注者側にて提供するサービス内容を中心としたシステムか構想をシステム化計画書としてドキュメント化する。作成したシステム化計画書をもとに RFP の作成とベンダー選定を行う。

運用設計の観点ではこの段階で考慮すべきことはほとんどない。

要件定義

システムで実現する内容を要件として定義する。

要件定義のゴール

• 運用体制図を作成する
• 運用項目の範囲として運用項目一覧のドラフト版を作成する
• 運用体制図と運用項目一覧で合意された要件をもとに要件定義書としてまとめる

要件定義の際に把握しておくべき情報

• 発注者のプロジェクトに対する期待度
• システム化計画時に検討されたが採用されなかったアイディア
• プロジェクトとシステムの変動要素
  • プロジェクト変動要素
    • リリース日
    • スケジュール延長の許容
    • 要員追加の可否
  • システム変動要素
    • システムの利用者数
    • サービス提供時間
    • 運用中のシステム拡張
• 発注者側重要人物の把握

運用体制図

運用にどの組織が関わるかによって後続の設計内容に影響が出るので変更があればすぐに運用体制図を更新する。

運用体制図を決定するために次のような内容をヒアリングする。

• 利用者：人数、利用時間、利用場所、利用方法
• 情報システム室：対応時間、必要工数
• サポートデスク、監視オペレーター、DC オペレーター：対応時間、必要人数、1組織が複数兼務するか
• 運用担当者：対応時間、必要人数
• ソフトウェア保守、ハードウェア保守：契約内容、対応時間

運用項目一覧

運用項目一覧には次の内容を記載する。作業頻度や工数は要件が固まりきらないうちは概算の値を入れる。

要件定義書

ユースケース

業務要件に応じて運用を定義していく。システムとして実現する内容はシステムの要件定義に含む。一部のシステム化できなかった項目や、例外対応が必要な処理を運用で実現する。

機能要件

システムに実装できなかった部分を運用で実現する。次のような場合に運用で実現することが多い。

• 実施するトリガーが流動的
• 入力情報が流動的
• 判断が複雑
• 承認が必要
• コストがかかる
• 作業頻度が低い
• 優先度が低い
• 手作業の方が圧倒的に早い

非機能要件

可用性

システムを継続的に利用可能とするための要件をまとめる。

稼働率は死活監視だけでなく、応答時間も計測することで異常を早期に検知出来る。データのリストアはユーザーからの申告があった場合など、はっきりとしたトリガーがある場合以外は運用に含めない。

災害対策 (DR) サイトを考慮する場合は切り替えがうまく行える状態を維持することも必要となる。コールドスタンバイの場合は定期訓練、ホットスタンバイの場合は常時監視する仕組みを整備する。

• 継続性：システムを継続するためのスケジュール（対応時間、リリース日、メンテナンス時間など）
• 耐障害性：稼働率と稼働率維持のための対策
• 災害対策：DR サイトの運用方針、切り替え方法
• 回復性：バックアップ / リストア方法、タイミング、目標復旧地点(RPO)、目標復旧時間(RTO)

性能・拡張性

システムに必要な性能と将来のシステム拡張性に関する要件をまとめる。

性能が十分に発揮されるか、拡張のための需要予測のためにもリソースの使用率などを計測する。拡張の際はスケールアップかスケールアウトかの方針を決める。

• 業務処理量
• 性能目標値
• リソース拡張性：拡張時のリードタイム、拡張方針（スケールアップ、スケールアウト）
• 性能品質保証

運用・保守性

システムの運用と保守に関する要件をまとめる。運用設計書にまとめられる内容となる。

• 通常運用：運用時間と特殊日、メンテナンス時間、バックアップ取得方法（間隔、世代管理）、監視方法とレベル
• 保守運用：メンテナンス日、運用負荷削減方針、パッチ適用方針（対象、周期、緊急対応方法）
• 障害時運用：システム復旧方針、障害発生時の代替技術有無、障害対応可能時間、障害レベルの設定
• 運用環境：開発・検証環境の用途と役割分担、手順書などのマニュアル記載粒度、リモートオペレーションの有無
• サポート体制：保守契約状況、システムライフサイクル、運用要員の教育方針、定期報告会の頻度とレベル
• その他の運用管理方針：サービスデスクやインシデント管理、問題管理、変更管理、構成管理

移行性

現行システムから新システムへ移行する際の要件をまとめる。システム利用開始前に必要となるため、移行に関して運用項目一覧に記載される項目はほとんどない。

• 移行時期
• 移行方式
• 移行対象機器
• 移行対象データ
• 移行計画

セキュリティ

システムの安全性確保に関する要件をまとめる。発生頻度は低いが、セキュリティインシデント発生時の対応はしっかり定めておく。

• 定期的なセキュリティ診断：外部の監査員によるシステムのセキュリティ診断
• 運用アカウントの管理：運用アカウントのパスワード変更、特権アカウントの貸し出し運用
• 不正追跡・監視のためのログ管理：定期的なアクセスログ監視
• セキュリティインシデント対応：マルウェア県知事の対応、感染時のフォレンジック対応

システム環境・エコロジー

システムの設置環境やエコロジー対応に関する要件をまとめる。拡張時の物理的制限があれば記載する。データセンターへの入管方法や持ち込み可能機器といった作法も記載する。

• システム制約・前提条件
• システム特性の洗い出し
• 適合規格
• 機材設置環境条件

運用要件の詳細

• 運用基本要件：運用体制図、対応時間、運用スケジュールなど全体に関わる要件
• 業務運用要件：利用者登録や権限管理など、サービスを利用するために必要な運用の要件を記載
• 基盤運用要件：パッチ適用、監視運用、バックアップ、ログ管理、運用アカウント管理などの基盤運用に関わる要件を記載
• 運用管理要件：上の維持管理方針、情報統制方法、定期報告についての要件を記載

要件定義で作成する成果物

• 運用項目一覧：60 %
• 要件定義書：100 %

基本設計

基本設計のゴール

• 運用設計書に運用のルール、やること、やらないことを記載して合意する
• 運用フロー図に運用業務に関係する人物の役割分担を整理する
• 運用項目一覧を修正して、詳細手順書で作成するドキュメントを合意する

運用設計で合意すべきこと

1. 今回の運用に求められること
2. 適用するにあたって知っておかなければならないシステムに対する知識
3. 今回の運用に出てくる登場人物とその役割
4. 運用項目ごとの目的とゴール
5. 各運用項目で利用するドキュメント
6. 採用されなかった運用方針とその理由

運用設計書

運用設計書には次のような内容を含める。

はじめに

運用設計書の目的、対象読者、構成内容の3つを記載する。目的にはシステム導入の目的を簡単に記載し、「そのシステムを安定稼働させて効率的にサービスを提供する」と記載する。対象読者は「システム運用に関わる全ての人」になる。構成内容は概要を表形式でまとめる。

利用者のユースケース

要件定義で定めたユースケースを読者に対して説明する。基本設計書に記載がある場合は転載でも構わない。ユースケースに変更の可能性がある場合は基本設計書の章番号を記載して参照させる。

機器構成・機能

システム構成、ネットワーク構成と実装されている機能を読者に対して説明する。基本設計書の章番号を記載する方がわかりやすい。

運用概要

要件定義で確定した登場人物やスケジュールに加えて、運用に必要な共通認識を記載する。

• 登場人物と役割説明、対応時間
• 通常時の運用スケジュールとシステムメンテナンス時間とその考え方
• 関係者間の連絡ルール、利用する運用管理ツールなど使い方

業務運用、基盤運用、運用管理

実際の運用項目の業務内容について記載する。

• 運用項目の目的
• 運用項目の概要
• 運用項目の運用方針、ルール、注意事項など
• 運用項目における関係者と役割、情報連携ルール
• 運用項目に必要なドキュメント

特記事項

運用上把握しておくべき情報で上記構成に記載しなかったことを記載する。検討されたが採用されなかった項目、運用方針などの理由。将来的に技術が進歩すれば実装できる可能性もある。

運用フロー図

運用項目に対して、いつ・誰が・どんな情報をもとに・何をするかを記載する。3つ以上関連する組織がある項目については作成することを推奨する。

• 処理の流れ
• 運用担当者の作業範囲
• 実施タイミング

基本設計の成果物

• 運用設計書：80 %
• 運用フロー図：80 %
• 運用項目一覧：80 %

詳細設計

詳細設計のゴール

運用手順書をはじめ、運用作業で必要となる各種ドキュメントを作成する。作成するドキュメントが多いため、WBS でこまめに管理した方が良い。

• 運用手順書を作成する
• 台帳と一覧を作成する
• 申請書を作成する
• 運用項目一覧とフロー図を修正する
• 報告書のフォーマットを作成する

運用手順書

運用手順書には次の内容を記載する。手順書の粒度はオペレーターのスキルに合わせる。既存フォーマットがあればそれに合わせる。

• 運用手順書の目的：手順書を実施する目的
• 作業実施トリガー：手順書が実施されるきっかけ
• 関連ドキュメント：手順書から参照するドキュメント名
• 前提条件：手順を実施するにあたって確認しておくべき前提条件
• 実施手順：実際の操作手順
• 事後作業：作業実施後にするべき作業

台帳 / 一覧

台帳には運用上で更新されるデータをまとめる。一覧にはドキュメント内にある静的データをまとめておく。次のようなものを作成する。

• ネットワーク系
  • IP アドレス一覧
  • ポート管理表
  • ケーブル結線管理表
• サーバー／ストレージ系
  • 機器構成一覧 – サーバー構成一覧
  • ソフトウェアライセンス一覧
• 運用系
  • 監視対象一覧
  • バックアップ／リストア一覧
  • ログ一覧
  • ジョブ一覧
  • 運用ドキュメント一覧
  • 運用アカウント管理台帳
  • 運用連絡先一覧
  • 保守契約情報一覧
  • 端末管理台帳

申請書

運用フロー図で情報連携が必要な箇所において、円滑に情報を共有するためのフォーマットを作成する。

• 申請内容
• 承認者と商人判断方法
• 申請から完了までのリードタイム

詳細設計の成果物

• 運用フロー図：90 %
• 運用項目一覧：90 %
• 運用手順書：90 %
• 台帳 / 一覧：90 %
• 申告書：90 %

運用テスト

運用テストのゴール

完成したドキュメントをもとに滞りなく運用業務ができることを確かめる。

• 運用テスト計画書を作成して方針を合意する
• 運用テスト仕様書を作成して実施内容を合意する
• 運用テストの課題と結果の取りまとめを行う
• ドキュメントの最終修正

テストの種類

• 単体テスト：設計した項目が正しく設定されているかを確認。機器やサービスの起動停止。
• 結合テスト：モジュール間のデータ連携などを検証する。異常系のテストも実施する。
• 総合テスト：提供するサービスに問題ないことを確認する。本番利用想定でテストする。
• 運用テスト：フロー図と手順書をもとに実際に運用できるかを検証する。

運用テスト計画書の内容

運用テスト計画書には次のような内容を記載する。

• テストの目的：運用テストに求める目的（ドキュメントをもとに業務ができること）を記載する
• テスト実施前提：テストを実施するための前提条件（ドキュメントや事前のテストなど）
• テスト範囲、種別：運用フローテストか運用手順書テスト
• テスト実装方法：実機テストと机上テスト
• テストスケジュール：概算のスケジュール
• テスト実施体制：テストを行う関係者の体制図
• 合否の判定基準：合格、修正あり、問題ありの3種類
• 運用課題の優先度：プロジェクト期間内、引き継ぎ完了まで、運用開始後の3段階
• 成果物：結果報告書、課題管理表、エビデンス

運用フローテスト仕様書

運用フローの全パターンからテストするものを抽出する。すべてのパターンを試すのは工数がかかるので、網羅性があるように設計する。

• 番号
• テスト項目名
• 実施内容
• 実行者
• 確認者
• 実施結果
• 実施日時
• 課題管理番号
• 備考

運用手順書テスト仕様書

手順書をもとに想定の結果が得られることを確認する。

• 番号
• 手順書名
• 実施内容
• 実行者
• 確認者
• 実施結果
• 実施日時
• 課題管理番号
• 備考

運用テストの成果物

• 運用設計書：100 %
• 運用フロー図：100 %
• 運用項目一覧：100 %
• 運用手順書：100 %
• 台帳 / 一覧：100 %
• 申告書：100 %

運用引き継ぎ

成果物などを運用担当者に引き継ぎ、運用業務を行えるようにする。必要に応じて勉強会や立ち会いをスケジュールする。

• システムリリース前に説明会、勉強会を開催する
• ドキュメントやルールの息継ぎを実施する
• 運用担当者の習熟度を上げる

習熟度アップ

• 継続的なドキュメント修正や改善活動
• 監視パラメーターのチューニング
• 問い合わせ対応、障害発生時のサポート、初回運用立ち会い