初めまして、中途入社4年目 キクチと申します。

前職では多種多様な業種の顧客向けシステム基盤の構築および運用が主な業務でした。

そしてエボルバに入社して最初に配属された現場は、前職と同様、多種多様な顧客システムやNW、サーバの運用設計、運用提案、保守運用を行う部署でした。

サーバの設計やNWの設計であれば何となくイメージが湧くものだと思いますが、運用設計？と当時頭の中であまりイメージが湧いてこなかったことを覚えております。

とはいうものの、保守運用を担う現場には絶対について回るものであり、ここを入念に設計しなければ
S-in後に問題多発、顧客からのクレーム多発etc...壮絶な未来が待っていることも往々にしてあると思いますので、どういうことを実施しているのかという部分を紹介していこうと思います。

運用設計とは？

運用設計とは、一言でいうとシステムの安定稼働に向けて、運用のフレームワークを作成することです。
日常・定期的に処理する作業、障害対応フローやルール、プロセス等、運用担当に向けた必要情報について
設計、まとめをして顧客および実運用担当者（担当会社や担当部署）との合意をとる、といった感じでしょうか。

運用設計のメリット

挙げるとキリがないので特に大きなメリットとしては以下3つと考えます。

①運用全体の効率化、最適化
事前に各関係者と、設計し説明、合意しておくことにより実運用時に無駄な確認や工数発生する余計な作業、発生を防ぐとこができます。
定期的に起こることが決まっている作業等も洗い出しておけば承認フローの簡素化や自動化することも可能となり、効率化最適化が進みます。

②様々なトラブルの事前回避および障害に対する対応の迅速化
起こりうるトラブル、障害について例外含め洗い出し、取り決めをしておけば顧客ニーズであろうトラブルの削減および障害対処の迅速化を図ることが可能となります。

③運用の属人化、ブラックボックス化防止
これがかなり重要だと現場に従事して特に感じており、どの顧客側および運用担当者側でも必ず課題として挙がってくるであろう
属人化の問題、担当者が離任や退職等で引継ぎされたももの不十分で非常に困ってしまう。という問題。（絶対に経験があると思う。）
運用設計段階で正確に情報を明記し、設計資料の定期的なメンテナンスを取り決めておくことで、上記リスクを削減できます。

運用設計での具体的な設計項目とは？

具体的な運用項目として何を設計しておくか、については要件やNW、SW等の基本設計、システムによって多種多様ありますが、主な例は以下かと考えます。

①基本方針
・運用設計の目的
・目標
・概要

②業務内容
・設計構築されたシステム上でどのような業務がなされるのか
・運用対象は何か
・システムを利用するユーザ範囲
などなど。

③管理対象項目
運用していく上で何がそのスコープ対象範囲かを明確に定義。
例）
・対象サーバやDB、NW
・ログ
・バックアップ
・ドキュメント
などなど。

④運用体制
運用を行っていく上での関係者、体制を定義。
・システム統括責任者
・開発責任者、担当者
・運用責任者、担当者
・保守担当
などなど、対象となるシステムによってベンダーやヘルプデスク等も利用することがあるかとおもうので
ここで定義しておくべき対象は変動が大きいです。

⑤監視設計
監視する範囲、方式等を定義。
・監視対象
・監視方法（死活監視、性能監視、セキュリティ監視など）
・ログの扱い（ローテーション、保管期限など）

⑥障害対応
・エスカレーションルール
・障害対処、対応フロー
などなど。

他にもバックアップを取得する運用であればバックアップ運用を定義する必要もあったり、BCP、DR、JOB管理等要件によっては上記に追加される場合もあります。
運用範囲内の物であればここで必ず定義しておかなければ後々顧客クレームや運用者が困ってしまう場面が出てきてしまうため正確に取り決め、定義しておく必要があります。

運用設計書として落とし込み＜重要！！＞

運用設計としてなされた内容は全て運用設計書、および関連資料といった形として明確にまとめておく必要があります。
昨今ではITILに準拠した資料作成を実施している企業がほとんどだと思いますが、運用を管理、効率化、障害対処、担当者変更等
様々な場合において参照される資料となるため、確実に実施することが推奨されます。
また、下記資料が作成されるべき資料の例となりますが、この資料群を定期的にメンテナンスしていくことが安定した継続運用では
必要不可欠となります。（1年くらいはなんとかなることもありますが、ここをさぼると数年後大きな問題になることが多いです・・・。）
・運用設計書
・保守運用要領書
・運用フロー
・手順書
・各種管理台帳
・運用報告書
などなど。

最後に

近年ではITIL（Information Technology Infrastructure Library）やDevOpsのような概念を利用した設計も重要視されてきておりますが、
まだまだ運用設計を軽視しがちなことは多いのかなと感じております。
実際に業務に従事してみて初期構築時から数年以上経っている案件は、運用方面で資料が纏まっていなかったり、運用スコープが曖昧だったり等、
様々な問題が起こり、どういったアプローチで改善していけばいいか分からず本当に運用設計は大事だということを再認識させられました・・・。

理想を言うのであれば、運用設計は要件定義といった早い段階から担当者が参画し、着手し始めるのが望ましいと思います。
（開発の初期から運用設計の担当者が参画していれば運用に必要なSaaSツールやその他機能を組み込むことも顧客と合意しやすいはずです。）

多様なシステムにおいては必ず更改のタイミングもあるかと思いますので、その際は運用設計の視点を意識することを推奨します。
恐らく何らかの役割と兼任したりする場合も多くあると思いますが、できる範囲からでいいと思いますので検討を進めてみると良いと思います。

運用設計は奥が意外と深く、ここでは書ききれていない事も多くあります。
本記事をクリックした方は少なからず運用設計というワードに興味や関心があるのかと存じますのでこれを機会にITIL、DevOps、PRINCE、PMBOKなど上記の参考となる概念や考え方、資格も多くあるので良ければ学習してみてはどうでしょうか。


以上、ありがとうございました。