概要

はじめに

今春のITサービスマネージャ試験の受験に向けて、まずはシステム運用についてある程度体系的な知識を身につけたいなと思い、積読となっていた「運用設計の教科書」を読みました。
結論としては、非常にわかりやすく学びの多いテキストでした。

主に自分自身のアウトプットのため、第1章と第2章を中心に、以下に内容をまとめます。
3～5章は具体的なケーススタディのため、特に印象に残ったフレーズのみ抜粋します。（印象に残るところが多くてこのボリュームに…）
実際は具体例を元にした丁寧な解説で、何というか、1章ずつが「濃い」 です。
ちょっとでも刺さるフレーズのあった方はぜひ本書を読んでみて下さい！

書誌情報

運用設計の教科書現場で困らないＩＴサービスマネジメントの実践ノウハウ
https://gihyo.jp/book/2019/978-4-297-10793-2

ISBN：9784297107932
著者：近藤誠司
出版社：技術評論社

2023年8月に改定新版が刊行済みです。これから買われる方はぜひ改定新版を購入ください。（自分は初版が積読だっただけ…）

読んだ理由

システム運用についてある程度体系的な知識を身につけたかった
ITサービスマネージャ試験（SM試験）の参考文献として

学習範囲

全章

先に感想

そもそも「運用設計」について明確に意識したことがなかったレベルだったため、システム運用についてサービスインの前に考えておくべき（「設計」しなければいけない）項目の全体像がわかり、とても良かったです。これだけで当初の目的は果たせました。
タイトルに「運用」と入っていますが、本書の主役である「運用設計担当」の主たる役割は、運用の実務担当者へ、スムーズに引き継ぎを行うこと（多分）なので、開発側のポジションで働いていて、運用側への引き継ぎを日頃している人達にもぜひオススメしたい本です。
思い返すと、自分の数少ないプロジェクト経験の中で「運用設計担当」的なポジションの専任者がいた場合は確かにサービスインがスムーズだった気がしますが、それはレアケースで、実際にはいない場合の方が多かったです。（いる場合は「今回は何かえらく体制がリッチだなぁ」とかのんきに思ってました）
現実的にも、開発側か運用側のメンバーが兼任でやるケースが多そうなので、本書に記載の流れを完璧にやりきるのは恐らくリソース的に厳しい場合が多いかなと。。なので、ポイントを絞って、うまく分担してできると良いのかなと思いました。
繰り返し出てくる言葉として、運用のリソースは有限なので、サービス開始後に運用担当者に不要な負荷がかからないようにする。そのためには、運用設計フェーズで ドキュメントを整理する（無用なドキュメントは極力減らす）、発注者側ときちんと合意をとる（先送りしない） ことが大事。という点が印象に残りました。
言うは何とやらで実際はなかなかハードル高いですが、まずは心構えとして胸に刻みます。。

まとめ

1章運用設計とは

運用、運用設計の目的

運用、運用設計とは？
- 運用：　システムがリリースされてサービス開始されたところから始まり、サービスが終了するまで続く
- 運用設計：　運用に必要な作業を取りまとめてルールを決めること
それぞれの目的
- 運用：　システムを安定稼働させて効率的にサービス提供することが目的
- 運用設計：　サービスの重要度に合わせて運用を最適化することが目的　←必然的に運用コストも最適化される

運用設計の目指すレベル

COBIT成熟度モデルのレベル3を目指す
レベル3以上は実際の運用担当が改善していく要素が多い
より良い運用へ改善していく準備を整えるのが、運用設計が目指すレベル

レベル	最適化範囲	例
3	定められたプロセス	・運用管理がある程度体系化されているが強制力はない・必要なドキュメントは体系化／標準化されており、研修を通じて共有がなされている・作業に必須なものはそろっているが、想定外のトラブルに対処できない

運用設計の3分類

「運用」には「業務運用」「基盤運用」「運用管理」の大きく3つの業務がある。運用設計では、3つの分類のどの部分の話をしているのか意識しておくことが必要
開発現場では、「運用」と言っている時に、お互いが想像している「運用」が異なっていて話がすれ違うことが良くあるので要注意

① 業務運用

業務の8割を自動化できたとして、残り2割の人間がやらないといけない業務部分を、本書では業務運用と呼ぶ

② 基盤運用

システムを維持するための基盤メンテナンス部分

③ 運用管理

運用に関わる人が守るべきルールと基準を決めること

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

運用設計担当の役割と運用ドキュメント

