動いてないと利用者に言われるようでは失格

サーバーやDBなど構築したシステムが正常に動作していることを保証することは、SLA上必要になります。

SLAとは、システムのサービス水準を示すもので、サービスの品質保証がどこまで行われるかという基準です。

運用というのは、このSLAを守るために日々頑張るということなのです。

そのために、システムが問題なく動いていることを常に監視しておく必要があります。

監視が行き届かなくて、利用したお客様から「おかしいぞ」と通知されるまで気づかないようではシステムとしては失格といわれても仕方がありません。

そのためにも、システムを自動で監視する仕組みが必要です。

監視をして異常が発見されたら、メールで通知したり、重要なものは主たる担当者の携帯電話に直接送ることで対応を行います。

障害が自動で修復できるならいいのですが、そうならないことがほとんどですので、最後は人が対処せざるを得ません。

「人」が頼りになるわけですが、それ以前のところをどれだけシステム的に自動で行うかが大事になります。

すべてのことを自動化することはできないので、人が定期的に見に行って監視することもありますが、それを毎日や毎時の手順として実施することは結構たいへんなのです。

そのためにも、監視システムを上手に使って自動で検知する仕組みを入れることがシステムの安定運用には欠かせません。

監視によって日々の運用を支える

提供しているサービスが問題なく動作していることを保証していくのが日々の運用作業になります。

それを支える重要な役割が監視にあります。監視はつまりは「見張り」の役目です。

監視に引っかかると、保守の担当者にメールで通知されます。

保守の担当者は、SLAの時間中はそのメールを常に見ておいて、一つ一つの通知が問題あるのかないのか、調べて対応することが必要になります。

通知されると言っても、通知の内容にはレベルがあります。

• 今すぐ対応が必要なもの
• なるべく速く対応が必要なもの
• 単なる警告で迅速な判断が求められないもの

といった大きな区分けがされます。

これらをしっかりと設計段階から計画して監視できる仕組みを作り込んでおくことが必要です。

インフラはメモリやディスクの空き容量など

サーバーの場合は、いろいろな判断基準がありますが、メモリの使用量が一定の割合を超えている、ディスクの空き容量が一定割合を下回ったなどが判断の代表例です。

メモリの使用量は、たとえば80%を越えたら情報として通知し、90%を越えたらアラートを上げるなどのように設定します。

ある処理を行うと急激にメモリを食う、ディスクを消費するような場合、その瞬間的な値を考慮して境界値を設定していくことになります。

これらはそのサーバーにどれだけのサービスを搭載し動作させるかにも依存します。

最初は想定値で設定し、運用しながら適正値に変更していきます。

実質的に問題のない通知の頻度が多いなら、監視の基準を下げてもいいでしょうし、通知されたときに大至急の対処が必要なら、通知の判定を厳しい方に見直すことも必要になるのです。

アプリケーションはログ出力が大事

インフラ的には監視内容が共通化されていたりあらかじめ準備されているもので事足りるのですが、個別のアプリケーションの監視は機能ごとに作り込んでいく必要があります。

そのとき監視の起点になるのがアプリケーションが出力するログです。

たとえばバッチのログであれば、処理を開始した、バッチのデータの事前検証をした、処理を開始した、どこにどんなエラーが発生した、などを出力していきます。

その際に、監視システムでピックアップして通知するためのキーワードなどを仕込むわけです。

単なる情報(Information)なのか、注意が必要な警告(Warning)なのか、対策が必要なエラー(Error)なのかそういった分類をするのです。

そういった設計をすることで、監視機能での検知が可能になるのです。

単なるログ出力ですが、そのログを情報の起点として障害通知につなげるので、その設計はとても大事なのです。

### 「運用」とは何か？

「運用」って結構曖昧なことばなのですが、

**「運用」とは、Webサービスなどが日々問題なく動作するためにシステムの異常な状態にならないようにしていくことです。**

Webサービスなど、一旦動かしはじめたら定期メンテナンスのようなタイミングが来るまで決して止めることはありません。

