今回は「運用監視」について、まとめてみる。研修を通じて「運用監視」をきちんと理解してほしい、という声がきっかけだ。
ここでいう運用監視というのは、組織が事業・サービス向けに構築した情報システムの運用監視のこと。開発フェーズのあとの、運用フェーズのことだ。ITSSというスキルセットでITエンジニアのスキルを語っていた頃の話だったり、ITILで定義されているような知識体系の話。もちろん、運用監視に関わろうというヒトにはそういう話も必要にはなってくるけど、今回は入門編。「へー、運用監視って大事なんだね。なんとなくわかった」と言ってもらえるが目標。
自分が初めて運用の部門に配属になった大昔、（その前まで属していた開発フェーズの）その後の工程くらいに思っていた。閉域網の中で情報システムを取り扱っていたし、ほとんどがオンプレでのシステム構築だから、開発に費用も期間もかかるし、それなりに大切に扱うものだともコンセンサスがあった。
今はどうだ。クラウドやSaaSを使うことが前提になり、システムは閉域網ありきで語ることができなくなった。穿った言い方をすれば、MSがOffice365になんかにするから、Officeから抜けられない企業は（Direct Accessを使うとはいえ）一定のポートを外部向けにオープンにすることが前提となった。またマルウェアを介した感染と合わせて、サイバーセキュリティに完全なネットワーク設計を行っても境界で防御なんてできなくなった。
で、最初に戻って、運用監視（の業務の意義）ってなんですか、の答えですが、「事業・サービスの安定稼働のために定期的に必要な確認を行うのが監視、監視の結果でリスク等を観測した場合や、予めカレンダーで定めて、必要な対処を行うのが運用」である。
ここで、高可用性を担保するための、システムの冗長化にも触れる。
システムは故障する。故障に際して、いちいち事業・サービスをとめられないから、単一な障害で止まらないような仕掛けを作る。例えばN+1のコンピュータを同時に動かして、何かが止まったら動いているコンピュータに処理を引き継いで、サービスを止めない仕組み、これが冗長化。
そもそも運用監視の目的は事業・サービスを安定して提供することなので、単純な故障が起きても大騒ぎする必要はない。事業・サービスが使えていればいいのだ。
なので、社会インフラ事業を提供する会社、通信や電気、水道サービスを提供する会社の冗長化はそれなりに堅牢に設計されているし、PoCのようなサービスに堅牢な冗長性は必要はない。冗長化ができていれば、故障部位が自動的に切り離されたり、縮退運転で安全にサービスを運用できれば良い。
で、またまた最初に戻る。監視というのは、サービスの安定提供のために何らかの対処が必要な状態になっていないかを監視すること。運用というのは、監視またはタイムスケジュールに基づき、必要な対処なり、オペレーションをすることが運用だ。セキュリティリスクも、事業やサービスを止めるかもしれない１つのカテゴリーであって、目的ではない。
例えばOffice365の運用監視をしていれば、その目的はOffice365の提供だし、Office 365の機能を１つの部品と見立てて提供しているAサービスの監視についての目的は、Aサービスが安定提供できることである。
もちろん、不幸にしてAサービスの全部を止めてしまうような障害もあり得る。例えば、複数系統化された電源供給が全面的に相当期間止まってしまった場合、システムは稼働できず、Aサービスも停止する。その際のBCP（Business Continuity Plan)は並行して考えておく。（けど、今回は長くなるので、そちらの深掘りはやめておく）
Office365を監視しているヒト（多分、MSから委託されたヒトだと思いますが）や、Aサービスを監視しているヒトが、同じイベントを見つけることもある。例えばOffice365自体の障害であれば、Office365だけでなく、それをベースにしたサービスも止まる。）この点を気にして、複数のヒトが同じものを監視するのは無駄との考え方もある。ただ、最近はこの辺の監視はほぼ無人化するから、センサーのそれぞれが監視することは、ダブルチェックにすればいいだけで、監視の棲み分けまでは気にしない。この場合はAサービスはAサービスの視点で監視するし、Office365の障害とわかった時点で、Office365の復旧までどう凌ぐかが、Aサービスの運用監視の仕事である。他方、Office365の監視のヒトは、Office365をどう復旧できないといけないかに奮闘しないといけない。見方を変えれば、両者は全然別物なのだ。