追加する新システムの特徴と現行運用を理解して、その橋渡しをするのが運用設計担当の役割
構築したシステムが最大の効果を発揮するように、ステークホルダー（利害関係者）と調整していく
ディスカッションを行いながら、導入するシステムの運用方針や手順を確定し、合意内容を成果物としてドキュメント化していく。主な「運用ドキュメント」は、以下の7種類。

ドキュメント分類	主な作成フェーズ
運用設計書	基本設計
運用項目一覧	要件定義
運用フロー図	基本設計
運用手順書	詳細設計
申請書	詳細設計
台帳	詳細設計
一覧	詳細設計

システム化計画

この段階では、まだだれが実際にシステム構築をするか決まっていないので、運用設計担当が参加することはほとんどない
ただし、実際にプロジェクトに参加した時に、このフェーズでどのような合意がなされているのか、予め資料を読み込んで知っておくことは重要　←発注者側の期待度、発注者側の重要人物把握、採用されなかったアイディアetcドキュメントに書かれていない行間もなるべく把握する

要件定義

目的： 運用項目一覧 という運用設計全体のガイドラインを作成し、基本設計以降で何をすればよいかわかるようにする
大まかな流れ
1. 運用体制図の作成と合意
2. 運用項目一覧のドラフト版の作成と合意
3. 1と2で合意された要件を、要件定義書としてまとめる
運用項目一覧はドラフト作成後に発注側とのディスカッションを通して、①ユースケース②機能要件③非機能要件、の観点で運用項目を洗い出し、アップデートしていく
- ユースケースで運用項目となりやすいのは例外ケース。「原則～だけれど、～したい」といった記述が出てきた時は運用項目が発生する可能性が高く、要件を掘り下げる必要あり。
- 機能要件で運用項目となりうるものは、ユースケースの中でどうしても機能実装できない部分。費用対効果からシステム化されず、手作業とすることを「運用回避」と呼ぶ
  - ゆくゆくはシステム化、運用自動化が検討される項目なので、運用回避された経緯は運用設計書に記載しておくこと。
- サービス継続のために必要な機能以外の要件は全て非機能要件。基盤運用担当と運用設計担当が主担当となり、要件とりまとめを行う。
運用項目一覧について発注側と大枠の合意ができると、運用工数の算出ができるようになる　←管理工数も忘れずに

この段階では運用項目一覧の完成度が6割程度なので、必然的に工数算出の精度も6割程度。工数算出依頼を受けた場合は、発注者側とこの点について予め合意を得てから算出作業を行うこと。

基本設計

要件定義で決まった範囲に対して、詳細な運用ルール、細かい役割分担を検討していく。特に、運用設計方針を発注者と合意することが重要。
大まかな流れ
- 「運用設計書」に運用ルール、やること、やらないことを記載し、発注者と合意する
- 「運用フロー図」で役割分担を整理し、発注者と合意する
- 運用項目一覧を修正し、発注者と合意する
目的と役割
- 運用設計書
  - 発注者との運用方針の合意形成、ならびにシステムリリース後に運用に関わる人がシステム運用を理解するためのドキュメント
- 運用フロー図
  - 1つの運用項目に対して「いつ」「だれが」「どんな情報をもとに」「何をするのか」を合意することが目的。事前に発注者側とレビュー＆修正を繰り返すことで、関係者の納得度を上げ、運用に入った後の摩擦を軽減することができる。
  - 処理内容が可視化されることで、運用改善がしやすくなるという副次効果もあり

運用フロー図は全ての運用項目で作成する必要はなく、判断基準として、関係する登場人物が3つ以上出てきた時に必要かどうかを検討する。また、既存運用に類似の運用フローがあれば、運用フローの乱立回避のため、極力同じ仕組みを利用すること。　

詳細設計

前フェーズまでに合意した運用項目の作業について、実際に担当者がどうやって実施するのかを決めていくフェーズ。関係者とのディスカッションや合意事項は少ないが、代わりにドキュメント作成量が増えて人手が必要。
大まかな流れ
- 作成予定の関連ドキュメント一覧について発注者と合意した上で、WBSを作成する
- WBSに沿って、関連ドキュメントを作成する
- 運用フロー図に関連ドキュメントをマッピングする

WBS(WorkBreakdownStracture)の作成手順

