オブザーバビリティ・エンジニアリング を読みました。1ヶ月かけて10時間程度で読みました。
この本を読むと、オブザーバビリティとは何か？という問いに対する心構え、メンタルモデルが形成されると思いました。
特に手を動かして何か検証したりはしませんでしたが、こういうシステムって欲しいよなとか、これを実現するためにはどういうのが必要か？といった点を考えるきっかけが得られたと思います。

この本を読む前の状態

• Observabilityとは、メトリクス・ログ・トレース
  • 可観測性
  • 外から状態を推測できるイメージ
• この本を読むモチベーション
  • Observability系の本を読むかあと思っているので、読み切ることで要素を回収しておきたい
  • 入門 Prometheusと違って広い範囲なので、メトリクス以外(ログ、トレース)の基礎を抑えたい

この本を読んだ後の状態

• 思ったより文化に寄っていた
  • メトリクス・ログ・トレースということを知るのと、実務で適用する間にちょうど良いと感じる本だった
    • どういう心構えで実務でのObservabilityに向き合えば良いか？が分かりそう
  • 事前に考えていたObservabilityのイメージは間違ってはないが浅かった。理解が深まった。
• 意外な点として、CI/CDのObservabilityの話が面白かった
  • てっきり本番環境のObservabilityに終始するかと思いきや、CI/CD環境への言及が後半そこそこあった
• home-k8sへの導入や、実務でのObservabilityへの向き合い方を考えるようになった
  • 分散システムのような予測不能な障害が起こりうるシステムを扱う場合には、Observabilityは必須だと感じるようになった
  • ビジネスロジックを追うためのカスタム属性について興味が出てきた
    • SLOの章に書いてあるように、Observabilityはユーザー体験をよく反映する。ユーザー体験に関する情報を得て、それをもとにシステムのやばさを評価したいと思うようになった
• 本を読むモチベは部分的に達成された
  • 要素回収はOK
  • ログ、トレースというより一段抽象度の高いObservabilityの基礎を抑えることができた

さらなる興味

• いくつかの疑問がある
  • 漸近的リリースを途中で止めるタイミングを自動判断するシステムに必要なものは何か？予測可能なものとしてどういうケースが挙げられるだろうか。そのために必要なObservabilityはなんだろうか。
  • デプロイ後に、事前に予想したリソース使用量の変化と異なることを検出するために必要なものは何か？どういう変化が起きたか、Feature flagの有効化の後の場合も考えてレポートを出せるだろうか。
  • あるPRが原因で本番障害が起こったとする。この時、このPRを特定するために必要なものは何か？CIのObservabilityとの連動は？何ヶ月か経って発生、みたいな場合にはどうしたらいいだろうか？
• 集計のアルゴリズムを学びたい
  • t-digest
  • HyperLogLog
• 試したい
  • クエリ結果を早く返す工夫、サンプリング手法
  • これらを愚直の場合と比較してトレードオフを整理したい

その他感想

• 直観に頼ったデバッグは分散システムで通用しない。分散システムの本番環境は見たこともない原因の障害が起こり、再現性がない。
  • これつらいと思った
• 本番環境はガラスの城ではない。本番環境でしか起こらないことが多々あるので、Observabilityを上げよう
  • これ分かる
• BIツールとの比較が面白かった
  • Observabilityより正確さを取り、スケールしにくい・柔軟なクエリが難しいのがBIツールという印象
• 先行指標と遅行指標で、遅行指標はObservabilityが重要になりそうだと感じた
  • 先行指標は変化を入れてすぐに結果が出るので目に見えて因果を体感しやすい
  • 遅行指標は何が効いたのか分からなくなりがち。そこでパイプラインのどこにどう影響したのかというObservabilityが重要になりそう。