運用監視に必要な知識はOS、コマンド、そしてプログラミング～ゼロからの運用監視設計（後編）。July Tech Festa 2016

運用監視の自動化は、複雑化するアプリケーションやサービスに対して効率的かつ確実な運用監視を実現する上で、またコスト削減の意味でも重要な要素になってきています。しかし運用監視の自動化は、どのように考えて実現していけばいいのでしょうか。

（本記事は「正しく運用されているかを評価するのが監視である～ゼロからの運用監視設計（前編）。July Tech Festa 2016」の続きです。）

ゼロからの監視設計

前佛雅人氏。ここでようやく、ゼロからの監視設計の話です。

監視設計をざっくりわけると、こんな風に定義できると思います。

ひとつはサービスレベルの定義、もうひとつは非機能要件としてのシステム監視ですね。こういうことは以外と職場でも学校でも教えてくれなかったことです。

なぜかというと、だいたい担当部署によってみているレイヤが違うわけです。物理層を見ているところ、ネットワーク層、あるいはインフラは外部の事業者に運用監視をまかせているところもあると思います。

Webページが表示されないとかレスポンスが遅いとか、そういうサービスレベルの監視、ここは欠かせません。

しかし、ここでは非機能要件と書きましたが、ここが忘れられがちだと思います。

システムがつねに正しく動き続けているかどうかを見る、なにかあったときの目として、プロセス監視やシステムリソースやネットワークやハードウェアといったあたりの監視が欠かせないと思います。

チームごとに別々の監視画面を見ている、というのもよくあります。ネットワークチームはスイッチだけ、サーバの監視ではCPUとメモリだけ、などです。

これらはまとめて見た方がいいと思います。というのも、ある日突然、原因不明でトラフィックが増えたりロードアベレージがあがったとしたら、なにか原因があるはずです。そしてそれが最終的にサービスレベルに影響するはずです。

しかしシステムレベルで監視をすることによってサービスレベルに影響しないよう、未然に防止することに役立てることができます。

知識と経験について

例えば、とある会社のWebサイトを構築しようと考えたとしましょう。

いまだとWebサイトをDockerを使って構築したいというニーズがあったとします。でもDockerのWebサイトってどうやって運用するのか、どうやって監視するのか、分かりませんよね。

でも基本は変わらないと思います。Webサイトであれば80番ポートの応答速度を監視するとか。

Dockerがどうやって動いているのかも気になると思いますが、これまでと同様に非機能要件、システムリソースを監視していればいいでしょう。Dockerになっても、監視に対する考え方はあまり変わらないと思います。

こういう風に考えるときに必要になるのが、知識と経験です。

監視をするにあたって必要な知識は、基本的にはこの3つ。OS、基本コマンド、プログラミング言語だと思います。

Linuxであればカーネルの主要な機能を調べておくといいと思いますし、監視ツールで見ているシステムリソースはたいてい何らかのコマンドを叩いたりしているので、どうやってこの項目を見てるのか、という知識もあったほうがいいですね。

もうひとつ、私が強調したいのは、自由に扱えるプログラミング言語がなにかひとつあったほうがいい、ということです。そうすれば、監視ツールにない項目でもプログラムを組んで監視できるようになります。

でも知識だけではだめだと思いませんか？

私としては経験を得るのための提案として、IT系のエンジニアならば、仮にもWebサーバ系ならば、自分で何らかのWebサーバをひとつくらい運用しませんか？

最近だとクラウドで簡単にサーバを作ったり壊したりできるので、Webサーバをずっと持っている人は多くないかもしれませんが、やっぱり自分で自由に遊べるサーバを持っていた方がいいと思います。

例えばタクシー運転手で、勤務時間内しかクルマを運転しない、という人と、趣味としても運転をしています、という人がいたら、どちらが信用できますかね、というレベルの話です。

できればインターネット上にサーバを立てるとこわいです。日々アタックもありますし、いろんな事故に巻き込まれたりすることもあります。でもそういう経験をすることで、いろいろ仕事に役立つと思います。

なぜ私たちは失敗するのか

自動化の前に、なぜ私たちは失敗するのか、なぜ失敗して報告書を書かなくてはいけないのか（会場笑）、というのに触れていこうと思います。

