はじめに

みんなが知っておくべき運用設計のノウハウ Kindle版
https://www.amazon.co.jp/dp/B0771HZRZ8

上記の書籍を読んだ際のメモです。ほぼほぼ章・節・項をそのまま踏襲した形になってしまいました。

1.運用と運用設計

運用とは

運用とは
- ものごとをうまく働かせること
ITシステム運用
- サービスを安定して提供するためにシステムを安定稼働させる
システムを運用する担当者
- 運用担当者
  - 問合せに基づくサービスデスク業務
  - 手順書を基に定期で行う定型作業
  - 依頼を基に行う非定型作業
    - アカウント作成
    - パッチ適用
    - ログ取得
  - システムの稼働状況やインシデント発生件数などの顧客への定期報告
- 監視オペレーター
  - 検知したら運用担当者へエスカレーション
  - 不具合発生時の一次切り分け
- 保守担当者
  - データセンターでの作業
    - 障害発生時の部品・機器交換
    - 定期メンテナンスや遠隔チェック
  - 機器販売ベンダーが担うことが多い

運用設計とは

運用設計はなぜ必要なのか
- システムが複雑化している状況において、運用に必要な情報だけをまとめておく必要がある
- 運用設計書というアウトプットに起こすことで、新たな運用担当者が増えた際にも理解できるようにしておく
運用設計をする意味
- 人はミスをするし物は壊れる
- 障害時の対応をあらかじめ想定して定めておくことで迅速な対応を可能とする
構築設計と運用設計の差異
- 構築設計
  - 物、機能、購買、仕様書スペック、パラメーター
- 運用設計
  - 人、非機能、保守、業務、イベント

運用設計担当者とのしてのプロジェクト参加

運用設計の担当者は、プロジェクトにおいて要件定義のフェーズから関わることが多い。一般的なプロジェクト進行、および各フェーズでの代表的な成果物、プロジェクトの登場人物は以下となる。

プロジェクト進行

プロジェクト進行
- システム基本計画
  - システム導入を検討する（本書の対象外）
- 提案対応
  - システムを導入する業者を決定する（本書の対象外）
- 要件定義
  - システムの要件を取りまとめる（2章）
- 基本設計
  - システムの基本的な動きをまとめる（3章）
- 詳細設計
  - パラメーターなどのシステムの詳細を決める（4章）
- テスト
  - システムを構築した結果をテストする（5章）
- 移行
  - システムを開始するための作業を行う（6章）

主なプロジェクト成果物

プロジェクト成果物
- 要件定義書
  - システムに何が必要かをまとめたもの
- 基本設計書
  - 要件をどのように実現するかをまとめるもの
- 運用設計書
  - システムをどのように運用するかを定めたもの
- 詳細設計書
  - 基本設計で定めたことの方針を実現する方式や設定値を定めたもの
- テスト仕様書
  - システムの正常性、性能を確認する項目をまとめたもの
- 移行計画書
  - システムのリリースに向けた各種計画をまとめたもの

プロジェクトの登場人物

プロジェクトの登場人物
- エンドユーザー
  - 利用者
  - システムのサービスを利用する人
  - 関わるとしてもテストフェーズの一環程度
- プロジェクトオーナー
  - 顧客
  - プロジェクトの発注者
- プロジェクトマネージャー
  - PM
  - プロジェクトの管理者
- インフラ構築担当
  - インフラチーム、基盤担当
  - ハードウェア、ネットワーク、OS、ミドル
- アプリケーション開発担当
  - アプリチーム、業務担当
  - ミドル、アプリ
- 運用設計担当
  - 運用設計チーム

2.要件定義フェーズ

要件定義とは

要件定義と要件定義書
- 要件定義
  - システム基本計画でシステムの概要がまとまったら、次にシステムの要件をまとめる
  - 本来は顧客が行うものであるが、ITに詳しくない場合SIerと協力して進める
- 要件定義書
  - 顧客に対するヒアリングの結果
  - 実装しなければならない機能
  - 達成しなければならない性能
実現方式の検討
- 社内事例検索
- ネット情報検索
- メーカー問合せ
- 実機検証
要件定義フェーズでの注意点
- システムの全体像が見えてくるにつれて要件は変動する
  - できる限り可能性を検討して後続フェーズでのブレを抑える