作成予定の関連ドキュメント一覧を作成し、発注者と合意する
引き継ぎ先の既存運用担当がいる場合、既存の運用手順書、台帳、一覧などのフォーマットをもらう
ドキュメント一覧を元に、プロジェクトメンバ間で役割分担を行う　←発注者側で作成するかどうかも合わせて調整
ドキュメント毎に誰がいつまでに何をやるか、WBSにまとめる　←担当者を曖昧にしないように注意

ドキュメント毎の注意点

運用手順書
- 運用に関わる担当者の誰が実施しても、同じ結果が得られるものであることが理想
- 引き継ぎ先によってどのくらいの粒度で手順を作成すればよいのかが変わってくるので、早めに担当者にレビューしてもらって、この粒度で問題ないか確認すること
台帳、一覧
- 一般的には、値が頻繁に更新される可変データを集めたものが「台帳」、静的なデータの可視性を高めるために集約したものが「一覧」　← 厳密な使い分けはされていないことも多いが、2種類あることは覚えておく
- 不要な台帳化、一覧化は避けることも大切
  - 台帳：運用手順書や運用フロー図に紐づいていない台帳は不要とみなせる
  - 一覧：年に数度しか参照されない場合は、パラメーターシートや詳細設計書に書いてあれば問題ない
申請書
- 発注者側が採用している方法に合わせて、発注者と協力して決めていく
- 運用担当者が申請書を受領した際に、誰の承認があれば作業を実施できるかを発注者に決めてもらう必要がある　←利用数上限などシステム側の制約が特にない場合は、承認不要とするのも一つの判断

運用テスト、運用引き継ぎ

システムを運用、維持していけるかを、運用担当者が運用フロー図と運用手順書を元に検証する。
目的：不具合を発見して改善を行い、実際の運用に耐えられるようにすること。運用担当者への運用引き継ぎも兼ねることができる。
大まかな流れ
- 運用テスト計画書を作成して、テスト方針を発注者と合意
- 運用テスト仕様書を作成して、テスト実施内容を発注者と合意
- 運用テストを実施し、結果をとりまとめして、課題に優先度を付与する
- 関連ドキュメントの最終修正を行う

まれに発注者側から、運用テストを「プロジェクト側でやっておいて欲しい」と言われることがあるが、実際の運用担当者が運用できるかを判断する場なので、意義をじっかり伝えて協力してもらうようにする。また、運用設計担当は全体のファシリテーターに徹して、テストは実際の運用担当者に実施してもらうこと。

運用テスト計画書、運用テスト仕様書の作り方

運用テスト計画書
- 詳細設計フェーズまでに決めたルールやドキュメントが問題なく使えるかを、どのように確認するかの方針と計画をまとめたもの
- 運用フロー図と運用手順書を全てテストすれば、必ずほかのドキュメントも呼び出されて、運用設計した範囲を網羅的にテストできるはず
- 記載事項：目的、実施前提、範囲・種別、実施方法、スケジュール、実施体制、合否判定基準、運用課題の優先度、テストの成果物
  - 範囲・種別：「運用フローテスト」と「運用手順書テスト」の2種類
  - 実施方法：「実機テスト」と「机上テスト」の2種類
  - テストの成果物：主な成果物は、「結果報告書」「課題管理表」「エビデンス」の3種類
運用テスト仕様書
- 運用フローテスト仕様書
  - 関係者間の情報連携のテスト。手順書の実施は行わない。運用フローに関連する申請書のフォーマット確認、台帳更新は含まれる。
  - 多くの場合、運用テストにかけられる工数、スケジュールは限られており、分岐網羅ではなく命令網羅で行うのが一般的 ←一度でも実施した処理ステップは、ほかの箇所ではテストしなくて良しとする
  - 発注者には、分岐網羅で網羅性の高いテスト一覧を作成して、そこから命令網羅を判断基準にして実施項目を減らすことを説明して、納得してもらうようにする
  - 異常系のあとの作業は内容が重複するのでやらない判断になることが多いが、NG判定のタイミングが正しいか？の確認をテスト項目に入れおくと、少ないテスト項目でもクオリティを維持できる
- 運用手順書テスト仕様書
  - 運用手順書は利用者が1対1になっているため、運用フローテスト仕様書よりもはるかにシンプル
  - 全ての手順書を並べて、テスト実施内容、実行者、確認者を記載していく
  - 発注者と実施内容について合意した上で、どの項目を実機テストor机上テストで行うかを決める

課題管理表の作り方

