[読書] 運用設計の教科書

運用 設計

読んだ本


運用設計の教科書 ~現場で困らないITサービスマネジメントの実践ノウハウ日本ビジネスシステムズ株式会社　近藤誠司

モチベーション

システム運用の文脈で、会社からのおすすめです。
担当プロダクトが運用支援系ということもあり、DevOpsにもつながりますし、前職では独学で運用支援などをやってきたようなところもあるので、きちんと体系立てた教科書を読むのも良いということでこちらを

かかった時間など

2022/12/11 〜 2023/2/16
合計7時間くらい
300Pくらいの本でしたが、すこし時間かかっているような気もしますが、こんなものでしょうか

理解メモ(復習)

第1章. 運用設計とは

運用設計は、 運用に必要な作業を取りまとめて、ルールを決めること
サービスの重要度に合わせて運用を最適化することが運用設計の目標
運用中のよくあるトラブル
1. 何をやればこのシステムが維持できるのか不明
2. 障害や故障が起きた場合に誰に連絡すればよいかわからない。そのことで影響が大きくなる
3. スキルの高い特定の運用担当者に負荷が集中する
4. 手順書の品質がわるく、作業担当者によって作業の結果にばらつきがある
5. ドキュメントが管理されておらず、運用改善の糸口がつかめない
COBIT成熟度モデルをもとに目指すレベルを決める
運用設計の分類
- 業務運用：システムを活用してサービスを提供するアプリケーションと利用者に関する業務
- 基盤運用：システムを維持して、アプリケーションが問題なく動作するためのシステム基盤に関する業務
- 運用管理：運用全体を管理して、円滑に行えるように全体のルールとものさしを決めて管理する業務

第2章. フェーズから考える運用設計

ここでは、ウォータフォール／V字型開発モデルで各フェーズを考える

システム化計画
- 運用に関連するドキュメントは「システム化計画書」「RFP」
要件定義
- ここで運用設計担当としては、サービス開始後に運用が必要となる範囲を明確にする
- 人的リソースの範囲を定めて、運用体制図を作る
- 運用項目の範囲を決めるために、ドラフト版の運用項目一覧を作って発注者と合意をとる
- 上記２つの作成の中で合意された要件を要件定義書としてまとめる
- 変動要素を把握しておく
  - プロジェクト変動要素
    - リリース日はどの時点で確定するか
    - スケジュールの延長に対する許容度
    - 途中で要員の追加は可能か
  - システム変動要素
    - システムの想定利用者数
    - サービスの提供時間
    - 運用中にシステム拡張があるか
- 運用管理項目はITILが参考になる。他に以下をまとめておく
  - 運用情報統制：運用上で発生した情報の選別方法、対応の仕組みをまとめる
  - 運用維持管理：運用上のルールや基準についてまとめる
  - 定期報告
基本設計
- 基本設計で運用担当者がやること
  - 運用設計書をつくる：運用のルール、やること／やらないことを記載
  - 運用フロー図を作成：複数の関係者の役割分担
  - 運用項目一覧を修正
詳細設計
- 詳細設計で運用担当者がやること
  - 運用手順書を作成する
  - 運用中に発生する可変データを管理する台帳を作成
  - パラメータシートを作成
  - 利用者依頼につかうシステム変更の申請書を作成
  - 運用状況報告書のテンプレートを作成
  - 運用テスト仕様書を作成
- 実機を触って確かめながら
- パスワードなど可変データは別のドキュメント(台帳)に
- 共通する項目は別章か付録に
運用テスト
- 運用テストでやること
  - 運用テスト計画書を作成する
  - 運用テスト仕様書を作成
  - 運用テストを実際の運用担当者に実施してもらう
  - 運用テストの結果、課題を取りまとめ
- 運用フローテストでは、全分岐パターンを洗い出すが、すべてのパターンの実施は厳しいことが多いため、重要なものを抽出する
- 運用テストの実施にあたって、トラブルが多いので、連絡手段をきめたり、物理的に近くにいるとよい
運用引き継ぎ
- リリース前にシステム説明会、導入製品勉強会などを実施
- 運用テストで運用関連のドキュメント、ルールの引き継ぎを行う
- 運用支援をする。支援実績を発注者に報告する

第3章. 業務運用のケーススタディ

業務運用の設計の進め方
1. ユースケースや機能要件からBPMNフロー図を作成する
2. アプリケーション担当とレビューを実施
3. 発注者とディスカッションして運用方針を決定する
4. 決定事項を発注者と最終合意する
ポイント
- 利用者のファシリティ（施設、設備、国）によってさらなる運用作業が発生しないか
- 利用者の権限（管理者、プレミアムプランなど）によって利用方法の違いがないか
システム利用者管理運用
サポートデスク運用
PCライフサイクル管理運用

第4章. 基盤運用のケーススタディ

システム基盤として、例えば以下のような制約事項や注意事項があることを把握することがポイント
- システムの全停止、全起動の手順、順序
- バックアップリストアを複数同時にやってはいけない。やるとRTO：目標復旧時間を超える場合がある
- バックアップリストアをやる際にシステムへの負荷がかかるので、事前の連絡が必要
- 上がっているエラーのプライオリティは現在は警告だが、定期的に確認が必要なものがある

