コンテナと Kubernetes の到来によりソフトウェアをデプロイおよび運用する方法は大きく変わりました。ソフトウェアはコンテナ化された分散システムとなり、Kubernetes（または類似の基盤）の上で自動化を通じて動的に管理されるものになっています。そうしたアプリケーションを開発し、本番（プロダクション）に高頻度でデプロイしながらも安定した運用を実現することが今求められています。 本セッションは「OpenShift Meetup Tokyo #9 - DevOps/GitOps編」での発表の続編としてアプリケーションの運用、監視におけるメトリクスやオブザーバビリティに関する DevOps のプラクティスを実践する方法と具体的に利用できるツールを紹介します。

1. 猛暑/残暑に負けるな！OpenShift.Run Summer #10
SUDA Kazuki (@superbrothers), Preferred Networks, Inc.
Kubernetes で実践する
クラウドネイティブ DevOps
“監視とオブザーバビリティ” 編

2. @superbrothers
前回のお話（DevOps / GitOps）
2
スライド: https://speakerdeck.com/superbrothers/cloud-native-devops-with-kubernetes-devops-cloudnative-and-gitops
YouTube: https://youtu.be/3_x1CO7XsaE?t=1216

3. @superbrothers
SUDA Kazuki / @superbrothers
▶ Preferred Networks, Inc. (PFN) エンジニア
▶ Kubernetes Meetup Tokyo, Prometheus Meetup Tokyo ほか、共同主催者
▶ CNCF Ambassador
▶ 「Kubernetes実践⼊⾨」、「みんなのDocker/Kubernetes」共著書
▶ 「⼊⾨ Prometheus」、「Kubernetes で実践するクラウドネイティブ DevOps」監訳書
3

4. https://www.oreilly.co.jp/books/9784873119014/
“ Kubernetesが標準プラットフォームである
クラウドネイティブの世界でアプリケーションを開発
し運⽤する⽅法を解説する書籍です。Kubernetesの
基本から、継続的デプロイ、機密情報管理、
オブザーバビリティなどの⾼度なトピックを扱う本書
は、サーバ、アプリケーション、サービスを管理する
IT運⽤者、クラウドネイティブサービスの構築や
移⾏を⾏う開発者必携の⼀冊です。

5. @superbrothers
PFN における Kubernetes の利⽤
5
多種多様な研究
多種多様なデータ
⼤勢の研究者
⾃社開発の技術
オンプレの GPU クラスタ
⼤量の機械学習ジョブ
Icon pack by Icons8 - https://icons8.com

6. @superbrothers
PFN の Kubernetes クラスタ
6
Tesla P100 PCIe x 8
10GbE x 2
InfiniBand FDR x 2
MN-1a サーバ
トータル 1024 GPUs
19.1 PFLOPS
2017年
Tesla V100 PCIe x 8
10GbE x 2
InfiniBand EDR x 2
MN-1b サーバ
トータル 1536 GPUs
53.3 PFLOPS
2018年
Tesla P100 SXM2 x 8
100GbE x 2
RoCEv2 with SR-IOV
MN-2a サーバ
トータル 1024 GPUs
128 PFLOPS
2019年
MN-Core x 4
100GbE x 2
MN-3a サーバ
MN-Core DirectConnect
トータル 192 MN-Cores
4.7 PFLOPS
(21.11 GFLOPS/W)
2020年
Icon pack by Icons8 - https://icons8.com
MN-1 Series MN-2 Series MN-3 Series
NVIDIA GPUなどの最新技術を採⽤した プライベート・スーパーコンピュータ MN-2 を⾃社構築し、7⽉に稼働
Preferred Networksの深層学習⽤スーパーコンピュータMN-3がスーパーコンピュータ省電⼒性能ランキングGreen500で世界1位を獲得
世界⼀位!!

7. @superbrothers
アジェンダ
1. 監視とオブザーバビリティ
2. Kubernetes におけるメトリクス
3. そのほか、PFN での取り組み
4. まとめ
7

8. @superbrothers
監視とオブザーバビリティ

