このあいだ、移行と運用の設計の話をしましたが、運用設計ってどうやって進めるのでしょう。
設計から製造工程では要求機能がきちんと動くことを目指してサービスインに向かうのですが、
ここには運用機能もきちんと動くことが大事です（あたりまえですが）
業務要件というのをもとに業務機能を設計し構築するのと同様に
運用要件というものをもとに運用設計をし、運用機能も「同時」に構築します。
運用要件は一般的に業務機能を運用できるようする非機能要件とよばれる（運用のための機能なのですが）
要件をもとに設計されます。
さて、その運用要件って誰がいつ決めるものでしょうか？
サービス要件によって作りが毎回変わる業務機能と違い、運用機能はどのシステムでも
大枠はだいたい決まっています。
それを実効するのも、ITILであるとか、ISO20000であるとかで一般的な体系も出来上がっているし、
統合運用ツールと呼ばれるものもいくつかあり、大抵はそれを導入します。
つまり、運用設計は何かシステムを最初に運用し始めた時にほとんど設計することになり、
その後の追加サービスはその運用設計に乗っかるという流れになるのです。
初期の運用設計は結構大変です。
今後のベースとなる運用のあるべき姿をとらえて、会社のシステムの運用管理を行う部署を
立ち上げたりします。
なので、このタイミングでは運用設計のコンサルが入ったりします。
このご時世、なかなか一から運用を作るという会社はないと思います。
それぞれのサービスを追加する場合は、すでにある運用管理部署の担当者がそのサービス要件に
適用させる必要がある運用要件を指示し、そのシステムの運用設計を依頼することになります。
アプリケーションのログ出力やバックアップ等の挙動についても、利用する運用システムの機能や
規定にのっとる必要があり、基本設計段階で運用設計の内容を取り込んでおかないと、
詳細設計時に検討が漏れてしまうことになります。
また、業務観点として「そのサービスがきちんと運用されている状態」ってどういう状態なのかを
SLAやキャパシティプランニングとして規定しなければなりません。
そして、その業務要件としての規定をチェックするための情報が取れることが必要です。
運用設計で決めなければならない細かいことは書きませんが、運用の目的は
そのシステムが正常に動いている状態をチェックし、また、業務が続けられるような
環境が整っていることを維持していくことです。
障害が発生した場合、環境のチェックまでが運用ですが、チェック後の作業が必要な場合は保守となります。
ということで、実は保守設計というものも必要になるのです。