『入門 監視』を読んだ

個人的に一番評価できるポイントは、そのボリュームでした。

この本は 200 ページほどしかなく、各章も 10~20 ページ程度なので、スプリント方式で勢いで読めました。

監視に興味があれば読むと良いでしょう。そこまで興味はないが気になる人は、読んだ人から話を聞くと良いと思います。

全部が全部必要な情報ではないので（例えば 9 章の SNMP を扱う人は少ないと思う）、一旦ザーッと流し読みして、気になったところを後で読み返したり、より専門的な本を読むとかすると良いかも。

本から少し脱線しますが一点だけ。

P10「1.2 アンチパターン２：役割としての監視」の中で “オペレーションチームだけでなく全員が本番環境に責任を持つ” という話が出ており、非常にもっともですが、そのような文化を作ることはなかなか難しいと思います。

うちの会社ではどのチームもこのような Slack のリマインダーを流しており、メトリクスを毎日見る文化が根付いています。

Continuous Watching
※ Heroku 使っている都合もあって、URL が多くなってしまっている。集約させたい。

アラートが出る以前の普段と違うメトリクスの変化や、アラートに関連したメトリクスの把握、そもそもどんなメトリクスを収集しているかの学習にもなるので、オススメです。

実際、全員がメトリクスを見ているわけではありませんが、「毎日何を見ているのか」という共有は大事だと思っていて、情報の非対称性が少しは解消されると思います。

しばらくスプリントミーティングなどで共有の場を設定し、それと並行してこのようなリマインダーを仕掛けると習慣が根付きやすいかもしれません。

以下、読書メモです。

1章監視のアンチパターン

振る舞いを監視することが大事。OS のメトリクスの監視はプライベートメソッドのテストとよく似ていると思った。

※ レガシーコードや特別な理由を除いて「プライベートメソッドのテストは書かない」ということは、2013 年に決着がついている。

“アラートにメールを使うのをやめよう”
それな。

今は全て Slack に送ってしまっているので、なんとかしたい。

ローテーションなあ…。365 日全員で対応している状況。幸いにもそこまでアラートは多くないが、バーンアウトの危険性はある。

頻度の多いアラートで、調査に着手し始めたとかなら、閾値を下げるなど検討したほうが良いと思った。

P35
・現場指揮官
・スクライブ（書記官）
・コミュニケーションの調整役
・SME（実際にインシデント対応する人）

振り返り（postmortem）大事。会社では大きなインシデントのあとに振り返る文化が根付きつつある。

たったの 10 ページにまとまっており、非常に良かった。

Redash での可視化やアラートの設定など、もう少し詰めようと思った。