9. @superbrothers
監視（モニタリング）とは何か
アプリケーションやツール、データベース、ネットワーク等の問題を知り、
それに対処するための情報を得て、問題に対処すること。
▶ アラートと問題の特定
+ システムの状態が悪くなっていることを知り、問題への対処を始める
▶ デバッグ情報の提供
+ 問題に対処するために必要な情報の提供
▶ トレンド調査
+ 現時点では問題ではないが時間の経過とともにどのように変化していくかを知る
▶ 他のシステムへの情報提供
+ オートスケーリングなど、⾃動化のために必要な情報を提供する
9

10. @superbrothers
ブラックボックス監視の限界
外部からの「アップ（up）かどうか」という問いかけに対してイエス∕ノーで答えるだけ。
▶ 予測可能な障害しか検出できない（例えばウェブサイトが応答しないなど
▶ システムの外部に露出する部分の挙動しかチェックできない
▶ 受動的かつ事後対応で、問題が発⽣した後でしか通知できない
▶ 「何が壊れているか」という疑問には答えられるが、
もっと重要な「なぜ壊れているのか」という疑問には答えられない
「なぜか」に答えるためには、ブラックボックス監視を超えた⼿法へ移⾏する必要。
10

11. @superbrothers
クラウドネイティブアプリケーションは常にどこかが壊れている
分散システムは、完全な意味で「アップ（up）」になることはない。*
▶ サービスが部分的に劣化しているのが定常的な状態であり、それを前提に稼働する
+ ブラックボックス監視のような単⼀の視点や観測からでは検出が難しい
▶ そもそも「アップ」を厳密に定義することは難しい
+ 名⽬上はアップの状態にあったとしても、
提供するサービスがユーザにとって機能していなければ、サービスはダウンしている
ブラックボックス監視は出発点としては意義があるが、そこでよしとすべきではないと認識する。
11* Ops: It's everyone's job now | Opensource.com

12. @superbrothers
ロギング、トレーシング、メトリクス
12
ロギング
Events
トレーシング
Request scoped
メトリクス
Aggregatable
Low
volume
High
volume
http://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