- 顧客とのギャップ
  - エンジニアは技術論を語りがちだが、必要なのはシステムの全体像と実現性
- 顧客が正解を持っているわけではない
  - 提示しなければ気づかない点もある
- 安易な現行踏襲はしない
  - メリットとデメリットがある

機能要件と非機能要件

機能要件
- 実装に直結し、イメージしやすい
非機能要件
- イメージしづらく、具体化しないと実装に至らない
洗濯機を例にした要件
- 機能要件
  - 洗い、すすぎ、脱水、タイマー機能、乾燥
- 非機能要件
  - 10年以上は使いたい、騒音を抑えたい、海外でも使いたい
  - 故障時に対応してほしい、20分以内に完了してほしい
IPAの非機能要求グレード
https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html
- 可用性
- 性能/拡張性
- 運用/保守性
- 移行性
- セキュリティ
- システム環境/エコロジー

運用設計は非機能要件に含まれる

運用設計項目は基本的に非機能要件に含まれる。要件定義フェーズから検討を始める。主な運用設計項目は以下の通り。

運用設計項目
- 運用体制
  - 次フェーズ以降の役割分担、責任分界点の決定に向けて把握しておく
- ユーザーアカウント管理方法
  - ユーザー追加
  - 一時貸し出しなどの特殊使用
  - 昇格による権限変更
  - 部署異動によるアカウント改廃
- セキュリティ対策
  - セキュリティポリシー
    - 脆弱性対策
    - ウィルス対策
    - パスワードルール
    - セキュリティパッチ適用方針
- ジョブ/スクリプト運用
  - OS、ミドルの機能を利用したもの
  - 専用の自動化ツール
- バックアップ/リストア運用
  - バックアップの概要
    - RPO（目標復旧時点）
  - リストアのトリガー
    - 障害発生時のみか、申請によるデータリストアなども必要か、など
- 監視運用
  - 「誰が」「どこで」「どのように」「どのぐらい」監視するかを決める
  - 「何を」「どのぐらいの周期で」「どのレベルまで」は次工程で決める
- ログ管理運用
  - 障害検知用
    - 比較的短期
  - 監査用
    - 長期保管が必要
- 稼働統計運用
  - 定期報告
- 移行
  - 運用引継ぎ
  - データ移行
  - ドキュメント納品
  - システム切り替え

BCP/DR

BCP/DRについてもっとも真剣に検討するのは要件定義フェーズ。

バックアップ
コールドサイト
ウォームサイト
ホットサイト

保守契約も要件定義フェーズで確認しておく。

3.基本設計フェーズ

基本設計とは

要件定義にて決定したシステム要件に従い、具体的な仕組みを決定する工程

役割分担
OS、ミドルウェア、アプリケーションについて理解を深める
後続ドキュメントを意識する
インフラ、アプリチームとの連携
運用項目一覧を合意する

運用設計書記載項目

共通項目
- はじめに
- 運用設計方針
- 運用体制
- 業務運用
  - システム運用とは別の
- 保守運用
- システムのライフサイクル
- 運用項目一覧
ITLプロセスの運用設計項目
- インシデント管理
- 問題管理
- 変更管理/リリース管理
- 構成管理（サービス資産管理）
- 情報セキュリティ管理
- サービスレベル管理（SLA）
- 可用性管理
- 拡張計画
- サービス選定/サービスレポート
システム基盤項目
- 監視
- ジョブ管理
- バックアップ・リストア運用
- ログ管理
  - 障害調査
  - 監査

4.詳細設計フェーズ

詳細設計とは

運用フロー

イメージは以下のPDFの図。

7.6 障害対応の作業フロー - 厚生労働省
https://www.mhlw.go.jp/sinsei/chotatu/chotatu/shiyousho-an/dl/090422-1a_0009.pdf

運用手順書
台帳/一覧
- NW系
  - IPアドレス一覧
  - ポート管理表
  - ケーブル結線管理表
- サーバー/ストレージ系
  - 機器管理表
  - サーバー構成管理表
  - ソフトウェアライセンス一覧
