運用項目の起源
運用項目（運用中に実施する作業）が洗い出されるパターンはいくつかありますが、代表的なものは以下の3つがあります。
① 運用要件に対応する
まずは、企業の要望、事前にまとめた非機能要求、遵守する法令・規約などによって、運用項目が決まるというパターンです。
システムに対するレポートを毎週提出してほしいといわれれば、レポート提出が週次になります。
非機能要件として、リソース不足時の「サーバ処理能力増強」方針が「スケールアップ」で、その作業を運用でやる場合は「サーバのスケールアップ作業」という項目が追加されます。
クレジットカード業界のセキュリティ基準であるPCI-DSSを準拠した場合、監査ログを最低12か月保管する必要が出てきます。
運用しているシステムで、どうしても90日しかログ保管できないサービスがあれば、手動でのログ保管などを検討する必要が出てきます。
このように、運用に求められる要件から作業が発生するのが1つ目のパターンとなります。
② 製品を使う上で必要になる。
次に製品を利用、管理していく上で必要になる作業があります。
クラウドサービスであれば、管理ポータルにアクセスするためのIPアドレス制限や、管理者権限の付け替えなどの作業が発生します。
システム基盤として製品を使うなら、パッチ適用やバックアップ、ログ管理、ライセンス管理などがついてきます。
③ 役割・体制上で必要になる。
最後に役割や体制として必要となる作業があります。
例えば監視担当であれば、アラート検知、一次切り分け、障害のエスカレーションなどの作業がついてきます。
セキュリティ担当者であれば、セキュリティインシデント対策、脆弱性の情報収集、社内外への情報共有、利用者への教育計画策定などがついてきます。
まとめ
これ以外にも、実装できなかった機能を運用でカバーしたり、人事異動などの社内イベントで発生する作業などもありますが、まずは要件・製品・体制に必要な作業をまとめて運用項目一覧を作成してベースを作るというのが良いかなと思います。
運用設計と運用改善の書籍を出版しています！
ご興味のある方は是非！
この記事が気に入ったらサポートをしてみませんか？