可観測性 (o11y) みっつのアプローチと ひとつの⽬的地 〜監視とどうすみ分ける？〜 2024.07.18 渡辺聖剛@アライアンス事業部

#cm_odyssey みなさん、  監視してますか！（挨拶 2

#cm_odyssey 監視 = 問題 (異常) を⾒つけるための⼿段 運⽤に⽀障が及ぶような 問題‧異常の発⽣を 検知する ● リソースの停⽌ (機器の故障、回線断) ● 処理の停⽌/遅延/エラー ● リソースの利⽤期限 (証明書やライセンス) ● etc. “監視とは 情報収集を行った結果に応じて 適切な宛先に発報すること” ———— IPA 非機能要求グレード 2018 04_項目一覧 C.1.3.1「運用監視」 計測 Measurement 検知 Detect/Alert 対処 Respond/Resolve 3 https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html 監視 monitoring 運用 operation

#cm_odyssey 監視と運⽤は切り離せない 「監視」を語るには まず「運⽤」から 4

#cm_odyssey みなさん、  監視してますか！（挨拶 運⽤ 5 (Take 2)

#cm_odyssey 「運⽤」とは ● 組織のリソースを活⽤し、 ● 対価や評価を得ることを ⽬的に、 ● 外部に対して、 ● 何らかのサービスを 継続的に 提供し続けること そのために必要な⾏動を 「運⽤」と定義する https://thinkit.co.jp/story/2010/12/16/1934?page=0%2C2 “(運用とは) サービスを継続的にデリバリ すること” ———— 波田野 裕一 / 運用設計ラボ合同会社 6

#cm_odyssey サービス(価値)のデリバリ https://www.irasutoya.com/ 価値の発揮 価値の創出 価値のデリバリ クライアント ➡ 開発 ➡ 運⽤ 7

#cm_odyssey SREの原則(Principle) #3 Well engineered software 巧妙な設計のソフトウェア ➡ 99.9% Well engineered operation 巧妙な設計の運⽤ ➡ 99.99% 良いサービスを作るだけでは 可⽤性に限界があるが、 良い運⽤は限界値を引き上げる https://www.usenix.org/conference/srecon17americas/program/presentation/rensin https://www.usenix.org/sites/default/files/conference/protected-files/srecon17_americas_slides_rensin.pdf “It takes well engineered operations -- including shared monitoring and fast rollbacks -- to get to 4 9” ———— David K. Rensin, Sr. Director of Engineering at Google 8

#cm_odyssey 運⽤の質 ➡ サービス価値に直結 Quality Value Operational Excellence オペレーショナル‧エクセレンス 9

#cm_odyssey 運⽤上の優秀性 - AWS Well-Architected 「運⽤上の優秀性」を  向上させる ➡ 運⽤の質が向上する ➡ サービスの価値が向上する https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/operational-excellence.html “優れたカスタマーエクスペリエンスを 着実に提供しながら、 ソフトウェアを正しく構築するために 取り組むこと” (a commitment to build software correctly while consistently delivering a great customer experience.) ———— 運用上の優秀性 / AWS Well-Architected Framework 10

#cm_odyssey ほかにも ● Google Cloud アーキテクチャ フレームワーク ● Microsoft Azure Well-Architected Framework ● Oracle (OCI)、Alibaba ... クラウドプラットフォームの 共通認識的な⽤語といえる （でも定義はまちまち） https://cloud.google.com/architecture/framework/operational-excellence?hl=ja https://learn.microsoft.com/ja-jp/azure/well-architected/operational-excellence/principles 11

#cm_odyssey どうすれば / 何をすれば 「運⽤上の優秀性」は 向上するのか... 12

#cm_odyssey 今⽇お話ししたいこと： The Journey to Operational Excellence 13

#cm_odyssey 登壇者紹介 14 2021 APN AWS Top Engineer / ALL AWS Certifications Engineer 2022 APN ALL AWS Certifications Engineer 2023,2024 Japan AWS All Certifications Engineer 2019 Mackerel Ambassador 2023 New Relic Partner Trailblazer https://dev.classmethod.jp/author/watanabe-seigo/ https://www.credly.com/users/seigo-watanabe.29d196c2 ▸ クラスメソッド株式会社 アライアンス事業部 ▸ 指向 : 運⽤‧モニタリング‧SRE ▸ 好きな AWS サービス : Certificate Manager (ACM) Route 53 CloudWatch metric streams ▸ 好きな Google Cloud サービス : Compute Engine Live Migration Cloud Operations suite ▸ ネタを挟まないと死んじゃう病 渡辺聖剛 (Seigo Watanabe)

