# @akeboshi memo: オブザーバビリティ・エンジニアリング

## 1章

- strace や tcpdump などの 低 レベル の コマンド や、 何百 もの print ステートメント に 逆戻りし始める事はよくある
- 正直これをなくすことはできないんじゃないかと思うんだけどそうでもないんか？

オブザーバビリティを高めて、経験則からではなく、障害の予測・検出をやりやすくする
従来はモノリス前提だったけど、マイクロサービスなど複数のシステムが複雑に絡み合ったシステムを監視するための手段ということかな

## 2章

## 3章

## 4章

## 5章

多くの要素と高いカーディナリをもった構造化ログを作ろう

## 6章

分散トレースできるようにしよう

- zipkin, jaeger, honeycomb, lightstep

w3c でヘッダー取り決められてるのか

- X-B3-TraceId
- X-B3-ParentSpanId
- https://github.com/openzipkin/b3-propagation?tab=readme-ov-file#parentspanid-2

## 7章

- 短期 集中 講座: OpenTelemetry の 概念 を 学ぶ. otel の文脈でよく出てくる単語なので覚えとくとよさそう
- Tracer
- Meter
- Context propagation
- Exporter
- Collector
- OTLP の ユビキタス 性 を 考慮 する と、 ベンダー の カスタム コード では なく OTLP の gRPC エクスポーター を 使っ て、 任意 の ベンダー もしくは OpenTelemetry Collectorを使う
- OTLP で定義された共通のプロトコルで送ってあげるようにしとくと切り替えやすくて便利だよね！

## 8章

- 手順書不要論
- わからなくはないが、必要な時は必要。もちろん自動化するべきではあるが、alert が鳴ったときにどういう指標を見ていくかとかのドキュメントは残したほうがいいしなぁ

- コア分析ループ (本がわかりにくい)
- 調べたいことを言語化する
- それについて関連するデータを可視化する (すでに可視化されてればスキップ)
- 可視化されているデータを多方面から分析し、抽象化する
- 調べたいことの原因が特定出来たら完了、できてなければ、次は何を調べればよいか考える