13. @superbrothers
198.186.192.44 - - [27/May/2010:01:56:54 +0100] "GET / HTTP/1.1" 403 327 "-" "-"
208.80.193.29 - - [27/May/2010:03:08:17 +0100] "GET / HTTP/1.0" 403 323 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; FunWebProducts; SIMBAR=0; .NET
66.249.68.210 - - [27/May/2010:03:46:25 +0100] "GET /robots.txt HTTP/1.1" 403 269 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html
66.249.68.210 - - [27/May/2010:03:46:25 +0100] "GET / HTTP/1.1" 403 263 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
198.186.192.44 - - [28/May/2010:02:04:30 +0100] "GET / HTTP/1.1" 403 327 "-" "-"
184.73.2.36 - - [28/May/2010:05:14:00 +0100] "GET /robots.txt HTTP/1.0" 403 272 "-" "SheenBot/SheenBot-1.0.4 (Sheen web crawler)"
184.73.2.36 - - [28/May/2010:05:14:00 +0100] "GET / HTTP/1.0" 403 267 "-" "SheenBot/SheenBot-1.0.4 (Sheen web crawler)"
208.80.193.42 - - [28/May/2010:12:56:12 +0100] "GET / HTTP/1.0" 403 323 "-" "Mozilla/4.0 (compatible; MSIE 7.0; AOL 9.0; Windows NT 5.1; FunWebProducts; InfoP
208.80.193.43 - - [29/May/2010:21:54:59 +0100] "GET / HTTP/1.0" 403 323 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; SIMBAR={ED852896-9625-4d9
188.140.124.209 - - [29/May/2010:23:04:22 +0100] "GET / HTTP/1.1" 403 263 "http://www.google.pt/url?
sa=t&source=web&ct=res&cd=2&ved=0CBkQFjAB&url=http%3A%2F%2Ftransmsilverio.com%2F&rct=j&q=transportes+manuel+silverio&ei=YY8BTNzMMZKL4AbUpNTLDg&usg=AFQjCNGYg9T
SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; InfoPath.2)"
188.140.124.209 - - [29/May/2010:23:04:36 +0100] "GET / HTTP/1.1" 403 263 "http://www.google.pt/url?
sa=t&source=web&ct=res&cd=2&ved=0CBkQFjAB&url=http%3A%2F%2Ftransmsilverio.com%2F&rct=j&q=transportes+manuel+silverio&ei=YY8BTNzMMZKL4AbUpNTLDg&usg=AFQjCNGYg9T
SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; InfoPath.2)"
188.140.124.209 - - [29/May/2010:23:05:56 +0100] "GET / HTTP/1.1" 403 263 "http://www.google.pt/url?
sa=t&source=web&ct=res&cd=1&ved=0CBUQFjAA&url=http%3A%2F%2Ftransmsilverio.com%2F&rct=j&q=www.transmsilverio.com&ei=vI8BTKe6M4SV4gbjruzLDg&usg=AFQjCNGYg9TdafIh
CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; InfoPath.2)"
208.80.193.30 - - [31/May/2010:05:56:02 +0100] "GET / HTTP/1.0" 403 323 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; YPC 3.2.0; FunWebProducts
207.44.204.87 - - [31/May/2010:14:35:45 +0100] "GET /wp-login.php HTTP/1.1" 403 274 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.ht
207.44.204.87 - - [31/May/2010:14:35:46 +0100] "GET /old/wp-login.php HTTP/1.1" 403 276 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bo
207.44.204.87 - - [31/May/2010:14:35:46 +0100] "GET /cms/wp-login.php HTTP/1.1" 403 276 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bo
207.44.204.87 - - [31/May/2010:14:35:47 +0100] "GET /blog/wp-login.php HTTP/1.1" 403 278 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/b
207.44.204.87 - - [31/May/2010:14:35:47 +0100] "GET /blog_old/wp-login.php HTTP/1.1" 403 282 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.c
207.44.204.87 - - [31/May/2010:14:35:48 +0100] "GET /blog-old/wp-login.php HTTP/1.1" 403 281 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.c
https://gist.github.com/pmcconnell-tc/9c3d57818d55ba7203d4e56f7142a43f
ロギング（Logging）
▶ イベントを対象として、イベント1つひとつのコンテキストの⼀部を記録する
▶ 例えば、HTTP リクエストをイベントとして、リクエスト時間、HTTP メソッド、パス、
リクエスト元 IP などのコンテキストをエントリとして記録する（アクセスログ
+ そのほかに、トランザクションログやデバッグログなど
▶ サンプリングしないので、記録できるコンテキストに⼤きな制限がなく、特定のイベントに
どのような問題があるのかを正確に特定できる
⼀⽅で、何を記録し、何を記録しないかは開発者が判断するため、ブラックボックス監視と同じく
検出できる問題は事前に予測しうるものに限定される。さらに、⼤量のストレージと帯域が必要で
スケールが困難。
13

14. @superbrothers
▶ ログフォワーダのツール
+ fluentd, fluent-bit
+ Logstash
▶ ログデータの管理、分析
+ ツール
+ Elastic
+ Grafana Loki
+ サービス
+ Google Cloud Logging
+ Amazon CloudWatch Logs
+ Azure Monitor
ロギングのツールとサービス
14Observability and Analysis - Logging / CNCF Cloud Native Interactive Landscape

15. @superbrothers
PFN でのロギング
▶ 転送しているログ
+ Kubernetes システムコンポーネント
+ Kubernetes Events
+ github.com/opsgenie/kubernetes-event-exporter
15
Google Cloud Logging
イベントをログに落とす以外に、特定のイベントを
Slack で通知といったこともできてべんりなんだけど、
イベントログが作成されなくなるバグがあるようなので注意 😅 (v0.9)

16. @superbrothers
トレーシング（Tracing）
▶ 1つのリクエストといった区切られたスコープのなかで関数呼び出しなどの
複数のイベントを記録し、ボトルネックがどこにあるのかを明らかにする
+ スタックトレース
+ プロセスをまたぐと分散トレーシングと呼ばれる
▶ サンプリングによってデータ量を⼀定に保ちつつ、
パフォーマンスに及ぼす影響を合理的な範囲に留める
16
12.94ms
11.95ms
6.91ms
6.71ms
1.27ms
0.04ms