#cm_odyssey 本⽇のアジェンダ 1. イントロダクション 2. The Journey to Operational Excellence 3. 運⽤と監視と可観測性 4. ツールの話（3つのアプローチ） 5. まとめ 15

#cm_odyssey おわび 本セッションのタイトルには 「 運⽤の優秀性」と記載されていますが、 AWS Well-Architected Framework に基づく 正しい表記は 「 運⽤上の優秀性」となります。 訂正しお詫びします。 https://pictogram2.com/?p=780 16

#cm_odyssey 今⽇お話ししたいこと The Journey to Operational Excellence (Ledet’s model of Operational Improvement) これをベースに お話しします https://www.assetivity.com.au/articles/reliability-improvement/reliability-in-operations/ 17

#cm_odyssey 運⽤上の優秀性 5つのステージ(Domain) Don’t fix it 《塩漬け》 Reactive 《故障対応》 Planned 《計画的対応》 Proactive 《定常的な開発》 Strategic 《戦略的事業展開》 Fix it after it breaks Fix it before it breaks Don't just fix it, improve it Asset management ( No claim, No fix ) 問題が⾒つかれば 対応する 計画どおりに 対応する 多くはこのどちらか‧両⽅ monitoring 監視 が必要 表⾯化するまで 対応しない monitoring 監視 ある意味 不要... 18 monitoring 監視 が必要...? ？

#cm_odyssey そもそも 「監視」って 何をするんだっけ... 19

#cm_odyssey 再掲) 監視 = 問題 (異常) を⾒つけるための⼿段 運⽤に⽀障が及ぶような 問題‧異常の発⽣を 検知する ● リソースの停⽌ (機器の故障、回線断) ● 処理の停⽌/遅延/エラー ● リソースの利⽤期限 (証明書やライセンス) ● etc. “監視とは 情報収集を行った結果に応じて 適切な宛先に発報すること” ———— IPA 非機能要求グレード 2018 04_項目一覧 C.1.3.1「運用監視」 計測 Measurement 検知 Detect/Alert 対処 Respond/Resolve 20 https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html 監視 monitoring

#cm_odyssey 監視だけでは「計画」に対応できない (本来の意味での) 監視 ➡ 発⽣した異常を検知し通知 ● 特定の「ポイント」を監視 ● その範囲でしか予測不能 ➡ 複雑な未来予測や 現状分析を⾏うには 「監視」だけでは 不⼗分 https://commons.wikimedia.org/wiki/File:Axi sCCTV.jpg 21

“Monitoring means that you already know what is important. (監視は、何が重要かが 既に判明している場合に 意味を持つ)” ⸺ Dr. Werner Vogels     CTO, Amazon https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/

#cm_odyssey 監視だけでは「計画」に対応できない (本来の意味での) 監視 ➡ 発⽣した異常を検知し通知 ● 特定の「ポイント」を監視 ● その範囲でしか予測不能 ➡ 複雑な未来予測や 現状分析を⾏うには、 「監視」だけでは 不⼗分 https://commons.wikimedia.org/wiki/File:Axi sCCTV.jpg 23

#cm_odyssey 何が重要か分かってない場合 Observability / o11y 可観測性(オブザーバビリティ) 24

#cm_odyssey 可観測性(オブザーバビリティ) 可⽤性、拡張性、耐障害性、と同じように、 可観測性は「観測可能な性能」を意味する概念 ➡「システム内部情報がどれだけ⼊⼿可能か」の指標 Operation 運用 Observability 可観測性 monitoring 監視 25

#cm_odyssey 天気予報での「監視」と「可観測性」 https://www.flickr.com/photos/hiroooooki/821009 6693 監視（を行う） ● 気温や湿度、降⽔量、⾵速 などを定点観測 ● 注意報‧警報 ● ⾬が降ったら傘をさす ➡ 災害発⽣に備える‧回避する 可観測性（を高める） ● 観測網の構築‧⾼度化 ○ 観測点、センサー ○ 各種レーダーや⼈⼯衛星 ● 気象予測⽤の HPC 導⼊ ● 分かりやすい報道‧アプリ ➡ 予報精度の向上‧⻑期予報 ➡ 天気予報以外でも活⽤ 26

