前回の記事が長くなりすぎたので分割後編です。フェーズごとの運用設計を把握したので、カテゴリごとにどんな運用項目があるかをまとめます。
運用カテゴリごとの項目
主に要件定義や基本設計フェーズで行う運用項目の洗い出しの時、次にあげるような項目を記載する。
業務運用
対象範囲
利用者とシステム管理者間のやりとりを円滑に行う。サービスを提供するアプリや利用者に関連するものが多い。
IPO
- インプット情報
- ユースケース
- アプリケーション機能
- 利用環境
- 発注者要望
- 処理内容
- BPMN フロー図作成
- 役割分担整理
- 既存申請方法の確認
- 利用マニュアルの確認
- アウトプット情報
- 運用フロー図
- ユーザー利用手順書
- FAQ
- 運用手順書
- 申請書
- 台帳
BPMN フロー図 (Business Process Model and Notation) を作成して処理を整理する。BPMN フロー図は業務の流れにフォーカスしたフロー図のこと。
運用項目
システム利用者管理
システム利用者に関して変更があった場合や利用状況を確認するための項目。
- システム利用開始：入社、昇格、異動などでシステムを利用する場合に実施
- システム利用変更：異動などで登録を変更する場合に実施
- システム利用停止：休職や退職でシステムを利用しなくなった場合に実施
- 緊急申請作業：進級申請によりシステム利用に関する変更作業を早急に実施する
- 利用者棚卸し：定期的に停止漏れがないかを確認するために棚卸しを実施
サポートデスク
利用者向けの窓口に関する項目。問い合わせ先は1つに統一することが望ましい。
- 問い合わせ対応：利用者からの問い合わせを管理し、一次管理とエスカレーションを行う
- 情報発信：定期メンテナンス情報、障害情報、Tips を公開する
- FAQ の更新：頻出する問い合わせの中から汎用的な作業を公開情報として更新する
- 定期報告：問い合わせ件数や、解決率、対応時間などを集計して報告する
デバイスライフサイクル管理
利用者に貸し出すデバイスに関する項目。故障時に必要な代替機の管理や、棚卸しを円滑に進めるための確認方法（二次元バーコードなど）も決めておく。
- デバイス貸し出し：利用者へデバイスの貸与を実施
- 故障時対応：デバイスの故障代替機器交換を実施
- デバイス返却：利用者からデバイスの返却対応を実施
- 棚卸し：台帳と差異がないか確認を実施
- キッティング：デバイスの物理作業
- マスター更新：クライアント PC のマスターイメージ更新
基盤運用
対象範囲
サービスが安定して動作するようにシステム基盤を運用するための項目。ハードウェアや OS、ミドルウェアが対象となる。
IPO
- インプット
- 基本設計書
- パラメーターシート
- 運用体制・運用ルール
- 処理内容
- 情報の取りまとめ
- 運用担当とのすり合わせ
- 発注者との合意
- アウトプット
- 運用フロー図
- 運用手順書
- 台帳
- 一覧
運用項目
パッチ適用
セキュリティホールとバグを修正するためにソフトウェアに対する更新プログラムの適用する。
トリガーは定期と緊急の2種類。システムの正常性を定義するため、必要に応じて事前事後の作業手順書も作成する。
- 適用対象：OS、ファームウェア、ソフトウェアなど
- 適用基準：外部組織 (JVN や JPCERT) などによって公開されたセキュリティスコアなど
- 実施判断者：適用する担当者
- 実施手順：メーカー手順とシステムに個別に合わせた手順
ジョブ / スクリプト管理
定期的に行う作業はジョブやスクリプトにしておく。システム上でどこまでが基盤やアプリで動いて、どこからがスクリプトによる外部入力の自動化なのかはっきりしておく。
- スケジュール変更
- ジョブの再実行
- ジョブの停止
ジョブは台帳にどのようなものがあるかをまとめておく。
- 分類
- 実行対象
- 処理概要
- 実行周期
- 開始時刻
- 停止時の影響
- 停止時の他システムへの影響
- 停止時の再実行
- 停止時の代替手段
バックアップ / リストア運用
どのタイミングのバックアップをどのタイミングでリストアするかといったバックアップに関する方針を決めておく。基本的にリストアは障害や設定変更時に不具合が発生した時、データの復旧を目的として利用する。
- バックアップスケジュールの変更
- 依頼によるリストア
- 依頼による手動バックアップ取得
取得しているバックアップについては設計書などにまとめておく。
- バックアップの目的：システム復旧かデータ復旧か、DR も考慮するか
- バックアップ対象：どんなデータを対象とするか、対象によっては最構築手順を定める
- 取得周期、世代数：RTO と RPO から算出する
- 取得可能時間：バックアップを取得する時間に制限があるか
- バックアップ方法：バックアップを取る方法
- バックアップ取得媒体：データを保存するストレージ種類
監視運用
システムの監視に対する項目。
- 監視対応：アラートを検知して一次切り分けもしくはエスカレーションを実施：非定期：アラート検知時
- 監視設定変更：監視項目の追加・変更・削除を実施する：非定期：依頼時
インフラ監視
- 死活監視：ping などで OS 起動を監視
- ハードウェア監視：SNMP でハードウェアの以上を確認する
- リソース監視：CPU、メモリ、ストレージ、ネットワークの値が閾値を超えていないか確認
- プロセス監視：OS で動作しているプロセスやサービスが起動しているか確認
- ログ監視：OS やミドルウェアのログを確認する
ログ監視は一般的にはエラー/err以上を監視対象とし、警告/warning以下は障害発生時に内容を確認できるようにする。
サービス監視
- HTTP 監視（URL 応答監視）：応答コードや応答時間の確認を行う。
- 画面遷移監視（シナリオ監視）：入力や操作から想定通りの動作をするか確認する。
サービスレベルと対応時間
対応可能時間と連絡先をまとめておく。 障害の重要度を定めておくとエスカレーション時のやりとりがスムーズになる。
- A：サービス全停止
- B：サービスの一部機能停止、縮退運転
- C：サービスは継続しているが、冗長化しているコンポーネントが一部破損
- D：サービスに異常は無いがアラートが上がっている
ログ管理
- 障害調査：障害時に一次対応として確認する
- 監査対応：数年単位でログを収集保存し、確認できるようにする
ログの保管期間
- 障害調査用には2〜3ヶ月分を保管しておく。
- 監査対応のログは数年単位でとる。全社ポリシーに規定があることがあるので確認
運用アカウント管理
- アカウント追加・変更・削除
- アカウント棚卸し
- パスワード変更
アカウントの管理方法
- ローカル特権 ID
- AD 特権 ID
特権 ID はなるべく IDP で管理する。権限を付与する場合は個人のアカウントに必要な管理権限を個別に付与する。 管理権限が付与されていた期間も管理しておく。
アカウント自体を払い出す場合は、アカウントを共有するケースもあるので注意する。 利用者が変更になったらパスワードを初期化する。
保守契約管理
- 保守契約管理台帳の更新：保守契約の内容、期間、問い合わせ先などの情報更新
- 機器故障時対応：部材発注、受け取り、現地立ち会い、交換部材の発送など
保守契約管理台帳
交換時にメーカーサポートがどこまで対応してくれるか。 保守サポートから提供される情報をまとめておく。
- 保守契約名
- 機器名、ホスト名
- 型番、シリアルナンバー
- 保守問い合わせ方法
- 問い合わせに必要な情報：契約番号やライセンス番号
- 受付対応時間
- 対応内容概要
- オンサイトサポートの有無
- 制約事項
- 保守契約期間
- 保守契約更新方法
運用管理
対象範囲
運用全体の方針、セキュリティポリシーなどを踏まえた全体共通ルール。
IPO
- インプット
- 既存の運用方針
- セキュリティポリシー
- その他のポリシー
- 処理内容
- 関係者へのヒアリング
- 項目ごとのカスタマイズ
- 定期報告内容
- アウトプット
- 運用フロー図
- 運用手順書
- 台帳
- 報告書
参考にする既存ルール
- 会社全体のサービスレベルの考え方
- インシデント管理や問題管理、リリース管理などのルール
- アカウント管理やパスワードルール
- システム開始時に運用と準備しておかなければいけない基準
- 定期報告書雛形
運用項目
運用維持管理
- サービスレベル管理：SLA を維持するための運用体制や仕組みを検討する
- キャパシティ管理：導入するシステムのキャパシティに関するデータを収集・分析・報告する
- 可用性管理：システムの稼働データを収集・分析・報告する
- 情報セキュリティ管理：セキュリティ方針を維持するために運用ですべきこと
- IT サービス継続性管理：災害時にサービス継続するためにすべきこと
- 運用要員教育：運用担当者がシステムを理解するべき基準をまとめ、定期訓練の実施周期など
サービスレベル管理
サービスを提供し続ける時間を定義する。SLA や SLO を定義する際は測定可能な指標を用いる。
サポートデスクの SLO であれば次のような指標を用いる。
- 一次回答率
- 応答時間
- 正答率
キャパシティ
リソースの過不足確認と需要予測する。
セキュリティ
セキュリティポリシーの変更にはコストをかけてでもやるべきである。セキュリティポリシーの変更に伴う反映箇所は残しておく。
IT サービス継続性
災害時に切り替えを実施できる体制を考える。
担当者教育
担当者の入れ替え時と定期訓練を考える。定期訓練では重大インシデント発生時や DR の切り替えなどをロールプレイする。
運用情報統制
- ユーザー問い合わせ対応
- 監視アラート対応
- 改善要望：改善要望の受付と実施判断
- インシデント管理：チケット起票、ワークアラウンドの実施
- 問題管理：起票、原因調査、対策の実施
- 変更管理：要求の起票、計画策定
- リリース管：リリース計画の作成と承認
- 構成管理：管理大賞の追加、更新、削除、棚卸し
- ナレッジ管理：ナレッジの収集、選別、活用、公開など
インシデントの解決（高級対策、応急措置、許容）後、継続して取り扱う課題であれば問題管理台帳に記載する。
構成管理
CI (Configuration Item) と CMDB (Configuration Management Database) で管理することが推奨される。
定期報告
利用者数や利用時間 キャパシティに対する閾値 パフォーマンスの閾値や応答速度などの相関を分析する。情報収集と報告資料の作成、開催の調整が必要となる。
コメント