初投稿ですね。SUGINORLと申します。
おもに金融系のシステムを担当しています。社会人になって7年ぐらいSEを、そのあとFINTECHベンチャーに在籍していまはシステムコンサルタントをやっています。
今回は、支援先企業でエンジニアの方にお話ししたシステム運用設計の話を共有しようと思います。人によっては当たり前の話だと思いますが、現場ですごく新鮮な表情で聞いていただけたので、何かのお役に立てればと。
システム運用って何
一般的にシステムは、作った後も利用されます。
利用し続けるためにはいろいろやるべきことがあります。
それを設計するのがシステム運用です。
システム運用はめんどくさい
システム運用は、だいたいは、「非機能要件」、つまり本来の機能とは関係ない要件と結び付けられていることが多いです。
それは、CPUやメモリにそこそこの余裕があるかだったり、障害を検知したり、発生したら対処する仕組みだったり、色々あります。だいたいこれらの設計は、「本当に作りたいもの」とは違うので、エンジニアには嫌われがちだったりします。
また、システム運用を担当する人（システム障害を検知したり、対処したりするための専門部隊）が個別にいる場合は、その人達とうまくコミュニケーションできなかったりしてイライラすることが多いかと思います。
なぜ、システム運用設計は必要なのか
もう早速本題なのですが、では、なぜシステム運用が必要なのでしょうか。
それは、 仕事を、人ではなくシステムにやってもらうために、どうしておけばいいのかを考える必要があるためです。
その業務を人がやっていれば、「何かおかしい」と気づいたり体調を崩したりした時に、「ヤバイヨヤバイヨ」を上司に報告することができます。しかしシステムは（今のところ）とても素直なので、そうはいかないわけです。
そこで、システムに、この手の「ヤバイヨヤバイヨ」を気づいて、報告してもらう必要が出てきます。これがシステム運用設計の目的です。
このように考えれば、決して監視したり、ジョブを組んだりするのが目的ではないということがわかっていただけるかと思います。
システム運用設計の入り口は「その業務は何か」を明確にすることから
それでは、どのように進めていけば、システム設計はうまくいくのでしょうか。
それは、システムが担当する業務を明確にすることからはじまります。
「運用設計に入る頃にはそんなの明確なのでは」と思いますが、意外にそうではなかったりします。
アジャイルでは当然ですが、ウォーターフォール開発でも、要件定義時から設計に入ったところで、システムが担う業務が少し変化してしまっていることはよくあるのです。そこで、「このシステムがやってる業務は何か？」を一度整理することがとても重要になります。
一方で、これが明確になってくると、その後の掘り下げはとても簡単になってきます。
「その業務は何か」を明確にすると運用設計は掘り下げやすい
例えば、ボタンをクリックすると「Hello!」と返してくるシステムを考えます。
そのシステムは、「Helloと言ったら、Helloと返す業務」ということになります。受付嬢の代替かなにかでしょうか。
すると、ユーザに対して掘り下げるべきことは以下のようになってきます。
- その業務の恩恵をうけるのは誰か
- いつ、その業務が必要となるのか
- その業務が止まったとして、いつぐらいから、どれぐらい困るのか
それぞれ見ていきましょう。
その業務の恩恵をうけるのは誰か
とても基本的なことですが、システムが担う仕事の恩恵を誰がうけるのかは重要です。特に一番重要なのは特定できるか、できないかになります。
例えば、社内システムで特定の部署しか使わない場合と、インターネットに公開されていたり、大企業の広範で使われるシステムの場合ではその設計は大きく変わります。
仮に障害が発生したとして、前者の場合はその回避策などをメールや電話で連絡したりすることもできますし、復旧のための協力を容易にお願いすることができたりします。この辺をうまくシステム運用に組み込むことは、システム運用のコストを下げる鍵だったりします。一方で後者の場合はそうはいきません。仮に障害が起きてもアクセスを止めることができなかったりしますし、その対応を利用者にお願いすることはとても難しくなります。このため、回避策や復旧策はかなり凝ったものにする必要が出てきます。
いつ、その業務が必要になるのか
わかりやすく言えば、24時間365日稼働させる必要性があるのか、ないのか、ないなら、どの時間帯稼働してればいいのかということです。これによって、たとえば障害発生時に対処できる体制をどれぐらいのレベル感で整えればいいのかや、メンテナンスでサービスを停止しないといけなくなったときはどうすればいいのかなどを考えることができます。
この手の話をすると「それは、24時間365日できるに越したことはない」とか言う人がいたりしますが、理由もなく長時間稼働させることはコストの増大に直結します。全体のコストバランスを考慮して、適切な営業時間を見積もることは商売の基本中の基本であるように思います。理由もなく、平気でこのようなことを言ってしまう人は、独裁国家で強制労働をしてくればその感覚が養われるのでオススメです。
反面、「どの時間にお客さんがくるのかわからないから、まずは24時間営業させて確かめたい」など、しっかりした理由があれば、コストをのんでもらい、その前提の設計を組む必要があると思います。（最近はこの手の考え方が多いように思います）
その業務が止まったとして、いつぐらいから、どれぐらい困るのか
一番むずかしいのがこれです。ここをうまくユーザから引き出せるかどうかが、SEを含むシステムサイドの人間の腕の見せどころではないかと考えています。
前述の「Helloと返してくるだけのシステム」を受付におくシステムだとして、話を進めます。
この場合、システムが止まると、お客さんが受付にきても誰も挨拶ができなくなります。そのことの事業へのインパクトを「いつから」「どれぐらい」で明確にしていきます。
今回の場合
- 「いつから」は、次のお客さんが来たとき
- 「どれぐらい」は、事業に直接影響はありません
上記の場合は、「障害を検知した場合は、システムの復旧にあたり、その間は人で代替する」といった具合で、設計としては、検知する仕組みと停止する仕組みを実装しておけばいいです。この要素に上の「いつ、その業務が～」を組み合わせれば、「検知しても通知するのは営業時間内」といった設計を組み上げていくことができます。
この例ではかなり、レベルの低い要件ですが、例えば「業務が停止すると、その時点から1時間あたり1億円の機会損失が発生」などであれば、障害が発生すると即座にフェールオーバーなどの業務自動復旧が働く仕組みと、障害を検知し体制を構築して、影響の調査と復旧にあたるためのルールを作っておく必要が出てきたりします。
業務が明確になったらやること
業務が明確になれば、あとは「業務が止まる可能性がある障害」の洗い出しと、その検出方法と対処について設計をする作業に入ります。これにはいくつか方法がありますが、トップダウン（業務フロー停止の想定）と、ボトムアップ（ソースのバグ、ハードウェアやミドルウェアなどの技術要素が停止した時の想定）の２つのアプローチから、業務へのインパクトを見積もり、「検知」と「対処」のためにどのような仕組みを作っていくのかを考えていく作業になります。
正解は「できるだけまったり」運用できるシステム
最後に忘れがちな運用にかかる人的コストの話をしておきます。
システム運用はかなりの精神力を使います。それは「早く戻したい」という焦りや「いつ何が起きるかわからない」といった恐怖感からきます。上述の「運用設計はめんどくさい」とこの精神がすり減ることのジレンマが、運用担当者と開発担当者の軋轢を生むことが多くあります。
したがって、できるだけ人の手間をかけず、コストを最小限に抑えながら業務を継続するために備える必要があります。むやみに電話がかかったり、アラートがなったり、必要もないのに即時対処が必要なしくみは作るべきではありません。
よく「そうなったらみんなで考えよう」「そのときは頑張ろう」という人が出てきますが、私の経験上、そういうことを言った人がそうなったときに頑張ってるのをあまり見たことがありません。
また、システム構築時の設計は通常滅多に変更されることがありません。最初に人にやさしいシステムを作っておくことが重要です。
最後に
運用設計の必要性について書きました。あえて「必要性」を強調したのは、よく経営から優先度を下げられがちだからです。
見落とされがちな背景は、金額に出にくいことにあります。実際、備えるのにコストがかかりますが、それが利益をあげることはありません。また、コストをかけても何も起きないこともあります。（それにこしたことはありませんが）いわば、かけたコストに対してリターンが見込めない、年金のようなものと思われがちです。
一方で、金額には現れませんが、運用設計を後回しにすると、つまり「いつ、（本当の意味で）何が起きるかわからない」システムを作り出すことになってしまいます。これはエンジニアに大きなストレスを与え、「優秀な人材の流出」を引き起こしますし、何より「障害時に被害が増大、拡大するリスク」などの形で現れてきます。
実はこの記事は、某Fintech企業が580億円分の仮想通貨を流出させた翌日に書いていたりします。といえばご理解いただけるでしょうか。
年金と違い、備えあれば憂いなしとまではいかなくとも最小限に食い止められます。
つたない文章でしたが、最後までお読み頂き、ありがとうございました。