内容
主にITシステムのエンハンスや運用業務を次担当者に引き継ぐときに必要な項目をまとめてみました。パブリッククラウドで構築されているシステム向けの説明になっています。
システム概要
概要の説明
まず、保守対象となるシステムの概要から話したほうが次担当者も理解しやすいと思います。主な機能やデータは何になるのか、画面数やデータベース規模（テーブル数やレコード数）を話すと良いです。
主な使い方
エンドユーザから見たシステムの主な使い方を記載します。マニュアルのリンクなどが貼ってあると良いです。
システム構成
サーバ構成
どのようにシステムを構築しているか、サーバベースで説明します。また、サーバ構成図があればリンクします。
アプリ構成
どのようにしてシステムの機能が実現されているか想像しやすくなります。Webサーバとバッチサーバが別れている場合には記載します。
使用しているクラウドサービス
パブリッククラウドで使用しているサービスを羅列しておきます。AWSであればEC2やSMS、SES、CloudFront、S3など、どのようにシステムが構成されているか想像しやすくなります。
使用している外部サービス
有料／無料にかかわらず、外部のサービスをWeb APIなどで使用している場合に記載します。下記のような外部サービスが考えられます。
- 決済系の外部API
- 監視系の外部API
- Google Maps APIなどの地図系API
データベース構成
トランザクション系、マスタ系など、どのようなテーブルがあるかを記載します。テーブル定義書などがあればリンクを張ります。トータルテーブル数などがあると規模を想像しやすいです。
ロール
ログインが必要なシステムであれば記載します。特に、権限の強さが異なるようなIDがあれば詳細を記載します。例えば、システム管理者向けの特権IDや、テナント管理者ID（マルチテナントが考慮されたシステムの場合）が考えられます。それぞれ、一般IDとの権限の違いを明記します。そのID固有のボタンやコマンドが存在したり、特別ページが存在するなどが考えられます。
接続情報
各種アクセスする方法を記載します。
アプリケーションURL
アプリケーションのTOPページや、ログインページを記載します。環境が複数ある場合（例えば、開発や検証環境）すべての環境のURLを記載します。
アプリケーションログインユーザ
ログインして使用するシステムの場合は、メンバーで共有しているアカウント情報をまとめておきます。複数のロール（一般ID、特権IDなど）がある場合はすべてのロールのログイン情報を記載します。
パブリッククラウド自体のアクセス情報
パブリッククラウドのアカウント情報を記載します。AWSであれば、共通で使用しているIAMなどを記載します。記載できない場合は、誰が管理しているか、どのような連絡方法を取ればよいか記載しておきます。
コードベースの情報
コードリポジトリがどこにあるか記載し、アクセス方法も記載します。複数のリポジトリがある場合は、すべてを一覧にして詳細を記載しておきます。
各サーバへのSSH
各サーバへsshするための情報を記載します。IPやSSHキーファイルの在処、SSHポートに制限がかかっている場合はその旨も記載します。.ssh/configの形式で貼り付けておくと便利かもしれません。
データベース
運用のため、データベースへの接続方法を記載します。私の環境では、SSHトンネルを使用した接続がメジャーでした。その際、踏み台サーバがあるのか、特に用意しておらずなにかのサーバを流用しているのかがわかると良いです。
ログ閲覧方法
運用には欠かせないログの閲覧方法や取得方法などを記載します。logstashなど収集系のアプリを別途用意しているなら良いのですが、そうではない場合は各サーバのどこに出力されるのかを一覧しておきます。
環境構築手順
環境をどのように構築したのか、環境構築手順を記載します。
ローカル環境
各々の環境が揃っているのは稀で、微妙な環境の違いで構築が困難となる可能性があり、ローカルの環境構築は難しいと思っています。dockerやvagrantなどで簡単に構築できるようになっていると時間の節約になります。
パブリッククラウド環境（本番/検証/開発）
どのようなミドルウェアが必要なのか、どのようにインストールしたのか、設定ファイルはどこか、環境ごとに違いがあるかを記載します。
リリース手順
リリース手順書があり、その通りに実施するのか、スクリプト等である程度自動化されているのか、CI／CDの機能で自動的に行われるのか記載します。
他システム連携
データを何かしらの形で別システムへ連携する機能があれば記載します。CSVで定期的にデータを出力していたり、データベースを他システムと共有している場合は記載します。CSVなどであればそのCSVのIF仕様書などのリンクも記載します。
定型業務手順
毎月や毎年など繰り返し行われている作業を記載します。どのくらいの負担がかかるのか次担当者が運用をスケジュールするのに役立ちます。また、あまりにも作業が多かったり、重かったりする場合はスクリプトにしてしまうなど自動化を考えたほうが良いかなと思います。下記にWebシステムなら必要かなと思われる定型業務を記載しました。
ドメイン更新
システムで使用しているドメインについて、どこで取得したか、期限切れはいつか、どのような支払い方法をしているかなどを記載します。また、必要に応じてドメインの更新を忘れないよう、更新手続きの時期にカレンダーに予定を入れておきます。
SSL/TLS証明書更新
ドメインと同様に、システムで使用している証明書について、どこで取得したか、期限切れはいつか、どのような支払い方法をしているかなどを記載します。また、必要に応じてカレンダーに予定を入れておきます。
マスター更新
マスター系のデータについて、別会社から購入しているデータがあれば記載します。例えば、住所や駅データ、電話帳などです。また、どのようにシステムに取り込むのか、取り込む手順書などをリンクしておきます。
イベントや告知系
定期的に行われるイベントが発生したときに伴う業務を記載します。例えば、バナーや広告の追加や変更です。変更手順が残っていれば次回作業時の時間節約になります。
スポット業務
繰り返しでなく、毎回ことなる作業や調査・判断が必要な業務を記載します。
- 退会
- ログインが必要なシステムからの退会処理（手作業が必要な場合は手順を記載します）。
- データ削除
- 何かしらの問題が起きてデータを削除ないし無効にする必要がある場合は、その手順を記載します。
経験上、データ削除系は考慮や実装されていないものが多く、運用フェーズで発覚し、運用でカバーすることが多いです。また下手に弄るとシステム障害につながる危険性もあるので、あまり出番はないものの、手順はしっかり残したいところです。
その他
その他で記載してあると良いと思う項目を上げておきます。
- エラー調査に役立つ情報
- 起きやすいエラー、仕方なく対応しているエラー
- 調査と対応結果
- 意思決定やプロジェクトの目的系の項目
以上です。