運用における失敗、というのがあると思います

やっちゃいけないと分かっていても、やってしまうことがあると思います。どうしてこうなったか。

（スライドで会場爆笑）

ひとつはシステム稼働前の不適切な運用フローや監視設定漏れ、といったこともあると思いますが、これらは事前にしっかり設計するなどで対策可能な場合が多いと思います。

一方、不可避なのは保守時の作業ミス、異常時のリカバリ失敗など。これらはどんなに頑張っても不可避だと思います。なぜ不可避かといえば、基本的には人的問題だと考えています。

最近のWebサービスなどは24時間365日に動いているのが当たり前で、サービスがリリースされた後のコードの変更やアプリの差し替えがよくあるようになりました。

すると運用中に人の操作が介在することも多くなってきていて、そこでの人的ミスはたぶん、人がダブるチェックしても回避できないと思います。

そうしたことは私たちの業界だけに起きているのではありません。これはラムッセンのSRKモデルと呼ばれるものですが、初心者は余裕がない状態で間違って事故を起こすパターンが多く、慣れてくるとマニュアル通りに事故を起こすと。頭で走っていても経験が足りないと、状況判断を間違えて事故を起こすことが多いそうです。

そして熟練者は思い込みでコマンドを実行してしまうなどで間違うと。なので基本的に人が介在する場合にはミスが避けられないということです。

対策としては、事故が起きても大丈夫なように設計するのは当然ですが、でも手作業を排除することも重要です。

そのために自動化ツールを導入しましょうと考えるのは、自動化ツールの導入が目的になってしまいがちです。

私がまずオススメしたいのは、人によるダブルチェックを信用しないというところから始めることです。人がやったことをダブるチェックするのではなく、人がやったことをテストなどを通して自動チェックするのが効果的だと思います。

例えば運用や監視でも、人が監視画面で設定を見てOKにするのではなく、そのあと何らかのツールが走って、正常であるという状態を監視し続ける、といった方法がいいのではないでしょうか。

アプリケーションやサービスの内容は日々変化する可能性があります。ということは、設定項目も変わっていく可能性があります。するといつの間にか設定ミスをして設定がずれてしまう、といったこともあると思うので、テストを通じた監視の方がいいのかなと思います。

このあたりは、知見がある人の話も是非聞きたいと思います。

知識や経験を活かすためにどうするか

知識や経験を活かすためにどうするか。

個人であれば経験を積むしかない。そして効率化を目指すのがポイントかなと思います。

組織においては、なぜこのような監視設計をしているのか、ドキュメントを残すのがいいと思いますし、可能であれば運用でもテストをすることを当たり前にしていくのがいいと思います。

そのために必要なのがプログラミングです。

単純に知識があるだけでも、経験があるだけでも厳しいので、知識と経験を両方活かす手段を考えなければならないと思います。

というわけでまとめです。

ゼロから関し設計できますか？ については、サービス側からドリルダウンして考えていけば解決すると思います。

ただし人が介在する以上、失敗をすることは不可避なので、手作業を減らして自動化していく必要があると思います。

そして自動化の推進とは、自動化ツールを導入するためではなく、知識と経験を活かすためのきっかけのひとつとして考えていくことが大事だと思います。

会場からの質問

会場　バックボーンのネットワークなどの切り替えも複雑になってきていて、それらを含めてサービスを継続するための監視も複雑になっていくと思うが、今後そのあたりはどうなっていくのでしょうか？

前佛氏 監視ツールの概念も今後変わっていくと思います。これまでは人の運用を支えるためのツールでしたが、今後はデータを集めて解析できるツール。膨大なデータを集めて人では分からないような分析をして予測をしたりチューニングをしてくれるようになるのかな、と思います。

会場 運用担当と開発者のスキルのギャップを埋めたいなと思っていますが、そこを埋めていくためにはどうすればいいでしょうか。

前佛氏 現実にはそれぞれが所属する組織が違っていると両者のスキルの差を埋めていくのは難しいかもしれませんが、そのままにしておくと他社に負けていくということになると思います。どうしようもなくなる前に、自動化などを取り入れて組織の意識を変えていくことが必要ではないかと思います。