近頃、運用時の引き継ぎの不十分さに起因して、一定の標準項目があったほうが良いのではないか、なんて話があった。
この手の話で難しいのは、チェックリストにしてしまうと、リストにないものを想像するのが難しいみたいなやつがあると思っている。
会計の世界だと、原則主義と細則主義というのがある。
前者は、原則論、その考え方の背景や趣旨を述べて、個別の事象については都度原則に照らして考える主義。
後者はその逆で、個別の事象などについて言及することから考え方や趣旨を示すような主義。
個別の事象の種類の豊富さや変化の多さによってどちらがいいかは変わるけど、変化を前提にすると原則主義の方が結果として趣旨に沿った対応がなされる傾向にある、とされている。
で、運用の引き継ぎについても同様だと思っているというのが自分の考え。
細則主義で一挙一動個別事象について語るのは、手間がかかる上に実際には効果的ではないと思っているので、こういう項目について検討した方がいい、というレベルだけ標準化し、その中身は現場の個別の案件に委ねるのが効率的かつ効果的なのだろうと推測してる。
じゃあ何を、というあたりで少し困るので次の箇所から抜粋・意訳して標準項目を検討するたたき台とした。
"22. The Operational Viewpoint, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, Second Edition"
関心事 | 内容や例 |
インストール・アップグレード | インストールやアップグレードが必要な対象、またその方法など |
提供機能移行 | どんな提供機能があるか、当該機能の提供をやめたり別のものに置き換えたりする場合にはどんなことをしなければいけないか |
データ移行 | どんなデータがどこにあるか、当該データを別の場所に移行する際に必要なことは何か（ETLとしてなにをしなければいけないか） |
運用監視と管理 | システムを動かし続けるためにしなければいけないこと、動いているかを確認するために見なければいけないことややらなければいけないこと（註：ここでの監視はLivenessの方） |
アラート | システムが正常に動いているか、動いていない場合にどのようなアラートをどう飛ばしどう管理するか（註：ここでのチェックはReadinessの方） |
構成（パラメーター）管理 | OSやアプリで必要とする設定値などの管理や変更の方法 |
性能監視 | パフォーマンスに問題ないかを見るために何を確認するか（註：ゴールデンシグナルに紐づくメトリクスを特定するイメージ） |
ユーザーサポート | エンドユーザーは誰でどのようなサポートが必要か、どんなレベルのサポートが期待されておりそれを誰が提供するか |
バックアップと復元 | どのようにバックアップをとって、どのように復元するか |
ただ、これだと、セキュリティの観点は部分的には入ってもかなり希薄な印象。
同じ書籍内にSecurity Perspectiveの記述もあったのだけど、ちょっとこれだと具体性が薄くて使いづらいと思った。
というわけで、『情報セキュリティプロフェッショナル教科書』の14章参照。（一部抜粋）
セキュリティの運用ポリシーの策定が必要、ということで、次の項目が上がっていた。
・ネットワークのアクセス制限：FW設定や、ネットワークまたぎでのセキュリティレベルの違いの特定など
・サーバーのアクセス制限：アクセス可能な環境の制御など
・アカウント管理：操作ユーザーとアカウントを紐づける仕組みなど
・ログ（上記に関するもの）の管理：セキュリティログの保存場所、特に同じサーバー上には置かないなど
そもそも守るべきリソースの特定（セキュリティ上守らなければいけない価値あるもの）をする、という話と合わせてドキュメンテーションすれば引き継ぎの項目としては一定の充足度となっていそうな感じがする。
これをたたき台に関係者や実際に運用する立場からアイデアを出してもらって、あとは記載に迷いを減らすように凡例などをつけるとよさそう。