17. @superbrothers
▶ ツール
+ Elastic APM
+ Jaeger
+ Zipkin
+ Lightstep
▶ サービス
+ Google Cloud Trace
+ AWS X-Ray
+ Azure Application Insights
トレーシングのツールとサービス
17Observability and Analysis - Tracing / CNCF Cloud Native Interactive Landscape

18. @superbrothers
メトリクス（Metrics）
▶ 何かの状態を測定した数値で、集計した結果から経時的にどのように変化しているかを明らかにする
+ アプリケーション: HTTP リクエスト数やリクエストの処理にかかった時間
+ インフラ: プロセスやコンテナの CPU 使⽤率、ディスク I/O、ネットワークトラフィック
▶ できる限りのコンテキストを無視することで、データ量と処理を合理的な範囲に維持する
18

19. @superbrothers
メトリクスは「動作している/していない」という単純な判断を超えて
監視の新たな次元を切り開く
▶ メトリクスは「なぜか」をあきらかにする
+ ⾃動⾞のスピードメータや⽬盛りが刻まれた温度計と同様に、メトリクスは現在の状況に
関する数値情報を与えてくれる
+ グラフの作成、統計処理、閾値に基づくアラートなどが簡単に処理できる
▶ メトリクスは「問題の予測」に役⽴つ
+ 運⽤者やユーザが問題に気付く前に、何らかのメトリック値が上昇してトラブルが
近づいている状況を⽰唆することがある
▶ メトリクスはアプリケーションを「内部から」監視する
+ 運⽤者がアプリケーションやサービスの内部実装を推測するのではなく、
システムの実際の動作（および障害）に関する情報に基づいて問題に取り組める
19

20. @superbrothers
メトリクスは、アプリケーションを内部から監視する
20
アプリケーションのリバースエンジニアリングを⽌めて内部からの監視を始めよう。
--- Kelsey Hightower、Monitorama 2016 にて（https://vimeo.com/173610242）
”

21. @superbrothers
▶ ツール
+ Prometheus
▶ サービス
+ Google Cloud Monitoring
+ Amazon Cloud Monitoring
+ Azure Monitor
+ Datadog
+ New Relic
+ Sysdig Monitor
メトリクスのツールとサービス
21Observability and Analysis - Monitoring / CNCF Cloud Native Interactive Landscape

22. @superbrothers
▶ https://github.com/prometheus/prometheus (Apache 2.0)
▶ クラウドネイティブの世界で事実上の標準となっているメトリクス管理ソリューション
▶ オープンソースのメトリクスベースモニタリングシステム
+ プル型で単純なテキストのメトリクス形式
+ 柔軟なクエリ⾔語
+ サービスディスカバリ機構との連携で動的な環境のモニタリングが得意
+ ダッシュボードとアラート通知
▶ 2016年に Cloud Native Computing Foundation の2番⽬のプロジェクトのメンバになる
+ 2018年8⽉に “卒業” (Graduated) プロジェクトとなる
Prometheus（プロメテウス）
22

23. @superbrothers
PFN でのメトリクス
23
▶ Prometheus Operator と⻑期記憶ストレージとして VictoriaMetrics を利⽤
Prometheus とその関連コンポーネントの管理を
Kubernetes でいい感じにやってくれるべんりなヤツです！

24. @superbrothers 24
スライド: https://speakerdeck.com/superbrothers/introduction-to-prometheus
YouTube: https://youtu.be/avj1QbWpf6M?t=1291
スライド: https://www.slideshare.net/pfi/prometheus-at-preferred-networks
YouTube: https://youtu.be/avj1QbWpf6M?t=4829
2019年6月時点の情報で
現在と異なっている部分があることに注意！

25. @superbrothers https://www.oreilly.co.jp/books/9784873118772/
Prometheus ユーザ必読！

