「入門監視」はエンジニアのマストリードだ - S氏はたまにblogを更新してます

f:id:suganoo:20190128003738j:plain

「銀の弾丸はない」この本からこれだけは覚えておいて下さい。

今回は「入門監視」を読んでみました。
Twitterで読んでる人が多く、自分もインフラの仕事をしているんで気になってたんです。

作者: Mike Julian,松浦隼人
出版社/メーカー: オライリージャパン
発売日: 2019/01/17
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

率直な感想として、これはかなり勉強になった本でした。
インフラに関わる人はもうみんな読んだ方がいいと思います。

最初の方からアンチパターンが挙げられています。その後に監視のデザインパターン、ビジネスでの監視、アプリケーションの監視、ネットワークの監視、付録...などと構成されています。

どこを見てもかなり重要な部分なんですけども、冒頭のアンチパターンでこれあるなーと共感したり、一番最後に実践的な監視の観点についての付録が付いてまして、これがとてもいい！本当に良かった本です。読んでない人に対して「マジっすか！"入門監視"まだ読んでないんすか！？パイセン！！」っとイキれるレベルです。

だいたいの構成

だいたいの構成はこんな感じです。

監視のアンチパターン
監視のデザインパターン
アラートの対処
統計学
ビジネスでの監視
アプリケーションの監視
ネットワークの監視
付録

最初の監視のアンチパターンを読むと「あーこれよくやるわー」っと思い当たる節がいくつかありました。

例えば「動いている」とはどういう意味なのか、と別章に書かれててツールやプログラムを作ると完成するまでに疲れてしまい、そもそもどういう状態がちゃんと動いているのか、っとあまりにも単純なことがおろそかになってしまうことがあります。思わず見抜かれているのかと思いました。

感銘を受けたところ抜粋

おお！っと感銘を受けたところを抜粋して見たいと思います。太字は私による編集です。

「役割」の監視ではなく「自分事として」監視しようぜ

P10 1.2 アンチパターン 2 : 役割としての監視

しかし、監視となると問題があります。理解もできないものを監視する仕組みなんて作れるでしょうか？それは難しいでしょう。
　つまり、このやり方はアンチパターンです。監視とは役割ではなくスキルであり、チーム内の全員がある程度のレベルに至っておくべきです。構成管理ツール、あるはデータベースサーバの管理方法に詳しいのは1人だけという状況にはしないのに、監視となると1人でもよいと思ってしまうのはなぜでしょうか。監視とは他の仕組みから孤立した仕組みではなくサービスのパフォーマンスのために重要なのです。
　監視の旅へ進むに当たって、皆が監視について責任を持つことを主張して下さい。

これ作ったことがない若手がテストをやるとかそんなところにも共通してるんじゃないかと思います。そのシステムの大事なところは作った人がよく知ってるはずです。システム監視を他人に任せず皆で責任をもつ、とても当たり前で大事なことです。

そもそも安定したもの作ろうぜ

P14 アンチパターン 4 : 監視を支えにする

注意を要するサービスを運用して、そこに監視をどんどん追加している状態なのに気づいたら、そういったことはやめてサービス自体定して回復力のあるものにすることに時間を使いましょう。

これ自分が担当することになって引き継ぎしたジョブがよくわからんって時によく起こるなーっと思い当たる節があります。引き継ぎの中身がよくわからないから、アラートが起きるたびにその場しのぎの対処をする。やっぱり根本原因は見なきゃダメですよね。

海外拠点があればこんなこともできるね

P45

Follow-the-Sun（太陽を追いかける）ローテーション

Follow-the-Sunローテーション：時差がある国で自国が夜でも海外拠点が昼ならそこに監視を引き継ぎするって方法。
海外拠点がある会社ならそういう方法も思いつきますね。

「障害出たのお前のせいだよなぁ」

P50 3.4 振り返り

　振り返りにはよくない習慣があることに私は気づきました。それは誰かを非難するという文化です。もしミスし問題を覆いさざるを得ないような雰囲気のチームにいるなら、それは非難する文化があると言えるでしょう。
　ミスに対する罰や恥を恐れている人は、それを隠したり軽視するはずです。インシデント発生後の対応が誰かを非難するものになるなら、内部に潜む本当の問題を改善することは絶対にできません。

これな！！そりゃー確かに障害を出したことは悪いけど、ペナルティーがでかいのは萎縮してしまいます。障害理由が自分の修正だった場合は、自分がむちゃくちゃショック受けてるし反省してるよ。っというかミスを責める文化だからミスが生まれやすいんだよ。っと自分の体験談をもとにしてつぶやく。
そういうチームの文化って思い当たることがあるし改めるべきだなと思いました。

マイクロサービスの監視

P105 マイクロサービスアーキテクチャを監視する

分散トレーシング
分散トレーシングの仕組みは単純です。システムに入って来るリクエストに、一意なリクエストIDを「タグ付け」します。このリクエストIDはリクエストに付いて回り、それによってリクエストがどのサービスにアクセスしたか各サービスでどのくらいの時間を過ごしたかが分かります。

マイクロサービスはまだ運用したことないのですが、これはなるほどっと思える対応でした。やってる人は当たり前のことなのかな。

本当に監視するものは？

P186 監視エージェントが収集するメトリクス

もちろん、OSのメトリクスの異常値は、実際にはなにかの結果でしかありません。筆者は監視を「システムに対する高速健康診断」というたとえをすることがあります。例えば、健康診断で肝機能のγ-GPTの値が悪かったとしましょう。個人差はあるのであくまで仮定ですが、これはお酒の飲み過ぎが原因でしょう。この場合本来監視すべきなのは酒量、γ-GTPがOSのメトリクスに相当します。つまり、システムでも同様に直接の原因でありコントロール可能な数値を本来は監視すべきなのです。

これ最後の方に出てきたんですが、すごく納得してしまった例え話でした。でもとはいえメトリクスを取得することは無駄ではないし、直接の原因があったとしてそこから例えばOSのメモリが枯渇してしまいメモリリークに繋がったとか、直接原因から細かな原因まで追求できるから無駄ではないでしょう。重点を置くのはそこじゃないよね根本原因を監視しましょうねというところ。