#cm_odyssey 運⽤上の優秀性 5つのステージ(Domain) Don’t fix it 《塩漬け》 Reactive 《故障対応》 Planned 《計画的対応》 Proactive 《定常的な開発》 Strategic 《戦略的事業展開》 Fix it after it breaks Fix it before it breaks Don't just fix it, improve it Asset management ( No claim, No fix ) 問題が⾒つかれば 対応する 計画どおりに 対応する 27 計画的に動くには、 より⾼い 「可観測性」が必要 どのステージでも 「監視」は必要 monitoring 監視 observability 可観測性 monitoring 監視

#cm_odyssey 「監視」と「可観測性」の役割分担 https://www.flickr.com/photos/39213183@N02/19 217073656 監視（を行う） ● システム障害に繋がる計測点を 継続的に監視 ● 異常を検知し発報 (アラート) ● アラートに基づく適切な対処 ➡ 障害発⽣に備える‧回避する 可観測性（を高める） ● 計装の導⼊ (インプリメント) ○ アプリ‧インフラストラクチャ ○ 各種エージェント‧プローブ ● ⾼機能な「ツール」 ● 検索‧分析‧可視化 ➡ システムの状態を常に把握 28 ➡「監視」以外でも活⽤

#cm_odyssey 「監視」以外の「可観測性」 ● ユーザーの快適さ（ UI/UX、レスポンス） ● コスト（利⽤費、環境負荷、運⽤負荷） ● 開発ライフサイクル（DORAメトリック） ● セキュリティ（技術的な共通点） Operation 運用 Observability 可観測性 monitoring 監視 29 運用の⼀部 (広義の監視)

#cm_odyssey 再掲）「運⽤」とは ● 組織のリソースを活⽤し、 ● 対価や評価を得ることを ⽬的に、 ● 外部に対して、 ● 何らかのサービスを 継続的に 提供し続けること そのために必要な⾏動を 「運⽤」と定義する https://thinkit.co.jp/story/2010/12/16/1934?page=0%2C2 “(運用とは) サービスを継続的にデリバリ すること” ———— 波田野 裕一 / 運用設計ラボ合同会社 30

#cm_odyssey 可観測性 = より多くの問題を監視可能に ● 「問題‧異常」の発⽣を 「監視」により検知する ● より多くの「問題‧異常」を 検知するために 「可観測性」を向上させる ● 多くの「問題‧異常」に 対処できるようになることで 「運⽤」の質が向上する ● 「サービス」の価値が クライアントに 正しく届けられる (デリバリ) “監視とは 情報収集を行った結果に応じて 適切な宛先に発報すること” ———— IPA 非機能要求グレード 2018 04_項目一覧 C.1.3.1「運用監視」 計測 Measurement 検知 Detect/Alert 対処 Respond/Resolve 31 https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html 監視 monitoring 運用 operation

#cm_odyssey 背景はわかった では どうやればいい？ 32

#cm_odyssey 可観測性の「実装 (インプリメント)」 [Proactive]‧[Strategic] ステージになると 道具(ツール)よりも それを使いこなすための 「⽂化」のほうが重要になる そのためにも、まず 環境の整備が先に必要 ➡ 「計装」の導⼊ “オブザーバビリティをうまく 実装できるかどうかは、適切な ツールを自由に使えるかどうかと 同じくらい、いやそれ以上に、 ソフトウェアの開発、配備、 デバッグ、保守の方法をサポート する 適切な文化的足場を備えて いるか どうかにかかっています” ———— Oreilly 「オブザーバビリティ・エンジニアリング」 Proactive 《定常的な開発》 Strategic 《戦略的事業展開》 33

#cm_odyssey 「計装」の導⼊ 計装 (Instrumentation) システムを観測し データを収集する仕組み ● メトリック (数値データ) ● ログ (テキストデータ) ● 分散トレーシング (処理の繋がり) 収集したデータは 可観測性ツールで分析‧可視化 https://commons.wikimedia.org/wiki/File:CCTV_Ca mera%27s.jpg 34

#cm_odyssey 計装と可観測性 計測 Measurement 収集 Send / Collect 検索 Query 分析 Analyze 可視化 Dashboard 検知 Detect / Alert 対処 Respond / Resolve 計装 Instrumentation 可観測性ツール observability platform 運用 operation 35

#cm_odyssey 3 種類の「計装」実装 ● OpenTelemetry (OTel) ○ CNCF による標準規格であり OSS 実装 ○ 各社からディストリビューションが公開 ● 可観測性ツールの独⾃実装 (Agent / SDK / Integration) ○ 各ツールのベンダーがメンテ‧公開しているもの ○ ツールとの互換性は最⾼ ○ 合成監視など SaaS タイプの計装も ● インフラストラクチャ‧プラットフォーム ○ クラウドインフラは初期状態で可観測性が⾼い状態 ○ OTel ディストロ、監視‧可観測性ツールも 36