- AIops (https://thenewstack.io/observability-and-the-misleading-promise-of-aiops)
- 現在はまだ、ai にアラート鳴らしてもらって、そこからデータ可視化・分析は必要
- とはいえ、この本が書かれている当時より精度はあがってそう

## 9章

- モニタリングは cpu, memory とか (もしくはもっと低レイヤーのメトリクス) インフラ的なもののみをさしてるのかな

- オブザーバビリティの定義がいまいちわからなくなってくる
- ソフトウェアのメトリクスであったり、ユーザの行動を追うようなTracing のな話かな

- コアビジネス戦略の一環として、 ソフトウェアを作成してリリースしているのであれば、 オブザーバビリティソリューション が必要
- まぁ、わかる。その前に分析基盤だとは思うが

## 10章

- 最大の問題点を解決することに重点を置いてください
- 一定理解できるが、最大の問題があるときはほかに優先させるものが多いのでは？
- マネージメントの承認を得た後に進める時の話なので↑は関係ない

## 11章

DevOps しましょうという話

## 12章

- 逸脱の常態化
- alert 仕掛けるときには結構これは本当に陥る
- ラムズフェルドの4象限
- 

■ Known Knowns （知っていると知っていること）

置かれている状況もとるべきアプローチも分かっている状態。例えば、オリヅルを折ってくださいと言われた場合、それを習得している人であれば、ほぼ自動的に手順を辿ってオリヅルを作成できます。また、経理係は月末に送られてくる請求書の処理をする際にいちいち手順を確認しません。それは与えられたタスクに対しての知識が十分にあり、それを行う手順を自分が知っていることを知っているからです。

■ Known Unknowns（知らないと知っていること）

それを知るべき必要性とその存在は知っているけれど、十分な情報がない状態。例えばFXをやっている人は、為替レートが常に変動することを知っており、それを利用してお金を稼ごうとします。しかし、いつどのタイミングでレートがどう変動するかは偶発的な要素（テロ、大企業の倒産、大国の首長選の結果etc）に大きく左右され、それを事前に知ることはできません。しかし、知らないと知っていることはそれについて知ろうと努力することができます。

■ Unknown Knowns（知っていると知らないこと）

知っている気はするのだけど、確信に至るような情報がない状態。いわゆる「第六感」が働いている感覚です。例えば長年の経験を持つ猟師は、何となく森のざわつきを感じ取り、獲物が近くにいると予測できます。しかしこのざわつきを理論的に説明してほしいと言われても、「長年の勘」としか答えられないのです。

もちろん勘が外れることもあります。ラムズフェルド元国防長官は、イラクの大量破壊兵器問題は自身にとって「知らないと知っていること」だったと伝えたかったのでしょう。

または、知っていることを認めたくないがために無意識に覆い隠している、という状態でもあります。幼少期の体験や家族との関係が原因でうつや怒りの発作に悩まされる人が、原因を認めるのを拒否する、といったケースがこれに当たります。

■ Unknown Unknowns（知らないことを知らないこと）

その事象について知る必要があることさえ知らず、もちろん発生の予測などできない「寝耳に水」の状態。例えば明日家に隕石が落ちてくるかどうかなど、普通は知る必要を感じることはなく、ましてや予測などできません。常に「自宅に隕石が落ちてくるかもしれない」などと心配していては、社会生活を送ることが困難になってしまうからです。非常に悲観的な言い方をすれば、私たちは皆、大なり小なり偶然の犠牲者となることを避けられないのです。

ちなみに同じ自然災害でも、大地震は「知らないと知っていること」に分類されます。いつどこで起こるかの予測は難しくても、それが高い確率で起こることは分かっているからです。

知らないことを知らない、ということはそれについてどうすることもできない、ということでもあり、ここには大きな危険性が潜んでいる可能性もあります。

known-knowns: 各種テスト、アラート
known-unknowns: システム監視 (dashboard を作っているような状態)
unknown-knowns: 第六感による問題特定
unknown-unknowns: 未知の故障系の対応

わかったら、 known-knowns にもっていくことが SRE の仕事

SRE Next で触れてた

---

- アラートに対応したデバッグ及びアクションをとるための体系的な方法が存在しなければならない。
- 特定のアラートには可能だが、SLOベース/エラーバジェットベースだとどうなのか？
- エラーバジェットベースだと、RunBookは用意できなさそう & 事前の検知も難しそうではある

## 13章

- Implementing Service Level Objectives ちょっと気になる
- 時間ベースのユニットはわかりやすいが、イベントベースのユニットは？
- 一か月の大体のリクエストを 43200 としてユニットにわけるのか？
- ちゃんとやろうとすると普通に複雑になるので、lambda など定期実行して datadog などからデータ取得して通知する形になるのかなぁ…
- ビジュアライズが難しいがどうするんだ…

## 14章

- 特定のユースケースに基づいてダッシュボードを作成する
- CI についてモニタリングしたことはなかったので、ここまで大規模になると得るものが多いというのは気づき
- CI/CD のモニタリングが必要なのはわかったが、これはオブザーバビリティなのか？

## 15章

## 16章

## 17章

## 18章

## 19章

- コード変更を金曜日にデプロイすることを禁止する
- 正当な理由があればオッケーだと思う
- 本質は、デプロイのハードルが下がっていて、基本的にはいつでもデプロイ出来る状態にあり、開発が遅くならないことが本質

## 20章

> サポートチームにはいくつかのオプションがあります。 もっとも簡単でシンプルなのは、SLOダッシュボードをひと目見て、顧客に影響を与える問題が検出されたかどうかを確認すること

> 営業チームがオブザーバビリティデータから引き出すことのできる定量的分析も、営業戦略の情報提供と検証に役立ちます。

Charity Majors, Liz Fong-Jones, and George Miranda　著、大谷 和紀、山口 能迪　訳. オブザーバビリティ・エンジニアリング (p.513). Kindle 版.

導入してよりよく使っていくには、サポートチームや、ビジネスサイドも使えたほうが好ましい。ので、ユーザ課金とはあまり相性はよくない.
もちろん、開発者がダッシュボードを使えて詳細な情報はサポートチームが使えないとかはあり

## 21章

OMM オブザーバビエリティ成熟度モデル (Observability Maturity Model)

- システム障害にレジリエンスで対応する
- 高品質なコードをデリバリーする
- 複雑さと技術的負債に立ち向かう
- 予測可能なケイデンスでリリースする
- ユーザーのふるまいを理解する

> システム障害に対して、レジリエンスをもって対応できるか どれだけ簡単に、高品質のコードを提供できるか どれだけうまく、複雑さと技術的負債を管理できるか どれだけ予測可能に、ソフトウェアリリースケイデンスを持っているか どれだけしっかりと、ユーザーの行動を理解できるか

## 22章