テスト実施後に、全ての課題を一覧にまとめて、優先度と重要度を設定する。その後、システムリリースまでに課題対応するか、運用申し送りとするかを決める。
優先度の考え方については、テスト計画書作成の段階でしっかりと合意形成を行っておく　←プロジェクトの瑕疵として扱われる恐れがあるので
結論としては、実施効果が最も高い課題から優先的に対応するという考え方でOK。ただし、本番運用後の対応のしやすさは考慮すること。
以下は優先度の考え方の事例

優先度	内容
高	プロジェクト期間内に対応する課題
中	運用引き継ぎ完了までに対応する課題
低	運用中に業務改善として各担当で対応する課題

運用引き継ぎ

運用担当者がスムーズに引き継ぎできるように、システムの構成や特性、運用ドキュメントの説明、実機訓練などを行う
どれだけ運用設計、運用テストを行っても、サービス開始直後はどうしても混乱が生じる。運用開始初期の問題を解決、フォローするために、一定期間運用設計担当者が残って運用をサポートすることがある。これを運用支援と呼ぶ。
運用支援期間に実施することは、主に以下。
- 運用テストや運用初期に生じた課題に沿った運用改善活動、ドキュメント修正
- 監視パラメーターのチューニング
- 運用担当者からの問い合わせ対応、障害発生時のサポート、初回運用立ち合い
運用支援は能動的な活動ではない分、発注者へ定期的に活動報告を行い、方向性のすり合わせを行うようにした方が良い

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

業務運用の目的は、利用者とシステム側のやりとりが円滑に行われるようになること。発注者や利用者とシステムの利用方法を決めていくことが、業務運用の醍醐味。
ユースケースをもとに業務運用を整理していると、ユースケース自体を変更したいという要望が出てくることがあるが、ユースケースに対する変更要望はシステム要件の変更になるので、必ずプロジェクトマネージャーも含めて検討するようにする
利用者から作業依頼で何かを実施する場合は、通常作業と緊急作業とを分けてヒアリングすると運用項目をもれなく洗い出すことができる
運用フロー図はできるだけまとめた方が良い。運用が変わった場合の修正工数、修正もれリスクを抑制できる。運用開始後のドキュメント管理のことも考えると、無用なドキュメントは極力減らすべき。
社内サポートデスクが業務アプリケーションごとに分かれているのはあまり良い状況とは言えない。できることなら、社内のITサポートの窓口は1つで、そこから担当者へエスカレーションされるのが望ましい。
サポートデスクの最大の役割は、利用者からの問い合わせ情報の集約
サポートデスクの問い合わせ対応の基本動作 ①ヒアリングとその記録 ②一次対応 ③運用担当者へのエスカレーション
集めた情報は事前に利用者に周知したり、利用者の見える場所で公開することによって問い合わせ件数を減らせる可能性がある。利用者からの問い合わせを待つだけでなく、利用者に必要な情報を発信していく仕組みも考えておくこと。
サポートデスクの業務は全体的に受け身の対応になりがちだが、しっかり地道に情報発信していくことで、時間はかかるが問い合わせ数は必ず減らすことができる。
サポートデスクの問い合わせ内容には、システムに対する不満も含まれている場合が多くある。それらを丹念に拾い上げてアプリケーションの改修やシステム運用に活かしていけば、おのずと利用者満足度の高いサービスが出来上がるはず。
システム利用者管理のように「何かを使える or 使えないよう」にする業務は、基本的に全て、「追加」「更新」「削除」「棚卸」の4つを軸にして設計を進める
既存フローがすでに固まっている場合は、運用設計時はできる限り既存フローを流用しておいた方が良い。運用設計と運用改善を同時に進めるのは難易度が高く、混乱を招くことになるため。発注者から運用改善のリクエストを受けた場合は、別プロジェクトとして取り組む提案をすると良い。

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

