はじめに
はじめまして、フューチャーインスペースの石崎です。
私の経歴ですが、約13年前IT業界へ異業種転職したところからスタート。新人開発者として某コンビニの開発PJにアサインされ、そのまま同PJの24h365d運用チーム立上げに携わり、運用保守フェーズを経験。以降は複数の運用保守設計や運用改善の案件に参画し、今に至ります。
運用保守設計のネタでブログを書いてみない？ とお誘いを受けたのでチャレンジします。
読んだ方に運用保守設計の面白さや難しさが伝わったら嬉しいです。
今回の内容
今回は運用保守設計がどういったものなのか、をイメージ出来る内容として以下をチョイスしました。
（1）運用保守設計とは何なのか？
凄く端的に言うと、システムが稼働した後のことを利用者(ユーザー)ではない視点で、あれやこれやと考えてどうするか決めていくことです。
システム開発設計が利用者視点で進んでいくのに対し、運用保守設計はシステム自体を動かす運用保守担当者の視点で進んでいきます。
例えば、車自体を作るのがシステム開発設計だとしたら、運用保守設計は、その車のメンテナンス方法を考えるような位置付けのイメージです。
そのため、システム開発プロジェクト中にはメンバーが業務要件やアプリ仕様を顧客と詰めているときに、運用保守設計の担当はシステムが動いた後のことを顧客と一緒に妄想しています。
- システムが停止した時はどれくらいで元の状態に復旧させる必要があるのか
- こういったことが起きたときは誰に連絡すれば最適な対応が取れるのか
…など様々な角度から設計します。
運用保守設計の範囲
基本的にはアプリケーションからインフラまで全てを設計範囲としています。
※システムはアプリやインフラなど複雑に絡み合いながら動くので、運用保守設計を行う場合は一気通貫で行うのが基本となっています。
そのため、運用保守設計のために読込みが必要なインプットはとても多いです。
アプリケーション仕様理解のために要件定義資料からアプリケーションの詳細設計書など、インフラ理解のために基盤設計書や、時にはソースやOSパラメータの確認も行います。
（2）運用保守設計で面白いところ
各現場で担当されている方は色々あるとは思いますが、個人的には「運用保守設計の最適解」を自身で考えて設計できるところだと考えています。
最適解の定義から自身で考えロジックを作っていくのは大変ですが、とても面白いです。
リスクやコスト、メリット・デメリットなど前提を具体化して条件を整理し、システム稼働後を妄想して設計、更にそれを顧客やPJメンバーと議論。共感や否定されたところを整理しまた妄想して設計、と1つ1つ積み重ねて行きます。
キャリアパスとしても各種領域をシステムを動かす側から考える運用保守設計は、中堅やベテランになればこれまでのノウハウを生かすチャレンジの場として、キャリアが浅い時は色々な領域を知るための場としても、面白い領域だと個人的に思います。
自身で設計実装したものがシステムの稼働後にどうなるかも確認出来るので、全てが想定通りだった時はとても気持ち良いですよ。
（3）運用保守設計の難しいところ
大きく2つあります、ここは各現場で運用保守設計を担当されている方も苦労されているところでしょう。
3-1. 実際に動かすのが人間の場合もあること
運用保守設計したものを実際に動かすのが人間である場合もあること、です。
アプリケーションであれば、バクが無ければ基本的に実装通りに動きます。システムほど嘘をつかず信用できる奴はいない、とまで個人的には考えています。
※システムが想定と違う動きをしているときは、基本的に人間が勘違いしているか設計ミスしている。
しかし、人間が動かすとなると話が全然違ってきます。ドキュメントを読んだ人間の解釈は無限大で、読んだ人の経験や、時にはその時のメンタルやフィジカルの状況まで影響します。
アプリ開発を経験してきたか・インフラ開発を経験してきたか、様々な要因で解釈やアウトプットに差が出ます。メンタルの例を挙げると、大型休暇明けの人は休暇前よりも読み違いを起こしやすいということもあります。
そのため、そういった影響を受けない、たとえ受けたとしてもリカバリが可能な設計というものが重要で、運用保守設計の難しいところです。
3-2. 運用保守で回避、という判断に対する備え
運用保守で回避、という判断に対する備えです。
システムが稼働した現場では「運用で回避」や「保守で対応」等、運用保守設計に無い想定外の業務が突発で発生することが多々あります。
運用保守で回避はシステムで問題が発生した時の最終手段です。運用や保守がなんとかしている間に、システム改修等を行うことで問題解決が図られます。
開発スキームでも各種施策が講じられていますが、運用保守設計としては、発生率の削減と想定外を無くす取り組みの2つ、でアプローチしています。
発生率の削減は、これまでの実績として、考慮漏れや実装不備、テスト漏れやアプリ不具合の影響で発生することが多いので、システム品質を高めるためにも、運用保守設計担当も積極的にシステム側（設計者や開発者）にフィードバックしています。
想定外を無くす取り組みは、開発⇒運用保守設計であった情報の流れを運用保守設計⇒開発の流れも作ることで相互チェックできる形にすることでアプローチしています。
システム設計開発中の「運用保守で回避」
ちなみに、「運用保守で回避」はシステム設計開発中にも出てきますが、こちらは基本的に検討先延ばしワードなので、現場の「運用保守で回避」とは全く異なるものです。
システム設計開発中にこの文言が出て来たら、色々な意味でドキドキしつつも、サポートするようにしています。
さいごに
DevOpsやSRE、RPA等が出てきつつも、まだまだ色々な可能性を秘めている運用保守設計の領域、ぜひ一緒にやってみませんか？