概要
「オブザーバビリティ・エンジニアリング」を読みました。 感想を書きます。
前提
目的
- ４月〜６月の OKR で DevOps・CI/CD が目標の 1 つだったので、個人的な課題図書の 1 つだった
- 今月は「入門監視」「オブザーバビリティ・エンジニアリング」「サイトリライアビリティエンジニリング」を読もうと考えていた
- 個人的な印象に、新しい書籍の方が関連する過去の書籍よりもとっつきやすい印象があるため、先述の書籍の中で最も出版日が最近の「オブザーバビリティ・エンジニアリング」を読むことにした
- 普段メトリクスを監視する際には経験則を用いた定性的な分析で行っていたので、定量的な方法を知りたかった
事前知識
DevOps 関連では下記の書籍を読んでいました。
また、下記の書籍も並行して読んでいます。
読了時間
2 回読みを実践してみました。
最初に毎日 30 分で 5 日間かけて流し読みをして 1 周しました。
その 2 週間後に毎日 1. 5 時間ほどかけて 1 週間程度で読み切りました。
2 回目読む際には書籍の緩急を把握しながら読めたので、前よりも理解が進んだと思いました。
ただし、前提知識が不足している分は、理解は浅い状態です。
感想
本書で、オブザーバビリティそのものと、DevOps・SRE にどのように活用され、達成されるのかについて知ることができました。
DevOps・SRE について考える機会が多かったので、アプローチの 1 つとして参考になりました。
本書が解説したオブザーバビリティの定義についての抜粋、それらに対応する自身の業務の課題と実践するべきこと、本書を読んでも実践が難しいと思った内容について記述します。
オブザーバビリティの定義について（主に抜粋）
本書の冒頭で「オブザーバビリティ」を下記のように定義します。
ソフトウェアシステムにおけるオブザーバビリティとは、システムがどのような状態に陥っても、それがいかに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度です。 事前にデバッグの必要性を定義したり予測したりする必要はなく、システムの状態データのすべてのディメンションとディメンションの組み合わせで、アドホックな反復調査により、その起用な状態や新しい状態を比較しながらデバッグできる必要があります。 もし、新しいコードをリリースすることなく、どんな奇妙な、あるいは新しい状態でも理解できるのであれば、あなたのシステムにはオブザーバビリティがあると言えるでしょう。
そして 22 章で下記のように定義を強化します。
もし、ソフトウェアシステムのどんな状態でも、どんなに斬新で奇妙でも、高カーディナリティ・高ディメンションのテレメトリーデータを任意に切り刻んで必要なビューにすることで理解でき、コア分析ループを使って比較しながらデバッグして問題の正しい原因を素早く切り分け、それらのデバッグニーズを事前に定義または予測する必要がなければ、あなたのシステムにはオブザーバビリティがあると言えるでしょう。
また、「訳者あとがき」からの抜粋です。
もし、皆さんの組織で DevOps や SRE がうまくいっていないとしたら、もしかするとオブザーバビリティが不足しているのかもしれません。両者は表裏一体なのです。
他にも、「訳者あとがき」から以下の文章もオブザーバビリティの重要性としてわかりやすかったです。
SRE はさまざまなプラクティスの集合ですが、それらの中でも「サービスの信頼性を基に意思決定を行う」というプラクティスは大きな柱の一つとなっています。 この「サービスの信頼性」をどのように数値化し、可視化するかという点において、本書が解説するオブザーバビリティが深く関与しています。
（中略）
本書はこのような信頼性の可視化や、インシデントの際の備えとなる、オブザーバビリティがあるシステムを構築するための考え方や技術的要件を解説します。 またオブザーバビリティを備えたシステムにおける運用手法や組織内での文化の普及方法についても解説しています。 したがって、本書はこの SRE と呼ばれる概念が普及した 2022 年において、その支えとなるオブザーバビリティを備えるために必携の書籍であると思います。
本書を読む前はオブザーバビリティについて具体的なイメージを持っておらず、「ログを出力しているか」「解析しやすいログか」「ログを解析するダッシュボードがあるのか」といった印象でした。 しかし、本書を読み進めるると、DevOps・SRE を達成するための重要な要因として語られていました。 その結果、サービスに信頼性とそれが生み出す価値についてさらに考えるようになり、SRE への興味が強くなりました。
自身の業務の課題と実践するべきこと
本書を読んで、自身の業務に課題があると思いました。 それは、テレメトリーデータやログを正しく出力および評価できていないことです。その結果、直感に頼った調査しており、サービスの信頼性を算出できていません。 これはオブザーバビリティからかけ離れているため、DevOps・SRE が実践できないことが明確になり、持続的な成長が難しい状態だと再認識しました。
これらの問題を解決するために、以下を実践する必要があると考えました。 1 つめは本書を読む前から議論できていませんでしたが、本書をきっかけに実践しようと思いました。
- オブザーバビリティをもとに DevOps・SRE についてチームで議論する
- 高カーディナリティ・高ディメンションのテレメトリーデータを議論しログに組み込む
- 会社で使われているモニタリング・オブザーバビリティツールのできることできないことを理解し、サービスを評価できる状態に近付ける
本書を読んでも実践が難しい内容
本書を読んでも実践が難しいと思った内容は OpenTelemtry によりテレメトリーデータの送信や、本書に記載されているダッシュボードの再現です。 どちらも参考になりましたが、業務ですでに利用されているライブラリやツールがあることを考えると、解釈や置き換えが難しそうだと思いました。 オブザーバビリティを推進するときには 1 つの課題になりそうです。
次に関連で勉強すること
DevOps・SRE に関わる下記の書籍を読みます。入門 監視は個人的な勉強会の課題図書になっています。
まとめ
本書を通じて、オブザーバビリティについて学び、DevOps・SRE と表裏一体であることを認識しました。 オブザーバビリティがある状態は業務と逆の状態になっているので、オブザーバビリティを通じて DevOps・SRE の達成を目指そうと考えました。 そのため、議論をすべきことは多そうですが段階を踏んで実践していきます。
最後になりましたが、翻訳者の方がブログで本書の概要を紹介しているので、興味がある方は以下のリンクから読まれることをお勧めします。