基盤運用の目的は、アプリケーションなどの業務運用が継続されること
基盤運用については、発注者や運用担当者へヒアリングする前に、まずは仕組みと機能を理解したうえでこちらが考えるベストな運用案を提示する
パッチ適用は基本的に面倒な作業。セキュリティの側面が強く、運用コストとトレードオフとなる。システムの求められているセキュリティ要件を鑑みて実施頻度を決める。←最終的には発注者側が決める
緊急パッチのリリースに際しては、冷静に注意深く、自分の管理しているシステムがパッチのリスクに該当するかを確認すること　←ただし、該当するか判断が難しい場合は適用する方針としておいた方が良い
運用設計でセキュリティの正当性を考え始めると、終わりのない議論となって先に進めなくなる。「今のパッチ適用ルールはいけてないから変えたい」となった場合は、安易に受けずに別の専用プロジェクトを立ち上げることを提案する。
パッチ適用手順書は、頻繁に公開されるもの以外は面倒でもリリースされた更新プログラムの適用方法から、そのつど手順書を作るのがベター。なまじ最初にしっかりした手順書を作ってしまうと、運用開始後び手順書を信じ切って作業して問題が発生する場合もあるので要注意。
正常性確認手順書を作る場合は、どのような状態が正常であるかを発注者と合意しておく（合意した内容以外で問題が発生した場合はリスクとして許容してもらう）こと。正常性確認手順書を作成しておくと、後から確認手順を追記することができる。運用開始後のナレッジ反映先を準備しておくのは、運用設計として大事な観点。
運用設計では、そもそもサポート切れによる製品アップグレード作業を運用の範疇とするか、プロジェクト対応とするか決めておく必要がある。追加で費用がかかる作業は、運用開始後に調整するとなかなか決まらないので、事前に運用コストとして見込んでおくようにすれば、予算取りもしやすく対応もスムーズ。このように、運用開始後の運用担当者の調整事項の負担を減らすことも運用設計の役割の一つ。
ジョブとスクリプト
- 人の代わりにシステムに対する命令（コマンド）を実行するのが「ジョブ」
- ジョブをつなげて依存関係を明確にしたものが「ジョブネット」
- 一連の作業を即時実行可能な言語（スクリプト言語）で記載した簡易なプログラムが「スクリプト」
ジョブ／スクリプト運用で、運用設計で最初に取り組まなければならないのは、システム全体としての運用自動化方針の確認。必須ではないけれど運用上の効率化が求められる部分について、今回のプロジェクトでどう扱うかまで決めておく。必須でやる範囲、発注者の要望があればやる範囲、対応しない範囲を決めたら、決定事項をどこに記載するかも決める。基本設計書か運用設計書のどちらかになるが、二重記載はしないように注意。
ひとたび障害でジョブが止まったら、運用担当者が何も知らないでは済まされない。運用担当者はシステムで自動実行している処理を把握しておく必要がある。　←自動化項目一覧の作成大事
要件があいまいで、保守契約外で運用効率化のために作ったスクリプトは、だれが管理主体となるかはっきりせず、便利だからと使い続けているうちに仕様変更etcでスクリプトが動かなくなり、問い合わせ先もなく、運用者が途方に暮れることがある。保守契約のないスクリプトを作成する場合はスクリプト仕様書と処理フローを用意してもらい、運用担当者へ引き継いでおくこと。
システムとして管理しているジョブやスクリプトはどんなものであっても、トラブルがおこった場合は運用担当者が対応しなければならないことは確か。運用設計としては、それらの情報をとりまとめて、運用開始後に運用担当者が困らないようにしておく必要がある。
バックアップとリストアは必ずペアで考えること。運用設計では、どのタイミングで取得したバックアップを、どのようなタイミングでリストアする可能性があるかを常に考えておく必要がある。
リストア作業は実施頻度は低いけれど、緊急性の高い時に行わなければならない作業。 運用担当者は、慣れていない作業をプレッシャーの高い時に行わなければならないため、リストア手順書はだれにでも実施できるくらいわかりやすいものであったほうが良い
「定期バックアップがいつのまにか止まっていた」というトラブルは比較的多く発生する。バックアップソフトやコマンド実行結果のログを監視システムで検知させる方法はもちろんながら、半年に一度ぐらいはバックアップ状況を棚卸する運用項目も検討しておくと良い。
リストアについては、事前に発注者と「このような状態になったらリストアする」というポイントを合意しておくことで、緊急時にもめることなく判断できる
セキュリティポリシーに記載のログ保存期間を超えた時期にセキュリティ事故が起きる可能性については、発注者にリスクとして許容してもらう必要がある
ログ管理で一番大切なことは、システムが明示的に取得しているログが何の目的で取得されているのかを運用担当者が見失わないことと、すぐに調べることができる状態に情報をまとめておくこと。これにより、障害復旧の時間を短縮し、システムの安定稼働へ貢献できる。
セキュリティに関する考え方は時代によって変わっていくので、運用設計担当者としても情報をキャッチアップする必要がある

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