26. @superbrothers
オブザーバビリティとは何か
可観測性、システムを運⽤する上で必要な内部状態の情報を取得できる状態にあること。
▶ システムのオブザーバビリティといえば、「測定のしやすさがどれほど担保されているか」
および「内部で何が起こっているかをどれほど容易に判断できるか」を⽰す尺
▶ オブザーバビリティは、システムの理解を促進する
+ システムの改善が意図したとおりに機能するかどうかの判断材料を提⽰できる
+ 「推測するな計測しろ」
これまでの監視が「システムが正しく機能しているかどうか」を⽰すのに対して、
オブザーバビリティが確保された監視は「システムがどうして正しく機能しないのか」を⽰す。
26

27. @superbrothers
オブザーバビリティを重視する⽂化の醸成
開発（Dev）と運⽤（Ops）の連携を通じて、サービスを測定できるようにしてオブザーバビリティ
を実現し、事実とフィードバックに基づくエンジニアリングのチーム⽂化へと移⾏。
27
開発（Dev） 運⽤（Ops）

28. @superbrothers
Kubernetes で活⽤すべきブラックボックス監視
Liveness（ライブネス）と Readiness（レディネス）の2つのプローブ。
▶ Liveness プローブ: ⾃分が健全（healthy）であるかどうか
+ 失敗するとコンテナが再起動される
▶ Readiness プローブ: ⾃分は問題ないが機能を提供できるかどうか
+ 失敗すると Service から切り離される、サーキットブレーカ
「クラウドネイティブアプリケーションは常にどこかが壊れている」
▶ サービスの優雅な劣化
+ ⼀部のコンポーネントで障害になった場合にもシステム全体の障害になることを回避する
28

29. @superbrothers
Kubernetes におけるメトリクス

30. @superbrothers
Kubernetes におけるメトリクス
▶ クラスタの健全性に関するメトリクス
+ ノードの健全性ステータスやノードあたり、および全体のリソース使⽤率∕割り当てなど
▶ Deployment などのオブジェクトに関するメトリクス
+ Deployment ごとのレプリカの設定数、利⽤できないレプリカの数など
▶ コンテナに関するメトリクス
+ ノードあたり、および全体のコンテナ/Podの数、リソース要求/制限に対する各コンテナの
リソース使⽤、コンテナのLiveness/Readinessの状況など
▶ アプリケーションに関するメトリクス
+ 受信したリクエストの数、返されたエラーの数、持続期間など
▶ ランタイムに関するメトリクス
+ プロセス、スレッドの数、ヒープとスタックの使⽤率、ガベージコレクション機能の
実⾏時間と待機時間など
30

31. @superbrothers
Kubernetes のメトリクスを取得する
▶ Kubelet （cAdvisor）
+ コンテナのリソース使⽤率と性能に関する情報
▶ github.com/kubernetes/kube-state-metrics
+ Kubernetes API にクエリして、ノード、Pod、Deployment などのオブジェクトに関する情報
▶ github.com/prometheus/node_exporter
+ OS カーネルが開⽰する CPU、メモリ、ディスクスペース、ディスク I/O、ネットワーク帯域
幅、マザーボードの温度などのマシンレベルの情報
31

32. @superbrothers
優れたメトリクスを選択する
▶ サービス: 「RED」パターン
+ Requests（リクエスト数）、 Errors（エラー）、Duration（持続期間）
+ 総数は増え続けるだけなので、例えば1秒当たりのリクエスト数（rate）に注⽬する
▶ リソース: 「USE」パターン
+ Utlisation（利⽤状況/使⽤率）、Saturation（飽和）、Errors（エラー）
+ Utilization はサービスがどの程度稼働しているか、Saturation はキューで処理待ちに
なっている仕事の量
▶ ビジネスメトリクス
+ サインアップしたもののキャンセルした割合（解約率）など
32
Prometheus は完全なデータ提供よりも 99.9% 正しいデータ提供と
機能継続を選択している。現⾦や請求書の処理などの完全なデータが
必要な場合は、ロギングなどの他の⽅法を選択しなければならない。
Google SRE handbook では、Saturation（飽和）を
追加した4つのメトリクスをゴールデンシグナルと呼んでいます

33. @superbrothers
単純な平均の問題点
単純平均（mean）は、外れ値の影響を受けやすく、1つか2つの極端な値があるだけで
平均値が⼤きく違ってしまう。
33アンスコムの例 - Wikipedia
4つのデータセットは全く異なるグラフですが、
単純平均の値はすべて同じになるのです 😱

