読みました。
オブザーバビリティ・エンジニアリング 目次 第Ⅰ部 オブザーバビリティへの道 1章 オブザーバビリティとは？ 2章 オブザーバビリティとモニタリングにおけるデバッグ方法の違い 3章 オブザーバビリティを用いないスケーリングからの教訓 4章 オブザーバビリティとDevOps、SRE、クラウドネイティブとの関連性 第Ⅱ部 オブザーバビリティの基礎 5章 構造化イベントはオブザーバビリティの構成要素である 6章 イベントをトレースにつなぐ 7章 OpenTelemetryを使った計装 8章 オブザーバビリティを実現するためのイベント解析 9章 オブザーバビリティとモニタリングの関係 第Ⅲ部 チームのためのオブザーバビリティ 10章 オブザーバビリティへの取り組みをチームへ適用する 11章 オブザーバビリティ駆動開発 12章 サービスレベル目標の信頼性向上への活用 13章 SLOベースのアラートへの対応とデバッグ 14章 オブザーバビリティとソフトウェアサプライチェーン 第Ⅳ部 大規模なオブザーバビリティ 15章 投資収益性: 作るか、それとも買うか 16章 効率的なデータストア 17章 安価で十分な精度にするためのサンプリング戦略 18章 パイプラインによるテレメトリー管理 第Ⅴ部 オブザーバビリティの文化を拡大する 19章 オブザーバビリティのビジネス事例 20章 オブザーバビリティの利害関係者と協力者 21章 オブザーバビリティ成熟度モデル 22章 ここからどこへ
自分は現在は所謂エンジニアという感じの職種ではなく、「カスタマーサクセス」とか「ソリューションアーキテクト」といった感じが近い働き方をしてるのだけど、この本の後半、特に19章・20章あたりでいきなりググっと引き寄せられ、釘付けにされるような感じがありました。
というのも、以前にこんなのとかこんなブログ記事を書いたりしていることもあるとおり、自分のキャリアの目指す先にある "何か" にとって非常に重要な要素のうちのひとつとして、「カスタマー x エンジニアリング的な何か」があると以前から思っていて、今回この本を手に取ったのも、それに関する何かヒントの断片のようなものがないだろうか、と藁にも縋るような思いがあったからでした。
で、実際に読んでみてどうだったか、というと、まさに大正解というか、「自分と同じことを考えてる人がいた！！」という感じでした。20章なんかもうモロに「カスタマーサクセス」のワードが出ちゃってますからね！
20章 オブザーバビリティの利害関係者と協力者
20.1 非エンジニアリング的なオブザーバビリティの必要性の認識
20.2 オブザーバビリティの協力者を作る実践
20.2.1 カスタマーサポートチーム
20.2.2 カスタマーサクセスチームと製品チーム
20.2.3 営業チームと役員
それ以外にも、例えば本書 P.265 には オブザーバビリティはエンジニアだけに限定されるべきではありません。同梱されたテレメトリーは、プロダクトマネージャーやカスタマーサクセス担当者が本番環境に関する質問に答えられるようにする必要があります とあったりもするし。
でもこれで（ようやく）自分の中にあった考えに自信が持てるようになりました。「Customer Reliabilty Engineering」だったり「カスタマーサクセスエンジニア」みたいなものを構成する最重要要素として、「カスタマー x オブザーバビリティ」というのはきっとあるよな、という。本書の268ページには以下のような記述があったけれど、
はっきりさせておきたいのは、すべてのチームがオブザーバビリティを専門にするわけではないということです。専門にしているエンジニアリングチームでさえ、あるチームは他のチームよりはるかに多くのコーディングと計装をするでしょう。しかし、あなたの会社のほとんどすべての人が、本番環境の現状についての詳細を分析するために、オブザーバビリティデータをクエリーできることに利益があります。 - Charity Majors、Liz Fong-Jones、George Miranda 著、大谷 和紀、山口 能迪 訳「オブザーバビリティ・エンジニアリング」,オライリー・ジャパン,P.268
まさしくこの裏返しで、オブザーバビリティを専門とするチームは多くのケースで顧客エンゲージメントについては専門にしていないことがほとんどであると思っていて、「システム開発とオブザーバビリティ」を専門にしているチームがあるのと同じく「オブザーバビリティと顧客エンゲージメント」を専門とするチームもあっていい・それこそがまさに、CREs だったり CScE であってほしい、んですよね。P.269-270には ビジネス機能をサポートする計装をコードベースに追加する場合は、エンジニアリング以外のビジネスユニットのニーズが満たされていることを、レビューによって確認する必要があります。 とあるけど、この観点だけでも、CREs だったりのロールが存在することのメリットは計り知れないよなーと。もちろんそれが "協力者" であってももちろんいいんだけど、本人がオブザーバビリティを主導できる力を持てるとそれはもう当たり前に強いよね、という。
そんなわけで、世の「カスタマー x エンジニアリング」な人にもぜひ読んでほしいな、という一冊でした（そういう方は、本書の中盤あたりはさらっと読んでしまってもいいと思います。技術的にはおもしろい記述がたくさんあったけど）。
最後に、本書の訳者のうちのお一人である大谷さんが先日、「技術書は気に入った一節を見つけるだけでいい」、と書かれておられ、たしかにそうだな、いいな、と思ったので、自分もこれに倣って、本書の中で一番気に入った一節を最後に引用させていただいて、このエントリを終わります。
エンジニアリングチームによって専門分野は異なりますが、自社のソフトウェアを使用する人々に優れた顧客体験を提供することは、決して「他の誰かの仕事」ではありません。それは共有された責任であり、全員の仕事なのです。オブザーバビリティも同じように考えられます。（中略）オブザーバビリティがあれば、ある時点において、顧客が実世界であなたのソフトウェアを使用したときの経験を理解できます。 - Charity Majors、Liz Fong-Jones、George Miranda 著、大谷 和紀、山口 能迪 訳「オブザーバビリティ・エンジニアリング」,オライリー・ジャパン,P.146
