Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOpsとSREのために知るべき3つの原則 〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜

Seigo Watanabe
July 10, 2023
7.2k

DevOpsとSREのために知るべき3つの原則 〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜

Seigo Watanabe

July 10, 2023
Tweet

More Decks by Seigo Watanabe

Transcript

  1. #devio2023 開発環境 = Software Development Life Cycle 機能実装 コード記述 (IaC含む)

    コミット ・PR コードのレ ビュー テストビル ド デプロイ用 ブランチへ のマージ 本番ビルド 本番ビルド (アプリケー ション)に対 するテスト 本番環境へ のデプロイ 本番環境に てアプリ ケーション が動作して いる状態 実行状態の 観測・計測 本番環境へ の操作・運 用 インシデン ト対応 ポストモー テム 計測結果や フィード バックを受 けての次の 開発計画 Code Review Build Test Deploy Run Measure Improve Plan Repeat Operate 4
  2. #devio2023 開発者は忙しい • 開発のCI/CDループ。 毎⽇コードは書かれている • 問題があるコードは、即座に 顧客体験の悪化を引き起こす • だから、⽇々のコードレビューは

    本当に重要 • しかし、組織の事情によっては そこを⼗分に⼿厚くできない • 規模に依らずそんな組織が多い • なぜなら、開発者たちは やることが多く忙しいからだ 5 https://youtu.be/uC2jIRm0eAM(意訳)
  3. #devio2023 「速いは正義」という時代 | ⾚の⼥王仮説 • 開発速度 ≒ 変化する / 変化に対応する速度

    • 処理性能(レスポンスタイム)の速さ ⽇々⾛り続けないと ついていけない! 7 https://agora-web.jp/archives/516141.html https://www.genpaku.org/alice02/alice02j.html “ここではだね、 同じ場所にとどまるだけで、 もう必死で走らなきゃいけないんだよ” ———— ルイス・キャロル 「鏡の国のアリス」
  4. #devio2023 わかりにくいと⾔われたので で例えてもらった 4⼈1チーム同⼠での対戦 • 敵を2体倒し、 ⾃分ひとりで最前線をキープ • 敵も同様に⾃拠点に攻め込んでいて、 味⽅ 3

    vs 敵 2 で状況が膠着 (通常はこのままでも勝てる) • ⾃分が戻ることで 4 vs 2、 早期解決を⽬指せるが、 せっかく上げた戦線を下げることになる ⾃分ひとりで前線を維持し続けるか? 拠点に戻り、戦況とチーム体制を整えてから 再び前線を上げるか? https://commons.wikimedia.org/wiki/Main_Page 10 ※画像はイメージです
  5. #devio2023 そんな装備で大丈夫か? 短期的には良い判断だが、 その後⽣産性はじわじわ低下 短期的には⽣産性が落ちるが、 中⻑期的には こちらが上に いわゆる「⽊こりのジレンマ」 ぼろぼろの斧で ⽊を切り続けるのか?

    それとも まず斧を研いで、 その後の⽊を切るペースを あげるか? https://webtan.impress.co.jp/e/2017/06/27/26149 http://elshaddai.jp/elshaddai_crim/freedeta.html 11 ➡ 課題を感じているなら 「斧を研ぐ」時間をとる検討を
  6. #devio2023 今年の 2 ⽉から毎⽉開催 • 2023/02/03 • 2023/03/03 • 2023/04/07

    • 2023/05/10 • 2023/06/07 • 2023/07/06 ご参加‧ご協⼒いただいた皆様⽅、 本当にありがとうございました! 14
  7. #devio2023 紹介する「 3 つの原則」 Refactoring / SDLC / ⽊こりのジレンマ /

    ⾚の⼥王仮説 DevOps / SRE / Platform Engineering CALMS / Culture / Automation / Lean / Measurement / Share Think big, act small, fail fast, learn rapidly DORAメトリック / 可観測性(Observability) / 監視(Monitoring) IaC / SaaS / マネージドサービス / ⼼理的安全性 / Phoenix Project 18
  8. #devio2023 ⾃⼰紹介 ▸ クラスメソッド株式会社 アライアンス事業部 エンジニアG ◦ DevOpsソリューション ◦ Google

    Cloud ▸ 指向 : 運⽤‧モニタリング‧SRE ▸ 好きなAWSサービス : ACM‧Route 53‧ CloudWatch Metric Stream ▸ 好きなGoogle Cloudサービス : Compute Engine Live Migration 22 渡辺聖剛 (Seigo Watanabe) https://dev.classmethod.jp/author/watanabe-seigo/ https://www.credly.com/users/seigo-watanabe.29d196c2 https://www.credential.net/profile/seigowatanabe992008/wallet
  9. #devio2023 リファクタリング 外部からみた動作を変更せずに 既存のコード本体を再構築し その内部構造を置き換える コーディング技術 https://refactoring.com/ “Refactoring is a

    disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” ———— refactoring.com 25 この考え方を 開発環境そのものにも適応する
  10. #devio2023 「開発環境」を「リファクタリング」する SDLCの全体の流れを変えずに パーツ単位で改善していく • ⼿段を変える ◦ ⼿作業 ➡ ⾃動化

    • 道具(ツール)を変える ◦ 使いにくい道具 ➡ 使いやすい道具 基本原則:影響範囲を「最⼩に」抑える (ゼロにする、ではない!) 26
  11. #devio2023 最⼩単位で⼩さく始める:リーン Lean “Think big, act small, fail fast; learn

    rapidly” ———— Lean Software Development: An Agile Toolkit 27
  12. #devio2023 ちょっと並べ替えて ❏ Culture (⽂化) ❏ Automation (⾃動化) ❏ Lean

    (リーン) ❏ Measurement (測定) ❏ Share (共有) 29
  13. #devio2023 実は ❏ Culture (⽂化) ❏ Automation (⾃動化) ❏ Lean

    (リーン) ❏ Measurement (測定) ❏ Share (共有) 30
  14. #devio2023 実は : CALMSフレームワーク ❏ Culture (⽂化) ❏ Automation (⾃動化)

    ❏ Lean (リーン) ❏ Measurement (測定) ❏ Share (共有) https://www.atlassian.com/ja/devops/frameworks/calms-framework DevOpsフレームワークのひとつ 31
  15. #devio2023 CALMSの提唱者 : Jez Humble 著作(共著)➡ https://itrevolution.com/articles/devops-culture-part-1/ https://amzn.asia/d/iGFJIVa https://www.oreilly.co.jp/books/9784873117744/ https://book.impress.co.jp/books/1118101029

    33 “After the first US based Devopsdays in Mountainview 2010 Damon Edwards (@damonedwards) and I coined the acronym CAMS, which stands for Culture, Automation, Measurement and Sharing. Jez Humble (@jezhumble) later added an L, standing for Lean, to form CALMS.” ———— John Willis “DevOps Culture (Part 1)”
  16. #devio2023 Q : DevOpsとは... 1. Dev と Ops 2. Dev

    も Ops も 3. Dev の Ops 4. Dev が Ops ある意味 全部 正解 34
  17. #devio2023 Automation (⼀般的な定義) “⾼度に⾃動化された⼿段によって、ひとの介⼊を最⼩限に抑えつつ ⼿続き(プロセス)を操作または制御する技術‧⽅法‧システム” ❌ (スクリプトなどで)⾃動化すること ⭕ ⼿動で⾏う作業を最⼩化すること Automation

    Definition & Meaning | Dictionary.com ➢ the technique, method, or system of operating or controlling a process by highly automatic means, as by electronic devices, reducing human intervention to a minimum. ———— dictionary.com 37
  18. #devio2023 「⼿動で⾏う作業を最⼩化すること」によって... • ⼈的要因による事故やミスを抑制 ➡ 正確性‧再現性が向上 • 作業時間‧実⾏時間の短縮 • 作業の持続可能性が向上

    (属⼈スキルからの脱却) https://www.atlassian.com/ja/devops/what-is-devops 39 “DevOpsの基本的なプラクティスは、ソフトウェア開発ライフサイクルを 可能な限り自動化することです。これにより、開発者がコードを書いたり、 新しい機能を開発したりする時間が増えます。 自動化は CI/CD パイプラインの重要な要素であり、人的ミスの削減と チームの生産性向上に役立ちます。” ———— 自動化 - 5 つの重要な DevOps の原則 | Atlassian
  19. #devio2023 lean (リーン) そもそもの⾔葉の意味: • 贅⾁‧脂肪が少ない、無駄がない • (含有量が)希薄である リーンソフトウェア開発: •

    「価値を⽣み出さないもの」を省く • サイクルタイムの短縮 • 継続的にプロセスを改善 DevOps的⽂脈: • 継続的な改善に努める • (その際の)失敗を受け⼊れる ➡ 「不具合の早期発⾒‧早期対処」 https://www.dictionary.com/browse/lean https://en.wikipedia.org/wiki/Lean_software_development https://www.atlassian.com/ja/devops/frameworks/calms-framework 42 “Think big, act small, fail fast; learn rapidly” ———— Lean Software Development: An Agile Toolkit
  20. #devio2023 Lean (リーン) • 継続的な改善の実⾏が前提 • ⼤局的にみて「⽬的地」を設定 • ⼩規模のところから段階的に ◦

    対象プロセス‧ステップ ◦ 対象システム ◦ 関わる組織‧メンバー⼈数 • 効果を⾒極め、「うまく⾏かないところ」は次で修正 https://www.dictionary.com/browse/lean https://en.wikipedia.org/wiki/Lean_software_development https://www.atlassian.com/ja/devops/frameworks/calms-framework “Think big, act small, fail fast; learn rapidly” ———— Lean Software Development: An Agile Toolkit 43
  21. #devio2023 Think big, act small • いま⾏っている「マニュアル作業」をそのまま⾃動化すると、 その作業の本質が覆い隠される危険性がある ◦ ⾃動化しようとしているその作業、

    最初は(本来は)ワークアラウンドのはずではなかったですか? • 全体(big)をみた上で、 なるべく局所(small)的な変更‧導⼊を⼼がけましょう https://www.oreilly.co.jp/books/9784873119137/ “問題の重大性を覆い隠すようなスクリプトを書くことは、 本当の問題を修正しないため中長期的には無駄であり、さらに 潜在的には後にもっと問題を引き起こす要因となりえます。” ————John Looney, 「サイトリライアビリティワークブック」(一部要約) 46
  22. #devio2023 計測(Measure) = 記録(Record) いま(現状)がどうであるかを 正しく理解‧把握するための⾏動 計測しないと... • 今がどうなっているのか分からない •

    → 過去と差もわからない、将来も予測できない https://www.linkedin.com/pulse/you-cant-improve-what-measure-raymond-bednar 48 “Measurement is the first step that leads to control and eventually to improvement.” ———— Dr. H. James Harrington
  23. #devio2023 49 古典 : いわゆる「推測するな、計測せよ」 https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6 http://www.lysator.liu.se/c/pikestyle.html “ルール1: (略)どこがボトルネックな のかをはっきりさせるまでは、推測を

    行ったり、スピードハックをしてはなら ない” “ルール2: 計測すべし。計測するまでは 速度のための調整をしてはならない。 (後略)” ————Robert "Rob" C. Pike “Notes on Programming in C” 1989
  24. #devio2023 Measurement (計測) 50 アプリケーションの挙動 ➡ APM (Application Performance Management)

    インフラ/システムの挙動 ➡ システム監視 (CPU/メモリ/システムログ etc...) 実⾏環境の挙動の監視 (異常の発⽣➡即時アラート) Infrastructure Application APM System Monitoring Dashboard
  25. #devio2023 Measurement (計測) 51 Code Review Build Test Deploy Run

    Measure Improve Plan Operate こちらは 誰が⾒ていますか? Infrastructure Application APM System Monitoring Dashboard SDLC
  26. #devio2023 DORAメトリック DevOps 組織の有効性を測定する 4 つの指標 (DORA = DevOps Research

    and Assessment) 速度 1. 変更のリードタイム(commit → deploy) 2. デプロイの頻度 安定性 3. 変更障害率(障害に繋がったデプロイの割合) 4. サービス復元時間(MTTR) https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-according-to-dora 52
  27. #devio2023 計測(Measure) ≠ 監視(Monitor) 監視 (Monitor) : ⽬的をもって閾値を設定、超過/下回ったら警報 計測 (Measure)

    : 「いまがどうであるか」の測定 • 現状把握のための計測(Measure)を! ◦ 警報ありきの監視(Monitor)ではありません • 持続性のある計測⽅法の採⽤を! ◦ Excelに⼿⼊⼒強制: 労⼒と⽐較して、正確な情報が採れる保証がありません 53
  28. #devio2023 可観測性(Observability) 異常検知‧警報のためでなく、 「いまシステムがどうであるか」を把握するための 計測 (Measurement) Metric / (Event)Log /

    Trace etc... ➡ そのためのもの! https://www.oreilly.co.jp/books/9784814400126/ 54 “システムがどのような状態になったとしても、それがどんなに 斬新で奇妙なものであっても、どれだけ理解し説明できるかを 示す尺度です” ————Charity Majors、Liz Fong-Jones、George Miranda「オブザーバビリティ・エンジニアリング」
  29. #devio2023 念のため : 監視(Monitoring)は、それはそれで必要 55 https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/ 既知の異常については 積極的に監視してアラートを 仕掛けましょう! “Monitoring

    means that you already know what is important. (何が重要でどうなったら異常なのか、 既に分かっている場合にのみ 監視は有効だ)” —— Dr. Werner Vogels
  30. #devio2023 ここまでのまとめ ❏ Culture (⽂化) ❏ Automation (⾃動化) ❏ Lean

    (リーン) ❏ Measurement (測定) ❏ Share (共有) https://www.atlassian.com/ja/devops/frameworks/calms-framework 反復的な手作業の排除 再現性・正確性の向上 継続的な改善を前提 最小限の範囲から段階的に 現状の状況把握・可視化 (詳細よりも大局を意識) どのように始めるか・進めるか 何から始めると効果的か・行った効果は 57
  31. #devio2023 1. Dev と Ops ➡ 本来の定義 https://www.techtarget.com/whatis/reference/The-history-of-DevOps-A-visual-timeline “DevOps is

    a shared philosophy in which development and operations teams work together. The practice promotes better communication and collaboration between those two teams, as well as other teams in an organization, such as security.” ———— The history of DevOps: A visual timeline 59
  32. #devio2023 2. Dev も Ops も ➡ 現在のありがちな状況‧‧? ひとり(or ⼩数)の担当者が

    なんでもやる • 開発 • 運⽤ • etc https://en.wikipedia.org/wiki/Tree_swing_cartoon https://medium.com/@thx2001r/the-project-cartoon-root-cause-5e82e404ec8a 60
  33. #devio2023 3. Dev の Ops ➡ 現在の理想像 Operations for Development

    Lifecycle 「開発サイクルを  うまく回す(運⽤する)」 MLOpsやDataOpsなど 最近の造語にもニュアンス合致 61
  34. #devio2023 まず : Measurement 可観測性(Observability)を向上させよう • システムに対して • SDLC全体に対して •

    継続的な計測と可視化‧記録 • ⼈の⼿による現状把握も「可観測性の第⼀歩」 どこに対して⾏うべきか / ⾏った結果どうだったか すべて分かる状態にしてから進めるのが理想です とはいえ、そこで詰まらないように! 64
  35. #devio2023 ⼿段:Automation Adobe Fireflyによる⽣成 - “Illustration of a car driven

    by a humanoid robot” 66 なるべく⼈の⼿を介さないような⽅向性 まず⼿順を整理してから⾏おう(テスト駆動) ⾃動化そのものが⽬的にならないように! 問 : ⾃動運転⾞両にほんとうに必要なものはなんでしたか?
  36. #devio2023 これもAutomation ⼿作業 (⾮コード化処理 / ⼿動実⾏) コード (スクリプト / IaC

    / ⾃動実⾏) ⼿製ツール スクリプト 既製品 (OSS / SaaS / マネージドサービス ) 67
  37. #devio2023 SaaS‧マネージドサービス推奨 • OOTB (Out-of-the-box) で すぐ使える ◦ ドキュメントも揃っている •

    インフラも運⽤も込み ◦ メンテナンスや障害対応に ⼯数を割かなくて良い • ツール側で勝⼿に進化 ◦ 意図しない進化のリスクも • 「継続的な⾒直し」がしやすい ◦ 利⽤契約 (OpEx) がほとんど 買い切り (CapEx) ではない 68
  38. #devio2023 こんなことをやってくれるSaaSがあります • アプリケーションのエラー発⽣ → トレースログの可視化 • IaCコードのセキュリティスキャン、評価 • フロントエンドテストの定期実⾏

    • システムやアプリケーションメトリックの異常なふるまいの検知 • 様々な出⼒‧計測結果を⼀元で可視化 • IaCステータス管理 • Git commitから⾃動でbuild → test → deploy実⾏ • フィーチャーフラグの管理 • 認証認可基盤 70
  39. #devio2023 案 1 : Platform Engineering 乱暴にまとめれば、 SDLCで利⽤するツール群を 管理運⽤する ...という概念に

    名前をつけたもの https://platformengineering.connpass.com/event/275718/ https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai?slide=8 “(さまざまな意見のまとめとして) 開発者体験と生産性を向上させるために セルフサービスで利用できるツール チェーンとワークフローを設計構築する 分野” ———— Platform Engineeringとは - Platform Engineering Meetup #1 74
  40. #devio2023 (唐突ですが) 4. Dev が Ops ➡ SRE! SREの出発点は ソフトウェアエンジニア(開発者)

    開発者が、⾃⾝のサービス (サイト)の信頼性を 向上させるためのもの Operations by Software Developer https://www.oreilly.co.jp/books/9784873117911/ “SREとは、ソフトウェアエンジニアに 運用チームの設計を依頼したときに できあがるものです” ———— Benjamin Treynor Sloss, VP, Google / 「SREサイトリライアビリティエンジニアリング」 77
  41. #devio2023 class SRE implements interface DevOps https://www.oreilly.co.jp/books/9784873119137/ https://www.oreilly.co.jp/books/9784873119618/ SDLCに「信頼性」のボトルネックがあるのなら その解決はSREの守備範囲

    “SREがパイプラインの後半部分に 集中できるのは、Google社内では 前半のフェーズで問題が解決されて いるか、それらのフェーズは 他のチームに委任されるからです。 (略)SREは、目的を達成するための 手段となるのであれば、 パイプラインの前半部分にも 首を突っ込みます。” ———— Thomas A. Limoncelli / 「SREの探求」 78
  42. #devio2023 CALMSの残りのふたつ ❏ Culture (⽂化) ❏ Automation (⾃動化) ❏ Lean

    (リーン) ❏ Measurement (測定) ❏ Share (共有) 82
  43. #devio2023 Share(共有) = サイロの撤廃 • チーム内で情報を共有する ◦ 開発〜運⽤〜ビジネス • 共有のための時間も改善の対象

    ◦ 「その準備は必要ですか?」 ◦ 「どんな価値を⽣みますか?」 ➡ 全員が同じツールを使い、 専⽤のダッシュボードで現状把握 ➡ 忌憚のないディスカッション → ⼼理的安全性 ➡ チーム全員でDevOps⽂化を共有 https://www.pexels.com/photo/people-taking-slices-of-pizza-from-plate-5907904/ 83
  44. #devio2023 Culture(⽂化) 『DevOps』が効果を発揮するためには、 組織の⽂化的⼟壌、 特に『⼼理的安全性』が不可⽋です ※ 正直なところ、導⼊難易度はかなり⾼い https://www.atlassian.com/ja/devops/what-is-devops/devops-culture 85 “組織が

    DevOps アプローチに移行するのに役立つ ツールやテクノロジーは用意されています。 しかし、文化を変えないままツールやテクノロジーを 変えることは、基盤にある弱点に対処せずにうわべだ けを変えることになります”
  45. #devio2023 [PR] クラスメソッド 内製化⽀援サービス • 体制づくり • スキル開発‧定着 • ビジネス開発

    3つの領域から 内製化を実現するための ⾃⾛に向けた⽀援 https://classmethod.jp/services/insource/ https://classmethod.jp/services/insource/step0/ 86
  46. #devio2023 このセッションで紹介したキーワード Refactoring / SDLC / ⽊こりのジレンマ / ⾚の⼥王仮説 DevOps

    / SRE / Platform Engineering CALMS / Culture / Automation / Lean / Measurement / Share Think big, act small, fail fast, learn rapidly DORAメトリック / 可観測性(Observability) / 監視(Monitoring) IaC / SaaS / マネージドサービス / ⼼理的安全性 / Phoenix Project 88
  47. #devio2023 このセッションで紹介したキーワード Refactoring / SDLC / ⽊こりのジレンマ / ⾚の⼥王仮説 DevOps

    / SRE / Platform Engineering CALMS / Culture / Automation / Lean / Measurement / Share Think big, act small, fail fast, learn rapidly DORAメトリック / 可観測性(Observability) / 監視(Monitoring) IaC / SaaS / マネージドサービス / ⼼理的安全性 / Phoenix Project 89
  48. #devio2023 TL;DR • ⽇々の開発をRefactoringしよう ◦ 進め⽅、⼿段 ◦ DevOpsの原則‧CALMSフレームワーク ◦ 「⽊こりのジレンマ」を回避しよう

    • 特に重要 ➡ リーン(Lean)の考え⽅ ◦ 技術的にも⽅法的にも ◦ Automationを念頭にMeasurementしながら ◦ SaaS‧マネージドサービスも積極的に検討を • 根幹には⽂化(Culture)がある ◦ ⽂化のためにはShareが必要 ◦ みなが同じ画⾯を⾒て同じ⾔葉を話そう ◦ そのためのツール(⼿段)選定を 90
  49. #devio2023 成功させるには “短距離⾛ではなく、マラソンである” “Remember: it's a marathon, not a sprint”

    91 https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board
  50. #devio2023 参考 (1) ❏ HTTP Archive: State of the Web

    https://httparchive.org/reports/state-of-the-web#bytesTotal ❏ 資本主義は「⾚の⼥王」である | アゴラ ⾔論プラットフォーム https://agora-web.jp/archives/516141.html ❏ 「⽊こりのジレンマ」という寓話|斧を研ぐ時間がなぜ重要なのか? https://webtan.impress.co.jp/e/2017/06/27/26149 ❏ Refactoring https://refactoring.com/ ❏ CALMS フレームワーク | Atlassian https://www.atlassian.com/ja/devops/frameworks/calms-framework ❏ DevOps Culture (Part 1) - IT Revolution https://itrevolution.com/articles/devops-culture-part-1/ ❏ DevOps の原則 | Atlassian https://www.atlassian.com/ja/devops/what-is-devops ❏ Lean software development - Wikipedia https://en.wikipedia.org/wiki/Lean_software_development
  51. #devio2023 参考 (2) ❏ You can’t improve what you can’t

    measure https://www.linkedin.com/pulse/you-cant-improve-what-measure-raymond-bednar ❏ UNIX哲学 - Wikipedia https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6 ❏ Notes on Programming in C http://www.lysator.liu.se/c/pikestyle.html ❏ Google Cloud で実⾏されている DevOps 組織の有効性を評価する | Google Cloud 公式ブログ https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-accordin g-to-dora ❏ The history of DevOps: A visual timeline https://www.techtarget.com/whatis/reference/The-history-of-DevOps-A-visual-timeline ❏ OPEX(オペックス)とは? 意味やCAPEX(キャペックス)との違いを解説 | クラウドERP実践ポータル https://www.clouderp.jp/blog/what-is-capex-opex ❏ Platform Engineeringへの招待 - Speaker Deck https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai?slide=8 ❏ DevOps ⽂化 | Atlassian https://www.atlassian.com/ja/devops/what-is-devops/devops-culture
  52. #devio2023 参考 (3) ❏ AWS re:Invent 2019 - Andy Jassy

    による基調講演 | AWS (⽇本語字幕) - YouTube https://www.youtube.com/watch?v=uC2jIRm0eAM ❏ オペレーション、監視(Monitoring)、可観測性(Observability)… AmazonのCTOはAWS re:Invent 2020のキーノー トでどう語ったか? キーワードを拾ってみた #reinvent | DevelopersIO https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/ ❏ なぜそれをやってるの?「太陽と祈祷師」の寓話にみる因果関係の話 | DevelopersIO https://dev.classmethod.jp/articles/202004-dilemma-of-the-sun-and-the-shaman/ ❏ SRE を成功させるには、まず計画を⽴てることが⼤事 | Google Cloud 公式ブログ https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board
  53. #devio2023 参考 (書籍) ❏ Amazon | The Devops Handbook https://www.amazon.co.jp/dp/1942788002

    ❏ O'Reilly Japan - リーンエンタープライズ https://www.oreilly.co.jp/books/9784873117744/ ❏ LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活⽤が組織変⾰を加速する - インプレスブックス https://book.impress.co.jp/books/1118101029 ❏ O'Reilly Japan - オブザーバビリティ‧エンジニアリング https://www.oreilly.co.jp/books/9784814400126/ ❏ 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/