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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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