書評「入門 監視」
「入門 監視」についての書評です。
あくまで私が読んでの感想とエッセンスを抽出しただけなので、ストーリーに沿った理解がしたい場合は、書籍を購入することをオススメします。
まずは筆者の性質を理解しておく必要があります。
ざっくり印象で記載すると「アンチNagios」「SaaS支持者」でした。
Nagiosについては良い点悪い点あるけれども、管理者が機能をそのまま利用するとよくない結果がまっているというニュアンスでした。
また、SaaSについては、できるだけオンプレではなくサービスを活用した方がアジリティが高いよ、というスタンス。
必要があれば構築すれば良いよね、という考え方でした。
まずはアンチパターンから。
「銀の弾丸はない」
それ一つでなんでもできる監視ツールはないということです。
なんとなく気づいている方も多いと思います。
NW、MW、APP、様々なレイヤの監視を統合するには、複数のツールを組み合わせる必要がある、といった感じですね。
そもそも「ツール先行」というケースも多いと思います。
知っている会社だから、ナレッジが多いから、安いから、流行りだから・・・。
そうではなくて、まずは何がしたいか、なんで監視したいか、ここが命題になりますよね。監視だけじゃないですが。
Why?からはじめて、ようやくそこにフィットするツールがでてくる、選定ができる状態になります。
「監視エージェントを入れることを恐れないこと」
実にその通り。
エージェントレスで詳細なメトリクスが取れるか？
→答えはNo
エージェントを入れる手間はかかるというのはあるけど、システムへの影響はほぼないと捉えて良いですね。
監視設定したからシステムのレスポンスが悪化したなんて話はそんなに聞きませんし。
「カルト・カーゴ科学」
慣習的に行っている監視設定やツールの採用はないかな？という問い。
よく見ませんか？
「とりあえずアプリログは全部出してあとで削減していこう（放置）」
「よく出力するけど影響ないので無視しよう」
CPU使用率が90%超えてアラームが出るんだけど、10分後には低下するので無視するようなオペレーション。ありませんか？
アプリケーション（つまりはユーザの利用）に影響がないなら不要な監視になりますね。
影響があるのであっても、そこまで詳細に監視する必要があるのかは要検討です。
特化ツールは自作する。
かゆいところに手か届かない。細かい監視設定や表示を微妙に変えたい。
PythonやVBなんかで自作できますね。
ハッカブルな余地があるシステムやサービスを使うと、細かいすきまを埋められると思います。
ダッシュボード
意味もわからないダッシュボードが表示されていないですか？
何十システムもの監視アラームやグラフが表示される画面。
人間の目は残念ながら二つしかありません。
自システムの情報だけがシンプルに表示されるのが一番目的にかなってますよね。
アラートの意味は？
単にエラーを通知するだけではないということ。
アラートは出ておしまいじゃない。
出力をもって人間に何かアクションを起こさせたいはず。
ユーザ影響はあるのか、そこまで緊急ではないのか。
その辺りがポイントになってきます。
次にデザインパターン！
コスト計算をしよう
SaaSを使うのもありですね。
設計・構築にかかる人件費、教育、メンテナンス費用、このへんを考慮するとSaaSが良いのは明白ですということ。
SaaSを使えないシーンは、SaaSでは事足りないくらいシステムが成長したときくらいです。
要するに、SaaSアレルギーに論理性などはないので、コストメリットを中心に見ていけば良いということでした。理にかなってますね。
アラート通知
メールで通知する意味はない。受信箱がいっぱいになる。
これはもう周知の事実でしょう。でもやっているとこもまだ多いかもしれません。
アラートには手順書をつけて標準化するべき。これもベター。
手順書を探す手間や間違える手間もアラートの数から見るとバカになりませんしね。
シンプルな手順ならそもそも自動化して自動復旧、失敗したときだけアラートを出せば良い。
運用サイドでやるのか、システム改修としてやるのかは記載されていないけれど、ここもコストがかからず安定するポイントでやると良いと思います。
アラートが多いとオオカミ少年になるし疲れる。
ありがちなケースで、毎日数百件のアラートが出るのでレスポンスが遅いといったこと。
これは運用が破綻しているということ以上に、メンバーのメンタル的にもよくないですよね。
自動化できないか？アクションが不要なアラートはないか？
毎月のPDCAでチェックをかけていくのも良いかと思いました。
削減対象を洗い出し、具体的なアクションに落とし込んでいくことで対処できるでしょう。
オンコール
ほんとうに重要な問題。
夜中の3時、旅行中、デート中にコールされると最悪ですよね。
簡単な障害ならまだしも、大きな問題ならなおさらです。
淡々とオンコールを受けるのが良いと誤認されることもありますが、実はそうではないと思います。
オンコールが多ければ怒っていいのです。
その怒りを持って、不要アラートの棚卸しや改善、自動化へエネルギーを向けることができたら、不要なコールは減るはずです。
もちろんインセンティブも。
グローバルに対応する方法で、監視のフォローザサンという方法もあります。
世界でサポートすることで、営業時間帯のみで対応が可能です。
ただし、接点が地理的にも時間的にも薄くなるので、コミュニケーションのオーバーヘッドがとても大きくなってしまいがち。
うまい方法でカバーできれば良いはずです。
ビジネス指標となるKPIデータ
利用者数、新規登録数、アクティブユーザ数などを取ることで、ビジネス目線でサービスの可視化ができます。
ここではシステムというよりはサービス観点。
これができればマネージャーや経営へ、システムステータスのレポートが簡単にできる。
これ意外と重要だと思います。
コミュニケーションも大切
問題点を見つけるために、プロダクトマネージャやソフトウェアエンジニアチームのマネージャと話すこと。雑談レベルで。ここから課題が見つかることも多いです。
実はメンバーが日々思っていることの中に、課題そのものや片鱗があるのかもしれませんしね。
フロントエンド監視
サイトのパフォーマンス、レスポンス速度はビジネスに直結します。
ページのロード時間、JavaScriptのロード時間を監視することがポイント。
デプロイの監視もすると問題が発生したときの原因調査が早くなるかもしれないです。
だいたいのインシデントは、オペレーションミスもしくはリリースミスだという説もあるので、デプロイポイントを明確にするのは良い気がします。
サーバ監視
低レイヤの監視（CPU、メモリ、ディスク）はあまり意味がない。
人間でいう「体重」のようなもので、重すぎること自体が何か病気や怪我になるわけではないけど、それを誘発する原因にはなりうるのかなと思いました。
ネットワーク監視
監視方法はSNMPしかない。複雑なNWを監視するのにはスキルが必要。
セキュリティ監視
詳しくやるのでなければ、手堅く始める方法はある。
まとめ
目的をはっきりさせよう
なんのために監視するのか？
たとえばWebページの「表示」なのか「レスポンス」なのか「画面表示内容」なのか。
それによってどこまで監視設定すべきかが変わってくると思います。
まずはビジネス要件から考えて、「何のために監視するんだっけ？」を常に持っておけば、おかしなパターンに陥らずにすみそうです。
多くの運用が、ツール先行や設定重視になってしまい、本来の目的を忘れてしまっています。
監視ってどんな役割？
監視について、いろいろな見方があると思いますが、ITILでいうところのイベント管理の部分になっています。
イベント管理とは、全てのITインフラから発生するイベントを監視し、運用が通常通りに行われていることを確認、そして異常なイベントが検知された際にはインシデント管理などの他管理プロセスへエスカレーションをすることです。
ようするに、正常・異常の判別をするだけなのです。
（一部インシデントのワークアラウンドまで含みますが）
異常アラートをどう収集するか、どう判別するか、アラートが出た際にどうアクションするか、このあたりをデザインしていくのが重要ということですね。
監視の重要性
システム運用の世界では中心的な役割を果たす「監視」ですが、DevOps的な世界や開発・保守にも関わりが深くなってきている今、Overviewとして読んでおくのも良いかもしれません。