運用管理に関してはシステム個別で設計はせず、導入する企業の運用管理方法に従うことが原則。やりなれた管理方法に従ったほうが、管理をする側もされる側もサービス開始時の混乱が少なくて済む。加えて、システムが横断して共通のルールが適用されていた方が、ITガバナンスの強化にもつながる。
運用管理では共通ルールを徹底することにより、ITガバナンスの強化を目指す。運用設計担当は、無駄なドキュメンテーションをして運用担当者を混乱させないように注意する。
サービスを維持するためには、システムの維持管理を行わなければならないが、システムの維持管理はやればやるほどコストがかかる。
大切なことは、利用者と発注者が結んだSLAに対して、適切にサポートできる運用体制を組むこと。
どの会社でも情報セキュリティに関するルール（「セキュリティポリシー」）が必ずある。セキュリティポリシーは、守ったほうがよいというゆるいルールではなく、すべてのシステムが必ず守るべき鉄の掟。
セキュリティ対策について、システムの機能で対策できるのであれば、その方がセキュリティレベルが高いといえる。機能面でカバーができないインシデントが運用設計の設計範囲となる。
セキュリティインシデントは頻繁に発生するものではない。だからこそ、実際に発生した場合にどのような対応をとるべきかを明確にしておく必要がある。システムにユースケースや機能から発生しうるセキュリティインシデントを顧客と合意し、実際にインシデントが起こった場合の対応を考えていく。
運用設計でドキュメントをそろえる意味は、教育のときにこそ真価を発揮する。運用要員教育のため、プロジェクトの成果物とは別に運用ドキュメント一覧を作成する。
運用担当者の入れ替えがあった際は、ドキュメント一覧の対象ドキュメントをもとにシステム知識の教育を行う。前提知識を入れておくことで作業に対する理解度やトラブル時の対応などが変わってくる。何よりも、運用作業の目的が明確になることで、作業に対するモチベーションをもつことができる。自分がどのようなシステムのどの役割で、何のために日々の作業をしているのかを理解していることはどの担当者でも大切なこと。
定期訓練では、重大インシデント発生時の対応やDR（Desaster Recavery：災害復旧）の切り替え手順など、低頻度高重要度な作業をロールプレイする。あわせて、SLAやSLO、情報セキュリティルールなどの基準を再確認するようにする。年に一度、半年に一度だけでもシステムの基準を再確認することによって、障害対応や日々の作業に対する接し方が変わってくる。
システムを有効活用していくことは運用の大きな役割なので、利用者の改善要望があればできる限り応えていったほうが良い。ただし、投資対効果やメリットデメリッﾄを検討する必要はある。運用コストがかかりすぎてしまったり、一部の利用者のメリットのために全体にデメリットが出るような改善要望については、場合によっては実施しないという判断も必要。
インシデント管理はインシデントの解消を目的とし、原因究明は問題管理にて行うこと。インシデント管理で根本対策まで管理しようとすると、クローズできないインシデントが乱立する恐れがある。管理対象の増加は全量把握を難しくし、すぐに対応すべきインシデントの優先度を下げてしまう危険性がある。
発生したインシデントの問題やリスクを許容するという判断もある。インシデントが許容されて対応しない方針となった場合、ナレッジ管理にどのような経緯で対応しなかったかを記載しておくこと。同様なインシデントの時に過去事例として判断材料のひとつとなる。
運用のリソースは有限。 本来のやるべき運用業務を実施しながら問題解決を実施するので、優先度を決めなければならない。
重要度と緊急度は混同して考えられがちだが、きっぱりと分けて考えること。
- 重要度：サービスおよび、システムにどれぐらいの影響を与えているか？
- 緊急度：問題が発生する周期、次期からどれぐらいの対応速度が求められるか？
情報システム室と運用担当者が、問題管理の進捗確認や対応方針の決定が行えるように、問題管理会議を定期的に開催すること。
問題管理会議では、何か月も動いていない優先度の低い問題について、対応が不要なら思い切ってクローズとできるようにルールを定めておくと良い。サービスにもシステムにも影響のない優先度の低い問題をクローズすることによって、本当に対応しなければいけない問題が明確に見えるようになる。これも問題管理の重要な役割。
ナレッジ管理は、過去のインシデントや個人スキルの棚卸をして、だれでも利用できる形式知にしていくことで運用品質を向上させることを目的とする。
なんの判断も生まない報告は、極力しないほうが運用負荷が下がる。空いたリソースにトラブルや運用改善などを割り当てることができる。

ー以上ー

「運用設計の教科書」を読んだ

概要