#cm_odyssey 「計装」の増やし⽅ ● まずはインフラ‧プラットフォームを活⽤ ○ Amazon CloudWatch, Google Cloud Monitoring ... ● 現状と運⽤戦略にそった計装の選定 ○ OpenTelemetry ➡ ロックイン回避、対応環境 ○ 独⾃実装 ➡ 可観測性ツールの評価‧対応環境 ※最近の可観測性ツールはほぼほぼ OTel に対応  OTel ⾃体の開発‧進化も着々 37

#cm_odyssey ここまでのまとめ ● 開発された「良い価値」を、 クライアントに送り届けるのが 「運⽤」の役⽬ ● 監視は本質的に Reactive 、 計画的に運⽤するための可観測性 ● 運⽤上の優秀性を⾼めるため、 まず可観測性向上から！ ● 可観測性は監視のためのみならず ● クラウドインフラはもともと 可観測性が⾼い。活⽤を！

#cm_odyssey ちなみに : Ledet モデル⽈く Reactive ステージは 「Overtime Heroes」つまり 「常に働き続けるヒーロー」が必要 ⽇常的な運⽤に、特別な能⼒をもった 「ヒーロー」は不要 ※ヒーローがいないと対応できない  状態は避けるべき、という意味 Planned ステージで必要なのは ヒーローではなく 「 驚きがないこと (No Surprises) 」 https://www.assetivity.com.au/articles/reliability-improvement/reliability-in-operations/

#cm_odyssey 「ヒーロー」⽂化の弊害 “私がハワイに新婚旅⾏に⾏っていたとき、午前 3 時に CTO から電話で呼び出されたのを 覚えています。1 時間以上もサイトはダウンしたままで、誰もその原因を突き⽌められて いませんでした。 私は⽂句を⾔いました。 でも⼼の底では、密かにすごいと思っていたんです。 私は「必要とされていた」。私は特別な存在だったのです。 プロダクトマネジメントを任されたことがある⼈は、このパターンに⾒覚えがあるかも しれません。 ヒーロー⽂化はひどいものです。 会社にとっても良くない。 ヒーローにとっても良くない（燃え尽き症候群になる）。 先輩エンジニアが辞めない限りその組織の「ヒーロー」になるチャンスはない、と感じ て、後から来たエンジニアはひどく落胆します。 このパターンは完全に不要です。 しかしもっとも重要な ことは、それが「スケールしない」ことです。” ⸻ O’reilly 「オブザーバビリティ‧エンジニアリング」※⼀部抜粋‧編集 https://www.oreilly.co.jp/books/9784814400126/ https://dev.classmethod.jp/articles/202302-report-observability-engineering/

#cm_odyssey 結局は 可観測性ツールの選定問題 41

#cm_odyssey 可観測性ツールを採⽤する理由 ● 特定領域の機能に特化している ○ 全ての機能が1ヶ所にまとまる ○ 機能間の統合もすすんでいる ● Out-of-the-box で使い始められる ○ ドキュメントもそろっている ○ ツールの運⽤を外部委託できる ひとことで⾔うと 「頑張らなくて良い」 ⽇常的に使うためのツールは 気負いなく使える必要がある 42

#cm_odyssey 専⽤ツール (SaaS) を導⼊する強み https://forge-vtt.com/features “SaaS ソリューションを使うと、 特定の問題領域に特化した専門知識を、 自分でやるよりもずっと安く手に入れる ことができます” —— Mike Julian 「入門　監視」 43 それらも計算にいれた上で 評価‧判断を！

#cm_odyssey Gartner MQ for APM/o11y 2023 リーダーポジション (3 強) ● Dynatrace ● New Relic ● Datadog それぞれ可観測性に対する アプローチに特⾊がある 44

#cm_odyssey アプローチ 1 : インフラ運⽤ツールから 可観測性 オブザーバビリティ 開発(Dev) 運⽤(Ops) アプリ インフラ インフラ運⽤ツール が機能を増やした パターン ex) Datadog ‧細かなライセンス ‧インフラ運⽤担当  者を主ターゲット  にした機能開発 45