そのくらいずっと動かし続けるものです。

ところが、ずっと同じように動作し続けてくれるのであれば、放っておいても問題ないのですが、ことはそんなに簡単ではありません。

同じように動作して欲しいのに、ときどきエラーで一部のデータが不正になったり、処理の途中で中断されたりすることが起こるのです。

また、**すべてを自動化することはできませんので、一部の作業を手作業で実施するようにすることもあります。**

Webサービスはユーザー向けに提供しますが、内部的にも同じデータを利用して処理を行ったりお客様の要望に対応したりするのです。

そうしたときに、システムの間違いや人為的ミスなど想定外のことが起こります。

そういった日常の作業をしたり、障害に対する対応をしたりするのが「運用」というものです。

この運用はシステムの稼働前にしっかり設計しておくことが大事なのです。

### 運用設計への要求

運用設計とはサービスが問題なく動作するために実施すべきことですので、サービスがどのように実現されるかが決まっていることが必要です。

ですので、**開発の工程でいうと、機能仕様が決まって、設計段階に入る頃が妥当です。**

たとえば、毎日あるデータを使ってDBを更新しないといけないとします。

ところが、この更新を自動化するには手間がかかるので、簡単なスクリプトを作って簡略化はするけれども完全な自動化まではできないとします。

こういうとき、これを「運用」で実施しようとプロジェクトで決定されるわけです。

運用でやるということは、すなわち人手でやるということです。

システム化できないから、人手でカバーして正常に動くようにしていこうというわけです。

完全な自動化ができない以上、運用の存在は欠かせません。

**システムとしては、何をシステム化し何を運用で行うか、そういったことを一つ一つ決めていくのです。**

### 運用に求める理由

運用でやろうと決めるとき、その条件は何でしょうか？

明確な基準を決めることは難しいと思います。

**システムの都合やプロジェクトの予算や納期などに影響されることがあります。**

運用でやるということは、何かしら人手による作業が行われることになります。

本来手作業でやることは少ない方がいいです。

人手でやれば、どんなに手順をきちんとしても間違えてしまうこともあるからです。

ですから、**自動化してしまうに越したことはないですが、自動化するにはその機能を開発することが必要ですが、予算が限られていてすべてのことを自動化することができないこともあります。**

また、どうやっても自動化できない作業もあります。

それ以外にも、サービスの提供を開始してから、日々実施しなければならない作業に気づき、なんとか運用でやりくりすることもあります。

### 運用に任せすぎるツケ

自動化できなかったことは運用に任せてしまおう、という考え方になるかもしれませんが、運用に任せたらすべて解決するわけじゃありません。

運用に回したことで後でツケとして回ってくることもあります。

それは、
・**運用コストが高くなる**
・**運用のミスがシステムに影響を与える**
といったことが起こりうるからです。

自動化できずに運用に回してしまえば、運用の作業が増えるので、仮に今1人で実施していることができなくなってしまえば、運用の人数を2人に増やさないといけないのです。

1人の運用で回っているうちはいいですが、2人に増やせば当たり前ながら、運用費が2倍になるわけです。

運用に任すというのはコスト負担が増えるのです。

しかも、改善しない限り毎月ずっとお金がかかり続けることになるのです。

### 運用のミスが大きなロスに

もう一つは、運用を人手で実施することによる間違いの発生です。

たとえば、毎日DBから不要なデータをクリーンアップする運用があったとき、手順は決められているけれども、端末の操作ミスで本来消すべきでない
データまでクリーンアップしたとします。

そうすると、消してしまったデータを元に戻さないといけないのです。

**元に戻す作業は定型化されていませんから、どうやって元に戻すかを考え、テストしそして実施しないといけないのです。**

**それは実はとても大きな損失になります。**

その間、本来やるべき運用の作業ができなくなってしまうからです。

システム的にも障害が発生した状態となりお客様に迷惑をかけたりすることにもつながりかねないのです。

こう考えると、安易に「システム化するのがたいへんだから、運用でやることにしよう！」などと軽い判断はなかなかしてはいけないのです。