パッチ運用
- 定期パッチ適用、緊急パッチ適用
- アプリケーションに不具合が出ないことを事前に確認
- 稼働中のものに適用するときに夜間や長期停止期間など限られた期間になる
- パッチ適用周期の考え方
  - ファームウェア：不定期。停止中の影響を考える
  - OS、ミドルウェア：メーカーがパッチを発行しているのでそれに合わせて毎月・3ヶ月に1度・半年に一度など決める。緊急パッチが出ることもあるが、まずは情報を調べる手順にしておいたほうがよい
  - アプリケーション：パッケージ開発＋作り込みがある場合は影響を考慮する必要がある。難しい
- 発注者との調整
  - パッチ公開周期とセキュリティ重要度からパッチ適用周期を決める
  - パッチ情報を誰が取得するかを決める
  - 緊急パッチ適用判断をだれが実施するかを決める
  - 緊急の場合、一時的にサービスを停止するかどうかを決める
  - パッチ適用時のメンテナンス時間の利用者周知方法を決める
- 悪魔の証明：正常性確認で、100%正常であることを証明する手段はない

ジョブ／スクリプト運用
- 実装したジョブやスクリプトがエラーで止まってしまったときなどが運用の対象になる
- 人がやる範囲と機械がやる範囲を明確にする
- スクリプトはいいことづくめのように思えるが、作成に時間がかかり、スクリプト自体が動かなくなるリスクも想定する必要がでるので、しっかりした手順書を残し、運用担当者が保守改善をするようにしたほうがよい。誰の責任も負わず保守されないスクリプトは危険
バックアップ／リストア運用
- バックアップとリストアをかならずペアで考える！
- DR(Disaster Recoverry：災害復旧)プラン
  - 別拠点へのバックアップ
  - ネットワーク帯域利用料、レプリケーションにかかる時間なども考慮が必要
- バックアップの計画は基盤構築コストに関わるため、プロジェクトの初期に調整すべき
監視運用
- インフラ監視：死活監視、ハードウェア監視、リソース監視、プロセス監視、ログ監視
- サービス監視：URL応答監視、画面遷移監視
ログ管理
- ログ管理の目的は、障害調査と監視対応
- 障害調査用のログの保管についての設計
  - ログローテーション
  - ログの保管場所
  - 保管期間
  - アーカイブ対応
  - セキュリティ
- 障害発生時のログ取得方法の手順化はやっておくべき
運用アカウント管理
- 特権IDが必要となるケース
  - ミドルウェア、DBの特権ID
  - OSの特権ID
  - ハードウェアの特権ID
- LDAP(ADなど)の特権IDを活用
  - 権限付与方式：実際の担当者のアカウントに権限を付与する
    - 台帳に誰になんの権限があるか表にしておくこと
  - 払い出し方式：権限が付与されたアカウントを作り置きして必要に応じて使わせる
    - 担当者の入れ替わりが激しい場合はこちらのほうがよい
    - 管理台帳に、使用する管理アカウント（adminなど）の列も追加して管理
- セキュリティポリシーをきめて、パスワード変更手順をまとめておく
- 実運用の直前で各システム、機器のパスワードを変えると問題がおきることがあるので、早めのテスト工程で適用したほうがよい
保守契約管理
- 機器、OS、ミドルウェア、アプリケーションのサポート期限の管理運用が必要
- 物理機器が故障したときの対応をまとめる
  - メーカーがどこまで対応してくれるのかを確認
  - 物理機器のあるデータセンターへの持ち込み申請、手順も把握しておく

第5章. 運用管理のケーススタディ

運用管理の設計の進め方
- 既存のルール、基準、フォーマット、フローを確認する
- 今回のシステムで適用できない箇所がないか確認する
- 決定した運用管理方法をドキュメントへ反映して発注者と最終合意する
各システムの維持管理基準やインシデントの扱いの基準を統一（＝ITガバナンスの強化）していく
運用維持管理
- 要件適宜でのSLAやガイドラインにあわせて運用項目をまとめる
- サービスレベル管理
- キャパシティ管理
- 可用性管理
- 情報セキュリティ管理
- ITサービス継続性管理
- 運用要員教育
運用情報統制
- インシデント管理
- 問題管理
- 変更／リリース管理
- 構成管理
- ナレッジ管理
  - 収集：とにかくたくさん集められるように、集めるハードルを下げる
  - 選別：運用に使うドキュメントにまとめて、公式なものとそうでないもので分ける
  - 活用：ナレッジの一覧、逆引き、タグ付けなど参照しやすいようにする
- 定期報告
  - 報告内容の取捨選択：なにも判断を産まない情報はしないほうが運用コストが下げられる

感想

具体的に日本での(?)開発・保守案件の契約がシミュレートされていて、用意すべきドキュメントの構成なども含めて進め方のイメージがつくわかりやすい本でした。
ITILでもサービスマネジメント周りがプラクティスとしてまとめられていて、こちらの本もITILがベースになっている印象ですが、より実際の現場ではどのように適用していくかが記載されているように思いました。
技術的なことはすこしわかっていても情シス部門のやっていることは把握できていないことが多かったので、Dev + Ops で進められるように運用で検討が必要なことを一通り知ることができてよかったです。

最終更新日: May 2, 2024