# @akiakaba memo: オブザーバビリティ・エンジニアリング
https://www.oreilly.co.jp/books/9784814400126/

## 1章 オブザーバビリティとは？

何が起こっているのかを把握できる度合いのこと。

### 感想

現代の監視saasに触れてるから、何が伝統的なモニタリングで何がオブザーバビリティなのかわからない。

## 2章 オブザーバビリティとモニタリングにおけるデバッグ方法の違い

## 3章 オブザーバビリティを用いないスケーリングからの教訓

## 4章 オブザーバビリティとDevOps、SRE、クラウドネイティブとの関連性

## 5章 構造化イベントはオブザーバビリティの構成要素である

### 主張

従来のメトリクスはオブザーバビリティと噛み合ってない。オブザーバビリティの基本的な構成要素はスキーマレスの構造化イベント（ログ）。分析ツールは高カーディナリティのデータの分析ができないといけない。

### 感想

理想を言えばそう。ただ自分が担当してる10KRPSのシステムで現実的にログのようなサイズのデータを絞らずに十分な期間ためて分析できるSaaSはない。最適化の結果のメトリクス利用だったりする。

イベントにどのようなフィールドを出力するかは実装次第。メトリクスは事前に何が起こるか知っていないと役に立たないと主張する一方で、イベントなら未知のインシデントの分析もできるというのは誇張のように思う。

## 6章 イベントをトレースにつなぐ

分散トレースの説明。トレースとスパン。実装イメージ。

概念
- トレースID、スパンID、親スパンID

依存先システムにトレースをつなげるため、アウトバウンドリクエストのヘッダにトレースID、親スパンIDを載せる。

クライアントシステム -> バックエンドのLB -> バックエンドシステム

- クライアントシステムのスパン
- クエリ呼び出し
- 重い演算
- オブジェクトストレージ書き込み
- バックエンドのバックエンド呼び出し

標準: https://www.w3.org/TR/trace-context/
- X-B3-TraceId
- X-B3-ParentSpanId

スパンへのカスタムフィールドの追加
イベントをトレースにつなぐ

## 7章 OpenTelemetryを使った計装

? 計装って何の訳なんだろ