#cm_odyssey アプローチ 2 : アプリ開発ツールから 可観測性 オブザーバビリティ 開発(Dev) 運⽤(Ops) アプリ インフラ アプリ開発のための ツールが機能を増や したパターン ex) New Relic ‧IDE統合、 ‧アプリ開発者を  主ターゲットに  した機能開発 46

#cm_odyssey アプローチ 1‧2 可観測性 オブザーバビリティ 開発(Dev) 運⽤(Ops) アプリ インフラ ‧機能セットはおおよそ互⾓ ‧メンバーやチーム、  プロジェクトとの親和性で⽐較 47

#cm_odyssey アプローチ 3 : その他 他の分野に強みを持っていたツールが 機能を増やしたもの ● 運⽤オートメーション ● ログ分析 ● クラウドプラットフォーム ● 監視ツール‧開発ツール 汎⽤性に劣るかもしれないが特定領域で強⼒‧最適化 ex) Dynatrace Splunk / Sumo Logic Google Cloud Monitoring Mackerel / Sentry 48

#cm_odyssey いいのは分かるけど、 お⾦かかるのはちょっと... 49

#cm_odyssey (再掲) The Journey to Operational Excellence 50

#cm_odyssey 運⽤上の優秀性 ステージを上げる Don’t fix it 《塩漬け》 Reactive 《故障対応》 Planned 《計画的対応》 Fix it after it breaks Fix it before it breaks ( No claim, No fix ) 問題が⾒つかれば 対応する 計画どおりに 対応する 51 Proactive 《定常的な開発》 Strategic 《戦略的事業展開》 Don't just fix it, improve it Asset management observability 可観測性 monitoring 監視 常に開発を継続し 問題点を未然に つぶす 全てのコストを 戦略的に コントロールする

#cm_odyssey Coding - all day, every day “コードに問題があれば、 悪い顧客体験が 即座に引き起こされる” ⸻ Andy Jassy / AWS re:Invent 2019 https://www.youtube.com/watch?v=uC2jIRm0eAM 52

#cm_odyssey Shift-Left SDLCの早い段階(開発段階) で運⽤を考慮する (主にセキュリティ⽤語) そうすることで、 運⽤段階で実施することと ⽐べてトータルコストを 下げられる、という⼿法 https://cloud.google.com/blog/ja/products/identity-security/shift-left-on-google-cloud-security-invest-now-save-later 53

#cm_odyssey SREの原則(Principle) #3 の続き Well engineered software 巧妙な設計のソフトウェア ➡ 99.9% Well engineered operation 巧妙な設計の運⽤ ➡ 99.99% Well engineered Business 巧妙な設計のビジネス ➡ 99.999% https://www.usenix.org/conference/srecon17americas/program/presentation/rensin https://www.usenix.org/sites/default/files/conference/protected-files/srecon17_americas_slides_rensin.pdf “It takes well engineered operations -- including shared monitoring and fast rollbacks -- to get to 4 9” ———— David K. Rensin, Sr. Director of Engineering at Google 54 “... and a well engineered business to get 5 9’s. Usually around making hard choices about SLOs and SLAs” ———— David K. Rensin, Sr. Director of Engineering at Google

#cm_odyssey ツールの分断 = サイロ化のはじまり ひとつのサービスに 複数のツール ある事象を⽰す「ことば」が ツール間で異なる ➡ 翻訳が必要 ？迅速‧緊密な  コミュニケーションは可能？ Dev Ops Biz Gov Special Tool Awesome Tool Excellent Tool Power Tool Awesome Service 55

#cm_odyssey 「がんばりどころ」を減らす 共通に使えるツールを 選択‧導⼊することで、 コミュニケーションの際の 「翻訳」のコストが 削減できる 認知負荷を考慮すると Platform Engineering の 導⼊も検討の余地あり https://www.gartner.co.jp/ja/articles/what-is-platform-engineering Dev Ops Biz Gov Awesome Service UNITE TOOL 56

#cm_odyssey チームトポロジーと「認知負荷」 がんばる = どこかに無理が⽣じる 本来不要な「頑張り」は Toil と同じ Toil を減らす努⼒が Operational Excellence 向上に繋がります https://pub.jmam.co.jp/book/b593881.html “認知負荷を考慮しないと、 チームの責任範囲と担当領域は 広がりすぎることになる。 自分の仕事に熟達するだけの余裕が なくなり、担当業務のコンテキスト スイッチに悩まされる” —— 「チームトポロジー」 57

#cm_odyssey まとめ 58