34. @superbrothers
最悪を知る
あるサーバのレイテンシの中央値が1秒であることが分かったとしても、10秒以上のレイテンシを
経験しているユーザにとっては何の意味もない。
▶ パーセンタイル（百分位数）
+ 99パーセンタイル（P99）は、ユーザの 99% が経験しているより⼤きな値であることを⽰す
+ P99 の値より⾼いレイテンシを経験しているのはユーザの 1% とも⾔える
34
⽣データ 10秒間隔での単純平均 99パーセンタイル
https://igor.io/latency/
P50 は中央値です！

35. @superbrothers
メトリクスのダッシュボードによるグラフ化
メトリクスを⽤いて実際には何をするのかといえば、メトリクスをグラフ化し、それらを
ダッシュボードにグループ化して、場合によってはメトリクスに基づいてアラートを通知する。
▶ サービスには「RED パターン」、リソースには「USE パターン」をしっかり活⽤する
▶ クラスタからノード、Pod、コンテナというように、より広い範囲から狭い範囲に
絞り込んで調査できるようにする
35
The RED Method: key metrics for microservices architecture
すべてのサービスに標準のレイアウトを
用意するのがオススメ！

36. @superbrothers
メトリクスに基づくアラート
⼤規模な分散システムはほとんど常にサービスが部分的に劣化した状態にある。そのため、あるメ
トリクスが通常の制限範囲から外れるたびにアラートを出していたのでは、1⽇に何百回も
オンコールされることになってしまう。
▶ オンコールを地獄にしない
+ 緊急かつ重要で「対処可能な」アラートのみに限定する
+ オンコール対象とならない他のすべてのアラートは、⾮同期の通知を送信すれば⼗分
+ メール、Slack メッセージ、GitHub イシューほか
▶ 間違ったアラートの排除
+ システムに対する信頼性を低下させて、無視しても問題ないと⼈間を油断させてしまう
36
SN 比（信号対雑音比）が高い状態を維持しよう！

37. @superbrothers
そのほか、PFN での取り組み

38. @superbrothers
アラートから GitHub イシューを作成
https://github.com/pfnet-research/alertmanager-to-github
▶ Alertmanager からの Webhook を受け取って GitHub イシューを作成する
+ 新しいアラートから GitHub イシューを作成
+ アラートが resolved ステータスになるとイシューをクローズ
+ アラートが再度 firing ステータスになるとイシューをリオープン
38

39. @superbrothers
ノードの Conditions の変化によりオペレーションを実⾏
https://github.com/pfnet-research/node-operation-controller
▶ ノードのConditionsを監視し、条件を満たすとそのノードのメンテナンス処理を
実⾏するPodを作成するコントローラ
▶ Conditions の変更には、 node-problem-detector やそれと連携する内製のツールを使⽤
39
アラート/サポートイシューのアサインをバランスよく⾏う
▶ 内製の task-assigner ツールを開発（クローズド）
▶ /assign コメントによるアサインもサポート
オンプレでべんりです！

40. @superbrothers
まとめ

41. @superbrothers
まとめ
▶ これまでのブラックボックス監視が「システムが正しく機能しているかどうか」を⽰すのに対し、
オブザーバビリティが確保された監視は「システムがどうして正しく機能しないのか」を⽰す
▶ クラウドネイティブな世界で重要な役割を果たすのが「メトリクス」
▶ メトリクス監視では、「Prometheus」がクラウドネイティブの世界で事実上の標準となっている
▶ オブザーバビリティに取り組むことは、事実とフィードバックに基づくチーム⽂化へと移⾏
▶ 重要なメトリクスに集中する。サービスの場合はリクエスト、エラー、持続期間（RED）、
リソースの場合は利⽤状況、飽和、エラー（USE）
▶ 単純な平均よりも最悪に注⽬する。それにはパーセンタイル（百分位数）を使⽤する。
▶ オンコールを地獄にしない、緊急かつ重要で「対処可能な」アラートのみに限定する
41

42. @superbrothers
Thanks / Question?
▶ Kazuki Suda, @superbrothers
▶ Slide: https://speakerdeck.com/superbrothers/
42