>計装（けいそう、Instrumentation）とは、生産工程等を制御するために、測定装置や制御装置などを装備し、測定することなどをいう。最近の計装は、上は経営情報システムから、下は個々の装置の制御装置まで、階層化・統合化されたシステムとしての側面が強くなっている。
>_{https://ja.wikipedia.org/wiki/%E8%A8%88%E8%A3%85 より}

### 計装標準

テレメトリの送信には各SaaSのライブラリを用いたり実装（利用）がばらばらなのでベンダーロックインされる

標準を作った => OpenTelemetry(OTel)

かつては
- OpenTracing
- OpenCensus

### OTel の概念

- API: ライブラリの仕様
- SDK: 実装
- Tracer: アクティブなスパンの操作
- Meter: メトリクスの操作
- Context propagation:
- 概要: 受信リクエストのコンテキストをデシリアライズ・現在のリクエストコンテキストのトレース・下流のサービスに渡すためのコンテキストのシリアライズをする
- W3C Trace Context[^trace_context]
- ? B3M: 検索で見つからない
- Exporter: プラグインの一つ。インメモリオブジェクトをどこか（ローカルやリモート）に送信
- Collector: プロキシやサイドカーとして実行されるプロセスでテレメトリを受信・処理・送信する

[^trace_context]: https://www.w3.org/TR/trace-context/ この仕様は、分散トレースシナリオを可能にするコンテキスト情報を伝播するための標準HTTPヘッダと値フォーマットを定義します。この仕様は、コンテキスト情報がサービス間でどのように送信され、変更されるかを標準化します。コンテキスト情報は分散システムにおいて個々のリクエストを一意に識別し、プロバイダ固有のコンテキスト情報を追加・伝播する手段も定義しています。

### その他用語

テレメトリ: 特定のリクエストのセットを処理するときにコードが何をしたか
- ログ・メトリクス・トレース・プロファイル等

## 8章 オブザーバビリティを実現するためのイベント解析

従来の方法の課題: システムに精通している人が、知っていることを頼りにデバッグを行う -> マネージャはそれを一般化しようと手順書化させるが、同じ方法で二度故障することはほとんどない

### 第一原理

他の仮定から演繹されたものではない基本的な仮定。

### コア分析ループ

1. 顧客やアラートから何を聞いたか
2. 変化が起きているところを見つける
3. 変化を促す要素を探す
4. 領域をフィルタして1に戻る

総当たり部分をツールで行う

## 9章 オブザーバビリティとモニタリングの関係

- オブザーバビリティとモニタリングは異なる
- モニタリングを捨ててオブザーバビリティツールを導入するというのは軽率
- ガイドライン
- オブザーバビリティはアプリケーションレベルの問題を理解するのに最適
- モニタリングはシステムレベルの問題を理解するのに最適

### モニタリングが適した場所
- アラートが出たときに対応する（＝リアクティブな）仕事に最適化されている
- 既知の未知を検出するように設計されている
- インフラにフォーカスしている
- 時代につれてアプリケーションレベルのモニタリングをするようにはなってきたが、いい方法ではない

### オブザーバビリティが適した場所
- よりプロアクティブ
- これまでに知られていなかった障害モード（＝未知の未知）を発見するために設計されている
- アプリケーションにフォーカスしている
- コードの状態が頻繁に、予測しにくい方法で変更される状況での可視化

### 考察: システム vs ソフトウェア

- ソフトウェア: 市場の問題を解決すべくビジネスが求めているもの
- システム: 動かしたいソフトウェアをサポートするために動かす必要があるもの

システムのほうがゆっくりと変化し、予測可能なので従来型のモニタリングが向いている。

### 組織的なニーズを把握する

コアビジネス戦略の一環としてソフトウェアを作成してリリースしているのであれば、オブザーバビリティが必要。

PaaSを使用しているなら従来のモニタリングはほとんど必要ない。

例外: CPU使用率、メモリ使用量、ディスクの使用状況などの高次のインフラメトリクスは物理的な性能の限界を示していて、ソフトウェアエンジニアは注意深く観察する必要がある。

> [!NOTE]
> 例外じゃないもの（高次じゃないもの）は何なの？ => 電源管理やカーネルドライバに関するメトリクスとのこと。

## 10章 オブザーバビリティへの取り組みをチームへ適用する

どこから始めるかは状況によるが、一般に言えること
- コミュニティグループに参加する
- 他の人から学ぶ
- こちらも価値を提供する必要があることには注意
- すでに十分なところではなく、最大の問題点を解決するところから始める
- 作るより買う: OpenTelemetry
- 既存の努力を活用する機会を探す: サンクコストが移行の障害になる
- これまでの監視で使えるものは使うなど
- 最後のひと押しに備える: やりやすい部分は進むけど、オブザーバビリティに十分な移行が完了するには大変な部分もあり、やり切る計画が必要

## 11章 オブザーバビリティ駆動開発

実稼働環境にリリースされたあとにのみオブザーバビリティが適用されることを意味するものではない。

## 12章 サービスレベル目標の信頼性向上への活用

しきい値ベースのモニタリングがもたらす一般的な問題
SLOベースのアプローチで解決

- 12.1　従来のモニタリング手法（しきい値ベース）では危険なアラート疲れが発生する
- アクションに繋がらない
- 無視するようになる
- 12.2　しきい値アラートは既知の未知のみに対応している
- 障害は避けられない
- 自動的に修復される障害ではアラートを発生させるべきではない
- デバッグしてはならないわけではないが、通常の営業時間内に行う
- アラートは2つの基準を満たさなくてはならない
- サービスのユーザ体験が劣化した状態にあることを示す指標でなければならない
- 解決可能でなければならない
- 12.3　ユーザー体験が道しるべ
- 分散システムには失敗は避けられず、常に少し失敗している
- 10人のユーザが応答時間が大きかったのような静的指標では、ピーク時の10人と閑散期の10人で重要度が違う
- P95の応答時間も、ピーク時にはうまくはたらくようにできても閑散期では個々のデータポイントの影響が大きくなりすぎる
- 5分ウィンドウでP95を測ったとすると、何かあったら5分ダウンしていることになるが実際の感覚と乖離している可能性がある
- そこでSLO
- 12.4　サービスレベル目標とはなにか？
- Google の SRE 本で広まった
- SLOはSLAより厳しい
- オブザーバビリティなしにSLOを導入するとまずい

### SLO

- :x: システムの測定基準に基づく
- :o: エンドユーザージャーニーに基づく

時間ベースのSLI（指標）とイベントベースの指標
> 時間ベースの指標 （「各5分ウィンドウのP99レイテンシーが300ミリ秒未満」など）と、 イベントベースの指標 （「特定のローリング時間ウィンドウの間に300ミリ秒未満で終了したイベントの割合」など）です。

（あまりピンときてない）

#### イベントベースの例
良い顧客体験を
>「ユーザーがホームページを正常にロードし、素早く結果を見ることができる状態」
>
と定義

例として

- リクエストパスが /home であるイベントの中で
- イベントの持続時間が100ミリ秒未満
- かつ 正常に処理された場合

が OK イベント。

SLO はサービスのユーザの体験に影響を与える症状のみを考慮し、なぜどのようにサービスが劣化しているかということは見ない。

原因ベースのアプローチをする従来のモニタリングとは対照的。
分散システムでは「アップ・ダウン・スロー」以外にも様々な障害モードがあり、アラートの管理上ユーザ体験への影響と原因を切り離すことは重要。

### アクション可能

## 13章 SLOベースのアラートへの対応とデバッグ

### ウィンドウ
- :o: スライディングウィンドウ（直近n日）
- :x: 固定ウィンドウ
- ある月の31日に障害が起こって翌月2日にも障害が起こっても良いとするのは顧客の感覚に合ってない

### SLO
- :x: 顧客との契約
- :o: 顧客の体験・満足度を測定する方法
- より良いSLO: 人間の感情・記憶・リーセンシーバイアスを考慮したもの
- SLOはノイズが多い従来のモニタリングの解決

### エラーバジェット
- SLOを使用する際のアラートに利用できる
- 枯渇したら新機能の優先度を下げてサービスの安定性を高める方向にシフトするのが基本
- 先制的（バジェットが枯渇しないように対応する）アラートを設定する難易度は高い
- 予測は 99.95%より低いSLOの違反を防ぐために効果的
- 予防的な働きはあまりしないがシステムの劣化を検出してアラートを出すためには有用
- インシデント発生 -> アラート発報 -> 人間が気づく -> 人間が対応 -> 対応完了 までに何分もかかるようなら達成できない
- 自動復旧の重要性が高くなる
- 状況の緩和策『サイトリライアビリティワークブック』5章「SLOに基づくアラート」
- 消費率を追跡して、枯渇させるような急激な変化をモニタリングする
- ルックアヘッドウィンドウ／ベースライン（ルックバック）ウィンドウ
- 実践的に、ベースラインウィンドウの前方に4倍まで線形予測が可能
- 短期間バーンアラートとコンテキストアウェアバーンアラート
- 短期間バーンアラート: 直近の期間（ベースラインウィンドウ）のデータから外挿
- コンテキストアウェアバーンアラート: SLOのウィンドウ全体のデータを使って外挿。バジェットの10%しか残ってないときと90%残っているときでは同じエラーでも緊急度が違う、と見なす場合など使う
- 計算コストと感度・特異度とのトレードオフ
- :o: イベントベース :x: 時間ベース
- （99.99%のSLO等）バジェットが少なければ数秒・数分で使い切る可能性があり、時間ベース（ダウンタイム）で「良い分」「悪い分」のような指標を使った判断は精度が足りない
- P95で300ms以下のようなSLOでは、P96で300msだとokでP94で300msだとその時間全体が障害という扱いになるけど、顧客体験と紐づいていない

### SLOとオブザーバビリティデータの結合
- アクション可能なアラートを作れる: いつどこで障害が発生したかを確認できるようになる

## 14章 オブザーバビリティとソフトウェアサプライチェーン

ビルドパイプラインを可視化することについて Slack のエンジニアからの寄稿。

ソフトウェアサプライチェーン:
> 開発からCI/CDパイプラインを経て、本番環境にデプロイされるまでのソフトウェアに入るもの、あるいは影響を与えるものすべて

> 内部ツールでは本番環境よりカーディナリティは低くなるが単一のイベントとスパンの重要度は高くなる

（ピンとこなかった）

---

第4部 大規模なオブザーバビリティ

> 第Ⅳ部では、オブザーバビリティの採用が成功し、大規模に実践されたときに何が起こるか、という採用のもう一方の側面について考察します。

## 15章 投資収益性: 作るか、それとも買うか

両方の選択肢の総コストを見極める必要がある。

まず目に見えるコストを計算
- 購入: お金
- 構築: 時間

次に隠れたコストを計算
- 構築: 機会費用・運用
- 購入: 将来的な利用コスト・ベンダーロックイン

> ソリューションを開発、維持するために必要なエンジニアの募集、雇用、トレーニングなどの隠れたコスト（エンジニアの給与やインフラストラクチャのコストも含む）に加え、 コアビジネスの価値を実現できていないツールの運用にエンジニアを割くことによる機会費用を十分に考慮する必要があります。

>リーダーやエンジニアの仕事は、ノイズを排除し、ビジネスを前進させるソリューションの中でもっともインパクトのあるニーズはどれか、優先順位をつけることです。

急に殴られた……

> コーディングは早くて安いですが、そのコードを保守するのは時間とコストが非常にかかります。
> 私たちは度々 **できるかどうか** に気を取られ、 **すべきかどうか** を考えるのをやめてしまうことがあると、同じエンジニアである私たちは知っています。

ベンダーの100万ドルのソリューションに尻込みして、インフラ費+エンジニアのコストで200万ドルの内製ソリューションを運用していたケースを上げている。

ベンダーロックインとOTel

### 購入するメリット・リスク

- メリット
- Time to Value: 価値実現までが早い
- オブザーバビリティに関する専門知識を持つパートナーと出会える可能性がある
- 自社で育てるには相当な時間がかかる
- リスク
- ベンダーに責任を押し付けることで、自社でオブザーバビリティに関する専門知識の獲得が薄くなる

買うか作るかは二者択一ではない

## 16章 効率的なデータストア

ソリューション内製する上での、データストアに関する知見。

## 17章 安価で十分な精度にするためのサンプリング戦略

ソリューション内製する上での、データサンプリングに関する知見。

TODO: 外部ソリューションでも使えるかもしれないけど一旦読み飛ばしてる。

## 18章 パイプラインによるテレメトリー管理

> テレメトリーパイプラインのもっとも単純な目的は、どのテレメトリーがどこに行くかの設定を一元管理しながら、データを生成された場所から異なるバックエンドに ルーティング することです。

めちゃくちゃお金かかりそう。

できるようになること
- ワークロードの分離
- でかいデータと小さいデータのワークロードを分離して、小さいデータのクエリ品質を担保する
- セキュリティレベルの違うデータの分離
- 個人情報は特定の人しか見られないようにするなど
- バッファリング
- オブザーバビリティバックエンドの信頼性は100%ではなく障害が発生して可視性が失われることがある
- 一定期間分のテレメトリデータを保持することでオブザーバビリティの信頼性を向上させる
- キャパシティ管理
- レート制限
- サンプリング
- キューイング
- データ変換
- 非構造化ログや異なる構造化のログのフォーマットの吸収

実装するにしてもスクラッチではなくOSSの利用が勧められている。

-> OTel にも pipeline の概念がある https://opentelemetry.io/docs/collector/architecture/#pipelines

## 19章 オブザーバビリティのビジネス事例

> オブザーバビリティは普遍的に、4つの重要な方法で最終損益に影響を与えると信じています。
>
> **収益の増加:**
> オブザーバビリティツールは、稼働時間とパフォーマンスの向上を支援し、コード品質を向上させることによって、直接的な収益の増加をもたらします。
>
> **インシデント対応の迅速化によるコスト削減:**
> オブザーバビリティは、平均検出時間（MTTD）と平均解決時間（MTTR）の短縮、クエリーの応答時間の改善、ボトルネックの早期発見、通話時間の短縮、ロールバック回避による時間短縮により、人件費を大幅に削減します。
>
> **インシデント回避によるコスト削減:**
> オブザーバビリティツールにより、開発者は問題が重大かつ長期化する前にその原因を発見することができ、インシデントの防止に役立ちます。
>
> **従業員の離職率の低下によるコスト削減:**
> オブザーバビリティを導入することで、仕事の満足度が向上し、開発者の燃え尽き、アラート、オンコールでの疲労、そして離職が減少します。

> プロアクティブなアプローチは、リアクティブな状況における症状を、異常であり予防可能で認識することから始まる

> [!Note]
> そういえばTTRって自動復旧を含むんだろうか。含まないんだとしたら自動復旧が導入されるごとに自動復旧できない障害の重みが増してMTTRは増える可能性がある。一方、パブリッククラウド等の自動復旧はそれが自動復旧と認識することもできないので計算の分母がわからない。

プロアクティブに問題を発見して解決できるようになると予期せぬ障害対応の業務量が減る。

>アプリケーションにセキュリティやテスタビリティを導入するのと同様に、オブザーバビリティは継続的に実践するものであり、本番環境の開発や運用に携わるすべての人が責務を共有するものです。

オブザーバビリティのイニシアチブをサポートするビジネス事例を作ることが大事。

## 20章 オブザーバビリティの利害関係者と協力者

エンジニアリングチームが社内の他のチームと提携し、オブザーバビリティ文化の採用を加速させる方法。いくつかの典型的ビジネスチームの支援方法を挙げている。多くのビジネスチームの目標達成を支援することで協力者が生まれる。

BIツールとの使い分け・併用
- クエリ実行時間
- 精度
- 最新性
- 構造
- 時間枠
- 揮発性

## 21章 オブザーバビリティ成熟度モデル

オブザーバビリティ採用の成熟度曲線によって組織全体の進捗を測定する方法。進捗状況を測定し、投資対象分野に優先順位をつける計画を持つことがもっとも効果的。

[ケイパビリティ成熟度モデル](https://insights.sei.cmu.edu/library/key-practices-of-the-capability-maturity-model-version-11/)というのがある 。成熟度モデルを見るときに重要なことは、すべての組織に適用できる万能のモデルはないということ。

[オブザーバビリティ成熟度モデル](https://www.honeycomb.io/wp-content/uploads/2019/06/Framework-for-an-Observability-Maturity-Model.pdf)が設定する、エンジニアリング組織の目標
- 持続可能なシステムとエンジニアの生活の質（QOL）
- 顧客満足度の向上によるビジネスニーズへの対応

### OMMで参照されるケイパビリティ

- システム障害にレジリエンスで対応する
- cf. https://www.infoq.com/news/2019/04/allspaw-resilience-engineering/
- チームが上手くいってる場合
- チームが上手くいっていない場合
- オブザーバビリティとの関連性
- 高品質なコードをデリバリーする
- チームが上手くいってる場合
- チームが上手くいっていない場合
- オブザーバビリティとの関連性
- 複雑さと技術的負債に立ち向かう
- 予測可能なケイデンスでリリースする
- ユーザーのふるまいを理解する

> [ワードリーマッピング](https://en.wikipedia.org/wiki/Wardley_map)は、現在の組織の能力に関して、これらのケイパビリティの優先順位と相互依存性の関係を把握するのに役立つテクニックです。 どのケイパビリティがビジネスにとってもっとも重要かを理解することで、オブザーバビリティ導入の旅を進めるために必要なステップをの優先順位を付けたり、障害を取り除いたりできます。

## 22章 ここからどこへ

>　[!Important]
>　ソフトウェアシステムにおけるオブザーバビリティとは、システムがどのような状態に陥っても、それがいかに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度です。 事前にデバッグの必要性を定義したり予測したりする必要はなく、システムの状態データのすべてのディメンションとディメンションの組み合わせで、アドホックな反復調査により、その奇妙な状態や新しい状態を比較しながらデバッグできる必要があります。 もし、新しいコードをリリースすることなく、どんな奇妙な、あるいは新しい状態でも理解できるのであれば、あなたのシステムにはオブザーバビリティがあると言えるでしょう。

今後の予測。

# 感想

- 全体的には冗長だなと思った
- 監視SaaSネイティブだからかも
- SLO への興味が強まった
- 追加実装せずに分析可能というのを目指すのは考えてもいいかも
- ビジネスとかリリースとか、直接プロダクトじゃない部分の可視化という発想は読む前からあったけど、改めてやってもいいなと思った