- 運用系
  - 監視対象一覧
  - バックアップ/リストア一覧
  - ログ一覧
  - ジョブ一覧（自動化対象一覧）
  - 運用項目一覧
  - 運用ドキュメント一覧
  - アカウント一覧
  - 連絡先一覧
  - 保守管理一覧
  - パスワード管理台帳
  - 端末管理台帳

監視設計

監視とは
監視設計とは
サービスの監視
- URL応答監視
- Webシナリオ監視
インフラ監視
- ハードウェア監視
- リソース監視
- プロセス監視
- ログ監視
  - アラートランク
監視設計の勘所
- 監視の運用体制
- 監視ツールの選定
- 監視サーバの配置場所
- 製品のリモート監視サービス
- 監視業務のアウトソーシング
- 監視システムのテスト

バックアップ設計

バックアップ設計
- RTO
- RPO
バックアップ種別
- システムバックアップ
- データバックアップ
バックアップの方法
- バックアップ製品を使用したバックアップ
- OS標準バックアップ
- スクリプトを使用したバックアップ
データリカバリ
バックアップ計画
- 目的
  - 障害/災害対策、構成変更時
- バックアップ対象
  - 物理/論理、構成ファイル、DB、ログ
- 取得世代数
  - 保持期間、取得回数
- データ量
  - バックアップする総サイズ
- 取得時間
  - 取得可能な時間帯
- バックアップ方法
  - フル、差分、増分
- 取得媒体
  - テープ、専用ストレージ、仮想テープ装置
- 費用
  - 初期費用、月額、追加料金
バックアップ技術
- 重複排除
- スナップショット
- レプリケーション

ログ設計

用途
- 障害調査
- 監査対応
ログ管理サーバー
- ログの一元管理
- ログの分析・レポート
- ログの圧縮
- ログのモニタリング
- ログの原本管理、改ざん防止機能

自動化設計

自動化の検討

自動化のメリット
- 工数削減
- 作業品質の向上
- スピードアップ
- 属人化排除
自動化対象の選定
- 作業頻度
- 作業時の判断数
- 作業のコンポーネント数
- 作業の確実性
自動化の方法
- スクリプト
- Cron/タスクマネージャ
- ツール/ソフトウェア
- ミドルウェアの機能
- ジョブ管理ソフト
- RBA機能
自動化の例
- 性能レポートの作成
- 監視一次対応

5.テストフェーズ

テストとは

テストの目的
テスト仕様書
- テスト項目番号
- テスト項目名
- 実施内容詳細（手順）
- 合否判断基準
- 実施結果
- 実施年月日
- 実行者
- 課題管理番号
テスト結果エビデンス
問題の管理方法

テストの種類と内容

単体テスト
結合テスト
総合テスト
運用テスト
- 運用フローの検証
  - 実施トリガー
  - 担当者間をまたがるデータのやり取り
  - 分岐、繰り返しの判断基準の正当性
- 運票手順の検証
- 運用テストでの注意事項

6.運用引継ぎ

ドキュメント引継ぎ
- 顧客作成ドキュメント
- インフラ構築チーム作成ドキュメント
- アプリチーム作成ドキュメント
  - 運用設計書
  - 運用フロー
  - 運用手順書
  - 台帳/一覧
スキルトランスファー
- システム説明会
- 新規導入製品説明会
- 運用テスト
運用引継ぎ管理

7.移行フェーズ

新規システムの場合
既存システム更改の場合
移行の方法
- 一括移行
- 段階移行
- 並行運用
移行計画書
- 移行概要
- 移行対象
- 移行中の影響
- 移行テスト
- 移行スケジュール
- 移行体制
注意点
- 監視システム
  - 一括移行
  - 段階移行
  - 並行運用
- 移行本部を作る
- 基準を決める

おわりに

オンプレ前提であるように感じましたが、クラウド環境を想定した際にも使える普遍的な内容でした。

運用設計における項目が網羅されており、設計・検討する際のベースにできる内容だと感じました。

他企業、他案件の運用まわりの設計書を目にする機会はなかなかないですが、以下のリンクにまとまっている資料は比較的近しい内容のように思えました。参考までに。

[調達仕様書案｜厚生労働省]
https://www.mhlw.go.jp/sinsei/chotatu/chotatu/shiyousho-an.html