ログの設計についてどのように考えるべきなのかを知りたかったため読んだが、周辺知識も有用だったため運用引き継ぎのパートをまとめ
前提
運用設計の目的の一つが、複雑な作業を整理して誰にでも作業できるようすること
運用引き継ぎとは
運用担当者が必要なフローや手順を理解し、必要なドキュメントやデータにアクセスできるようにすること
運用引き継ぎの方法
運用引き継ぎの方法は大きく分けて2つ
- ドキュメントの引き継ぎ
- スキルトランスファー
ドキュメントの引き継ぎ
運用を行う上での意思決定に必要な情報を意識した精査、作成
- 対顧客ドキュメント
- インフラ構成ドキュメント
- アプリケーション構成ドキュメント
- 運用設計ドキュメント
顧客ドキュメント
顧客に対するドキュメント
顧客に依頼されたドキュメントやガイドライン的なものなども。
個人的には顧客への対応ノウハウもあっても良いと思う
インフラ構成ドキュメント
アーキテクチャ構成図はじめ、概要を理解するのに必要な設計図や手順書など。
利用頻度をもとに分類した方が良い
アプリケーション構成ドキュメント
UML図など。
開発時にだけ必要だったものと運用後も必要なものを選別する
運用設計ドキュメント
運用設計書、運用フロー、運用手順書、管理一覧シートなど。
更にそれらを説明するため作成した資料などもあった方が良いものは必要
スキルトランスファー
運用スキルの展開
運用担当者が触れたことのない機器や設計思想（アーキテクチャ）があれば、勉強会や説明会を開催して理解を深めてもらうこと。検証実機によるハンズオンまで実施すれば、運用開始直後もスムーズな運用が期待できる。
具体的には下記3つ
- システム理解
- 技術理解
- 運用理解
↓
安定運用
実施を推奨するもの
システム説明会
PMが主催して、運用担当者に対してシステムの仕様や現状、今後の方針を説明する。
説明会には既存のアプリ、インフラ、運用担当含め、システム開発に直接関わっているメンバーも参加すると望ましい。
できるだけ質問をその場で回答して課題として残さないようにする必要がある
導入製品勉強会
初見の導入製品などがある場合は勉強会などを開催しても良い。
一般的な製品仕様や機能を説明する。
運用テスト
運用を想定し、手順書、フロー図、管理シート等に問題がないことを確認する。
実環境が使える場合は、利用するアカウント権限まわりなど事前に説明や確認しておく必要がある。
運用引き継ぎ管理項目
網羅できているか確認する
| 項目 | 内容 |
|---|---|
| システム説明会/勉強会実施日 | システム説明会、導入製品勉強会の実施日程と周知日、概要などをまとめておく |
| 参加者 | 説明会、勉強会、運用テストの参加者を把握し、引き継ぎ対象に網羅性があるか確認する |
| 説明内容 | システム説明会、勉強会、運用テストにて行う説明内容を整理して、参加者に対して適切な内容であるか確認する |
| 宿題・課題管理 | 各会の参加者からのコメント・指摘管理して対応する |
| 決定事項・申し送り事項 | 各会での決定事項や、運用に対して申し送りとなる事項を取りまとめてドキュメントと合わせて引き継ぎを行う |
| 参考資料 | 引き継ぎ資料として運用担当へ渡すドキュメントをまとめておく |
他ポイント
- 手順書と実体が乖離していないかを確認し、しているのであれば修正または削除をする
- 属人化していて可視化できていないものはまずドキュメント化する
書籍情報
JBS Technology Inc, 近藤誠司(監修), みんなが知っておくべき運用設計のノウハウ
https://amzn.to/2VU8olW
雑感
そのまま直接引き継いでも属人化を引き継いでいるだけであり運用の効率化になっていないし、それをもって引き継いだと言えるのは確証性もなく、それによる齟齬やキャッチアップコストの増大は伝える側の怠惰が原因となってしまいそう