#cm_odyssey 運⽤上の優秀性 5つのステージ(Domain) Don’t fix it 《塩漬け》 Reactive 《故障対応》 Planned 《計画的対応》 Proactive 《定常的な開発》 Strategic 《戦略的事業展開》 Fix it after it breaks Fix it before it breaks Don't just fix it, improve it Asset management ( No claim, No fix ) 問題が⾒つかれば 対応する 計画どおりに 対応する 常に開発を継続し 問題点を未然に つぶす 全てのコストを 戦略的に コントロールする 表⾯化するまで 何も対応しない ● 運⽤のステージに応じて必要な可観測性のレベルは異なる ● より「上」の運⽤ステージに⾄るには、運⽤だけでは⾜りない ● ツールの導⼊で「がんばらない」サービス展開を！ 59

#cm_odyssey 成功させるには “短距離⾛ではなく、マラソンである” “Remember: it's a marathon, not a sprint” 60 https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board

No content

#cm_odyssey APPENDIX

#cm_odyssey 参考 (1) The journey to operational excellence ❏ How operations can impact equipment reliability | Assetivity https://www.assetivity.com.au/articles/reliability-improvement/reliability-in-operations/ ❏ Create the environment for maintenance success | Assetivity https://www.assetivity.com.au/articles/maintenance-management/5-keys-to-lean-maintenance-and-im proving-maintenance-productivity-part-5-environment-for-success/ ❏ What is The Maintenance Maturity Model? And How is Digital Technology Changing It? | DigitalThinker https://digitalthinker.com/what-is-the-maintenance-maturity-model-and-how-is-digital-technology-cha nging-it/ 運⽤とは ❏ 明⽇の運⽤現場のために - 運⽤フレームワークという視点 | Think IT（シンクイット） https://thinkit.co.jp/story/2010/12/16/1934?page=0%2C2 ❏ 2015-03-27 ザ‧運⽤ 〜 運⽤とは何か、運⽤とはどのようであるべきか — OpsLab https://www.opslab.jp/publish/20150327-mspj.html

#cm_odyssey 参考 (2) DevOps / SRE ❏ Reliability When Everything Is a Platform: Why You Need to SRE Your Customers | USENIX https://www.usenix.org/conference/srecon17americas/program/presentation/rensin https://www.usenix.org/sites/default/files/conference/protected-files/srecon17_americas_slides_rensin .pdf ❏ SRE を成功させるには、まず計画を⽴てることが⼤事 | Google Cloud 公式ブログ https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board ❏ Google Cloud で実⾏されている DevOps 組織の有効性を評価する | Google Cloud 公式ブログ https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-accor ding-to-dora ❏ AWS re:Invent 2019 - Andy Jassy による基調講演 | AWS (⽇本語字幕) - YouTube https://www.youtube.com/watch?v=uC2jIRm0eAM

#cm_odyssey 参考 (3) 監視 / オブザーバビリティ ❏ オペレーション、監視(Monitoring)、可観測性(Observability)… AmazonのCTOはAWS re:Invent 2020のキー ノートでどう語ったか？ キーワードを拾ってみた #reinvent | DevelopersIO https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/ Platform Engineering ❏ Platform Engineeringへの招待 - Speaker Deck https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai ❏ プラットフォーム エンジニアリングに関する 5 つの誤解: プラットフォーム エンジニアリングとは⼀体なのか | Google Cloud 公式ブログ https://cloud.google.com/blog/ja/products/application-development/common-myths-about-platform-e ngineering ❏ Platform Engineeringを実現する上で重要な組織論「チームトポロジー」とは？ (1/4)|CodeZine（コードジン） https://codezine.jp/article/detail/19001

#cm_odyssey 監視 / オブザーバビリティ ❏ O'Reilly Japan - SLO サービスレベル⽬標 https://www.oreilly.co.jp/books/9784814400348/ ❏ O'Reilly Japan - オブザーバビリティ‧エンジニアリング https://www.oreilly.co.jp/books/9784814400126/ SRE / Platform Engineering ❏ O'Reilly Japan - SRE サイトリライアビリティエンジニアリング https://www.oreilly.co.jp/books/9784873117911/ ❏ O'Reilly Japan - サイトリライアビリティワークブック https://www.oreilly.co.jp/books/9784873119137/ ❏ O'Reilly Japan - SREの探求 https://www.oreilly.co.jp/books/9784873119618/ ❏ チームトポロジー - JMAM ⽇本能率協会マネジメントセンター 「⼈‧組織‧経営の変化」を⽀援するJMAMの書籍 https://pub.jmam.co.jp/book/b593881.html 参考 (書籍)