『オブザーバビリティ・エンジニアリング』という本を見つけて「オブザーバビリティとはなんだ」と思ったので、読みました。
この記事は株式会社要 cavacanチーム Advent Calendar 2024 12日目の記事です。
オブザーバビリティ・エンジニアリング
読んだ感想ですが、「オブザーバビリティ」という言葉に聞き覚えがなくても、本番環境の対応をしたことがあるなら「なるほど～～」と思うことが間違いなしの内容でした。
下記の見出しを読んで興味のあるトピックがあれば、そこの章から読み始めるというのもよいでしょう。
本番環境で不具合おきたので原因調査お願いします
…と連絡が来たのでとりあえずダッシュボードを開いてみると、見覚えのあるパターンでグラフが異常を示している。「この雰囲気はたぶんあの障害が起こっている」「あの機能が悪さしてるかな」とピンと来ました。
これ、やっているひとおおいと思います。経験のあるエンジニアほどよくやっているいわば「障害占い」です。
本来、原因の追求としてやらなければならないのは何のバイアスも無い事実（データ）に基づく調査です。占いでは既知の問題を当てることは出来るかもしれませんが未知の問題には対処できません。
原因調査をするべきなのはわかっていても、調査がしにくいアプリケーションを作ってしまった／担当になってしまった場合、当たろうが外れようが占うしかありませんね。これはオブザーバビリティの低いアプリケーションです。
逆に、調査がしやすいアプリケーションというのはログやリクエストの情報の探索性が高いということになります。これはオブザーバビリティが高いアプリケーションということになります。
TDDで不足するものとは
開発段階からオブザーバビリティ向上に取り組むうえで、改めてTDD（テスト駆動開発）の良いところ・悪いところを確認します。
DevOps・SRE
組織単位でオブザーバビリティを考えたときに、そもそもオブザーバビリティが必要となった要因としてDevOpsやSREの思想や動きがあったことがわかります。
この書籍のタイトルにはそのへんの単語が入っていませんが、実はよく触れられています。
まとめ
この本では具体的にどのようなアプローチを取ればアプリケーションのオブザーバビリティを高めることが出来るかが説明されています。
実際のアプリケーションに今すぐ取り入れたい、というせっかちな人はこの本があればとりあえず導入できるので、入手すると良いと思います。
次回のアドベントカレンダーは @matsujunjun さんの「初めての自動テスト ―Webシステムのための自動テスト基礎」の書評記事です。