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

Slide 1

Slide 1 text

DevOpsとSREのために知るべき 3つの原則〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜 08 July 2023 渡辺聖剛＠クラスメソッド株式会社

Slide 2

Slide 2 text

#devio2023 Q : みなさんの職種(ロール)について 1. エンジニア・プログラマー 2. 技術責任者 3. 情報システム部門 2

Slide 3

Slide 3 text

#devio2023 早速ですが、⽇々の開発業務、忙しくないですか？

Slide 4

Slide 4 text

#devio2023 開発環境 = Software Development Life Cycle 機能実装コード記述（IaC含む）コミット・PR コードのレビューテストビルドデプロイ用ブランチへのマージ本番ビルド本番ビルド（アプリケーション）に対するテスト本番環境へのデプロイ本番環境にてアプリケーションが動作している状態実行状態の観測・計測本番環境への操作・運用インシデント対応ポストモーテム計測結果やフィードバックを受けての次の開発計画 Code Review Build Test Deploy Run Measure Improve Plan Repeat Operate 4

Slide 5

Slide 5 text

#devio2023 開発者は忙しい ● 開発のCI/CDループ。毎⽇コードは書かれている ● 問題があるコードは、即座に顧客体験の悪化を引き起こす ● だから、⽇々のコードレビューは本当に重要 ● しかし、組織の事情によってはそこを⼗分に⼿厚くできない ● 規模に依らずそんな組織が多い ● なぜなら、開発者たちはやることが多く忙しいからだ 5 https://youtu.be/uC2jIRm0eAM（意訳）

Slide 6

Slide 6 text

#devio2023 でも要求はどんどん増える : 2013 → 2023 https://httparchive.org/reports/state-of-the-web#bytesTotal デスクトップ ➡ 2.7倍モバイル ➡ 4.9倍サーバー側の処理内容 ➡ ????倍 6

Slide 7

Slide 7 text

#devio2023 「速いは正義」という時代 | ⾚の⼥王仮説 ● 開発速度 ≒ 変化する / 変化に対応する速度 ● 処理性能(レスポンスタイム)の速さ⽇々⾛り続けないとついていけない！ 7 https://agora-web.jp/archives/516141.html https://www.genpaku.org/alice02/alice02j.html “ここではだね、同じ場所にとどまるだけで、もう必死で走らなきゃいけないんだよ” ———— ルイス・キャロル「鏡の国のアリス」

Slide 8

Slide 8 text

#devio2023 ここで聞こえてくる「忙しすぎて、環境のメンテとかできないよ」との声

Slide 9

Slide 9 text

#devio2023 RPGにおける武器と狩り場のジレンマ ● はやく経験値や素材を稼ぎたい ● レベルアップなどの理由で、装備や狩り場が適正ではなくなったそのまま狩り続けるのか？それとも、拠点に戻って装備を整え適切な狩り場に移動する？ https://commons.wikimedia.org/wiki/File:LARP.jpg 9 ※画像はイメージです

Slide 10

Slide 10 text

#devio2023 わかりにくいと⾔われたのでで例えてもらった 4⼈1チーム同⼠での対戦 ● 敵を2体倒し、⾃分ひとりで最前線をキープ ● 敵も同様に⾃拠点に攻め込んでいて、味⽅ 3 vs 敵 2 で状況が膠着（通常はこのままでも勝てる） ● ⾃分が戻ることで 4 vs 2、早期解決を⽬指せるが、せっかく上げた戦線を下げることになる⾃分ひとりで前線を維持し続けるか？拠点に戻り、戦況とチーム体制を整えてから再び前線を上げるか？ https://commons.wikimedia.org/wiki/Main_Page 10 ※画像はイメージです

Slide 11

Slide 11 text

#devio2023 そんな装備で大丈夫か？短期的には良い判断だが、その後⽣産性はじわじわ低下短期的には⽣産性が落ちるが、中⻑期的にはこちらが上にいわゆる「⽊こりのジレンマ」ぼろぼろの斧で⽊を切り続けるのか？それともまず斧を研いで、その後の⽊を切るペースをあげるか？ https://webtan.impress.co.jp/e/2017/06/27/26149 http://elshaddai.jp/elshaddai_crim/freedeta.html 11 ➡ 課題を感じているなら「斧を研ぐ」時間をとる検討を

Slide 12

Slide 12 text

#devio2023 忙しいなかですがなんとかアップデートしてほしい... というわけで、開発環境を「リファクタリング」しませんか？

Slide 13

Slide 13 text

#devio2023 本⽇お話しすること https://dev.classmethod.jp/news/devops-webinar/ 13

Slide 14

Slide 14 text

#devio2023 今年の 2 ⽉から毎⽉開催 ● 2023/02/03 ● 2023/03/03 ● 2023/04/07 ● 2023/05/10 ● 2023/06/07 ● 2023/07/06 ご参加‧ご協⼒いただいた皆様⽅、本当にありがとうございました！ 14

Slide 15

Slide 15 text

#devio2023 ウェビナーアンケートより 15

Slide 16

Slide 16 text

#devio2023 ウェビナーアンケートより 16

Slide 17

Slide 17 text

#devio2023 今⽇お話しすること開発環境の「リファクタリング」どうやって進めましょう？ ● どこを ● どのように ● どうやって‧何を使って 17

Slide 18

Slide 18 text

#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

Slide 19

Slide 19 text

#devio2023 本⽇のゴール⽇々の開発の状況を思い返して「オレたちみんな、毎⽇たいへんなことやってんな...」「実はもっと楽に効率あげられるんじゃないかな？」と、思えるようになること 19

Slide 20

Slide 20 text

#devio2023 今⽇お話ししないこと ● SDLCステップごとの具体的な解決策の提⽰（語り尽くせません！） ● 具体的なツールの紹介（銀の弾丸はありません！！） ● 開発環境 ≠ コーディング環境（好きなIDEを使ってください！）（でもコーディングを助ける話はします） 20

Slide 21

Slide 21 text

#devio2023 こちらも是⾮視聴を！ AWS事業本部コンサルティング部 mokoさんのセッション勝⼿に姉妹編的なセッションだと思いました（ついさっきそう思いました

Slide 22

Slide 22 text

#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

Slide 23

Slide 23 text

#devio2023 [PR]【7/24（⽉）福岡】DevelopersIO 2023 福岡 https://dev.classmethod.jp/news/devio-2023-fukuoka/ 23

Slide 24

Slide 24 text

#devio2023 開発環境の Refactoring（リファクタリング） 1 1

Slide 25

Slide 25 text

#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 この考え方を開発環境そのものにも適応する

Slide 26

Slide 26 text

#devio2023 「開発環境」を「リファクタリング」する SDLCの全体の流れを変えずにパーツ単位で改善していく ● ⼿段を変える ○ ⼿作業 ➡ ⾃動化 ● 道具(ツール)を変える ○ 使いにくい道具 ➡ 使いやすい道具基本原則：影響範囲を「最⼩に」抑える（ゼロにする、ではない！） 26

Slide 27

Slide 27 text

#devio2023 最⼩単位で⼩さく始める：リーン Lean “Think big, act small, fail fast; learn rapidly” ———— Lean Software Development: An Agile Toolkit 27

Slide 28

Slide 28 text

#devio2023 さらに Automation ⾃動化 Measurement 計測‧測定 ● 「機械的に実⾏される所」を増やす ● 現状把握と効果測定 28

Slide 29

Slide 29 text

#devio2023 ちょっと並べ替えて ❏ Culture （⽂化） ❏ Automation （⾃動化） ❏ Lean （リーン） ❏ Measurement （測定） ❏ Share （共有） 29

Slide 30

Slide 30 text

#devio2023 実は ❏ Culture （⽂化） ❏ Automation （⾃動化） ❏ Lean （リーン） ❏ Measurement （測定） ❏ Share （共有） 30

Slide 31

Slide 31 text

#devio2023 実は : CALMSフレームワーク ❏ Culture （⽂化） ❏ Automation （⾃動化） ❏ Lean （リーン） ❏ Measurement （測定） ❏ Share （共有） https://www.atlassian.com/ja/devops/frameworks/calms-framework DevOpsフレームワークのひとつ 31

Slide 32

Slide 32 text

#devio2023 つまり DevOpsの原則‧フレームワークにそって開発環境をリファクタリングしましょう ...という提案です 32

Slide 33

Slide 33 text

#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)”

Slide 34

Slide 34 text

#devio2023 Q : DevOpsとは... 1. Dev と Ops 2. Dev も Ops も 3. Dev の Ops 4. Dev が Ops ある意味全部正解 34

Slide 35

Slide 35 text

#devio2023 Automation/Lean/Measurement 2

Slide 36

Slide 36 text

#devio2023 Automation/Lean/Measurement 2

Slide 37

Slide 37 text

#devio2023 Automation （⼀般的な定義） “⾼度に⾃動化された⼿段によって、ひとの介⼊を最⼩限に抑えつつ⼿続き(プロセス)を操作または制御する技術‧⽅法‧システム” ❌ （スクリプトなどで）⾃動化すること ⭕ ⼿動で⾏う作業を最⼩化すること Automation Deﬁnition & 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

Slide 38

Slide 38 text

#devio2023 端的に⾔えば Automation ≠ オートメーション  とかく「如何にコードで置き換えるか」のような議論になりがちですが... 「その⼿続きは本当に必要なのか？」「もっと簡素化‧簡略化できるのでは？」「コードを書かなくても⽅法はあるのでは？」もっとも効果的な⽅法で「⼿作業を回避」することが重要です 38

Slide 39

Slide 39 text

#devio2023 「⼿動で⾏う作業を最⼩化すること」によって... ● ⼈的要因による事故やミスを抑制 ➡ 正確性‧再現性が向上 ● 作業時間‧実⾏時間の短縮 ● 作業の持続可能性が向上（属⼈スキルからの脱却） https://www.atlassian.com/ja/devops/what-is-devops 39 “DevOpsの基本的なプラクティスは、ソフトウェア開発ライフサイクルを可能な限り自動化することです。これにより、開発者がコードを書いたり、新しい機能を開発したりする時間が増えます。自動化は CI/CD パイプラインの重要な要素であり、人的ミスの削減とチームの生産性向上に役立ちます。” ———— 自動化 - 5 つの重要な DevOps の原則 | Atlassian

Slide 40

Slide 40 text

#devio2023 端的に⾔えば Automation ≠ 機能実装  サービスとして提供するためではなく、そのための⼿段を改善するのが⽬的 ➡「⼤きく完全なもの」は⽬指さない https://commons.wikimedia.org/wiki/File:160216-N-XT273-025_(25055215346).jpg 40

Slide 41

Slide 41 text

#devio2023 Automation/Lean/Measurement 2

Slide 42

Slide 42 text

#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

Slide 43

Slide 43 text

#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

Slide 44

Slide 44 text

#devio2023 Lean ➡ 「継続的な改善に努める」「⾃動化して終わり」ではない (ここも錯覚しやすいポイント) 「やっている時間が無い」からこそ持続可能な範囲で試⾏‧遂⾏することが重要 https://pxhere.com/en/photo/930678 44

Slide 45

Slide 45 text

#devio2023 「作ったものは壊したくない」➡ わかります！もちろん「全てを作り直せ」と⾔っているわけではないです残すべきものは残しましょう（その判断をしましょう）最初からライフサイクルを意識しておくといいですね！ 45

Slide 46

Slide 46 text

#devio2023 Think big, act small ● いま⾏っている「マニュアル作業」をそのまま⾃動化すると、その作業の本質が覆い隠される危険性がある ○ ⾃動化しようとしているその作業、最初は（本来は）ワークアラウンドのはずではなかったですか？ ● 全体(big)をみた上で、なるべく局所(small)的な変更‧導⼊を⼼がけましょう https://www.oreilly.co.jp/books/9784873119137/ “問題の重大性を覆い隠すようなスクリプトを書くことは、本当の問題を修正しないため中長期的には無駄であり、さらに潜在的には後にもっと問題を引き起こす要因となりえます。” ————John Looney, 「サイトリライアビリティワークブック」（一部要約） 46

Slide 47

Slide 47 text

#devio2023 Automation/Lean/Measurement 2

Slide 48

Slide 48 text

#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

Slide 49

Slide 49 text

#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

Slide 50

Slide 50 text

#devio2023 Measurement (計測) 50 アプリケーションの挙動 ➡ APM (Application Performance Management) インフラ/システムの挙動 ➡ システム監視 (CPU/メモリ/システムログ etc...) 実⾏環境の挙動の監視 (異常の発⽣➡即時アラート) Infrastructure Application APM System Monitoring Dashboard

Slide 51

Slide 51 text

#devio2023 Measurement (計測) 51 Code Review Build Test Deploy Run Measure Improve Plan Operate こちらは誰が⾒ていますか？ Infrastructure Application APM System Monitoring Dashboard SDLC

Slide 52

Slide 52 text

#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

Slide 53

Slide 53 text

#devio2023 計測(Measure) ≠ 監視(Monitor) 監視 (Monitor) : ⽬的をもって閾値を設定、超過/下回ったら警報計測 (Measure) : 「いまがどうであるか」の測定 ● 現状把握のための計測(Measure)を！ ○ 警報ありきの監視(Monitor)ではありません ● 持続性のある計測⽅法の採⽤を！ ○ Excelに⼿⼊⼒強制：労⼒と⽐較して、正確な情報が採れる保証がありません 53

Slide 54

Slide 54 text

#devio2023 可観測性(Observability) 異常検知‧警報のためでなく、「いまシステムがどうであるか」を把握するための計測 (Measurement) Metric / (Event)Log / Trace etc... ➡ そのためのもの！ https://www.oreilly.co.jp/books/9784814400126/ 54 “システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度です” ————Charity Majors、Liz Fong-Jones、George Miranda「オブザーバビリティ・エンジニアリング」

Slide 55

Slide 55 text

#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

Slide 56

Slide 56 text

#devio2023 ここまでのまとめ Automation‧Lean‧Measurement

Slide 57

Slide 57 text

#devio2023 ここまでのまとめ ❏ Culture （⽂化） ❏ Automation （⾃動化） ❏ Lean （リーン） ❏ Measurement （測定） ❏ Share （共有） https://www.atlassian.com/ja/devops/frameworks/calms-framework 反復的な手作業の排除再現性・正確性の向上継続的な改善を前提最小限の範囲から段階的に現状の状況把握・可視化 (詳細よりも大局を意識) どのように始めるか・進めるか何から始めると効果的か・行った効果は 57

Slide 58

Slide 58 text

#devio2023 ちょっと休憩：こちらの解答 1. Dev と Ops 2. Dev も Ops も 3. Dev の Ops 4. Dev が Ops 58

Slide 59

Slide 59 text

#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

Slide 60

Slide 60 text

#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

Slide 61

Slide 61 text

#devio2023 3. Dev の Ops ➡ 現在の理想像 Operations for Development Lifecycle 「開発サイクルをうまく回す(運⽤する)」 MLOpsやDataOpsなど最近の造語にもニュアンス合致 61

Slide 62

Slide 62 text

#devio2023 では、具体的にはどうすれば？

Slide 63

Slide 63 text

#devio2023 実践のためのヒント 3

Slide 64

Slide 64 text

#devio2023 まず : Measurement 可観測性(Observability)を向上させよう ● システムに対して ● SDLC全体に対して ● 継続的な計測と可視化‧記録 ● ⼈の⼿による現状把握も「可観測性の第⼀歩」どこに対して⾏うべきか / ⾏った結果どうだったかすべて分かる状態にしてから進めるのが理想ですとはいえ、そこで詰まらないように！ 64

Slide 65

Slide 65 text

#devio2023 やり⽅は：Lean ⼤きく変えず、少しずつ変える変えるべき箇所が⼤きかったら ➡ まずタスクを分解しよう変更は永続的とはなりえない。継続的な改善を 65

Slide 66

Slide 66 text

#devio2023 ⼿段：Automation Adobe Fireﬂyによる⽣成 - “Illustration of a car driven by a humanoid robot” 66 なるべく⼈の⼿を介さないような⽅向性まず⼿順を整理してから⾏おう（テスト駆動）⾃動化そのものが⽬的にならないように！問 : ⾃動運転⾞両にほんとうに必要なものはなんでしたか？

Slide 67

Slide 67 text

#devio2023 これもAutomation ⼿作業 (⾮コード化処理 / ⼿動実⾏) コード (スクリプト / IaC / ⾃動実⾏) ⼿製ツールスクリプト既製品 (OSS / SaaS / マネージドサービス ) 67

Slide 68

Slide 68 text

#devio2023 SaaS‧マネージドサービス推奨 ● OOTB (Out-of-the-box) ですぐ使える ○ ドキュメントも揃っている ● インフラも運⽤も込み ○ メンテナンスや障害対応に⼯数を割かなくて良い ● ツール側で勝⼿に進化 ○ 意図しない進化のリスクも ● 「継続的な⾒直し」がしやすい ○ 利⽤契約 (OpEx) がほとんど買い切り (CapEx) ではない 68

Slide 69

Slide 69 text

#devio2023 SaaS‧マネージドサービスの強み https://forge-vtt.com/features “SaaS を使えば数分で動く仕組みが手に入り、しかも始めたタイミングからドキュメントなども手に入ります。” —— Mike Julian 「入門　監視」 69

Slide 70

Slide 70 text

#devio2023 こんなことをやってくれるSaaSがあります ● アプリケーションのエラー発⽣ → トレースログの可視化 ● IaCコードのセキュリティスキャン、評価 ● フロントエンドテストの定期実⾏ ● システムやアプリケーションメトリックの異常なふるまいの検知 ● 様々な出⼒‧計測結果を⼀元で可視化 ● IaCステータス管理 ● Git commitから⾃動でbuild → test → deploy実⾏ ● フィーチャーフラグの管理 ● 認証認可基盤 70

Slide 71

Slide 71 text

#devio2023 誰がやる？ 4

Slide 72

Slide 72 text

#devio2023 だから「開発者は忙しい」って⾔ってるだろ！ 72 https://youtu.be/uC2jIRm0eAM

Slide 73

Slide 73 text

#devio2023 とはいえ現場の状況や問題について、⼀番詳しいのは現場の開発者 ➡ 最適解の⼀番近くに「机上の空論の押しつけ」は回避したいなんとかならないものか... 73

Slide 74

Slide 74 text

#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

Slide 75

Slide 75 text

#devio2023 というか、開発環境‧開発⼯程も「サービスの⼀部である」と位置づけるのであれば、その品質や「信頼性」を担保するための役割が既にあったりしませんか...？ https://www.oreilly.co.jp/books/9784873117911/ https://www.oreilly.co.jp/books/9784873119137/ https://www.oreilly.co.jp/books/9784873119618/ 75

Slide 76

Slide 76 text

#devio2023 案 2 : Site Reliabilit Engineering https://www.oreilly.co.jp/books/9784873117911/ https://www.oreilly.co.jp/books/9784873119137/ https://www.oreilly.co.jp/books/9784873119618/ S R E Site サイト Reliability 信頼性 Engineering 技術 (or Engineer) 76

Slide 77

Slide 77 text

#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

Slide 78

Slide 78 text

#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

Slide 79

Slide 79 text

#devio2023 というか結局のところ (残念ながら) 「現状打開しないと」という意識の元で「誰かが」やるしかないです『Lean』の考え⽅のもとちょっとずつ、無理なく、少しずつ『Automation』を導⼊していってみませんか？斧とぎ専任チームも選択肢に！ ➡ その結果が『Refactoring』に繋がっていきます！

Slide 80

Slide 80 text

#devio2023 [PR] クラスメソッドの⽀援サービス（例） https://classmethod.jp/aws/services/iac/ https://classmethod.jp/aws/services/cloud-assessment/ 80

Slide 81

Slide 81 text

#devio2023 まとめ...の前に 5

Slide 82

Slide 82 text

#devio2023 CALMSの残りのふたつ ❏ Culture （⽂化） ❏ Automation （⾃動化） ❏ Lean （リーン） ❏ Measurement （測定） ❏ Share （共有） 82

Slide 83

Slide 83 text

#devio2023 Share（共有） = サイロの撤廃 ● チーム内で情報を共有する ○ 開発〜運⽤〜ビジネス ● 共有のための時間も改善の対象 ○ 「その準備は必要ですか？」 ○ 「どんな価値を⽣みますか？」 ➡ 全員が同じツールを使い、専⽤のダッシュボードで現状把握 ➡ 忌憚のないディスカッション → ⼼理的安全性 ➡ チーム全員でDevOps⽂化を共有 https://www.pexels.com/photo/people-taking-slices-of-pizza-from-plate-5907904/ 83

Slide 84

Slide 84 text

#devio2023 ＿⼈⼈⼈⼈⼈⼈⼈⼈⼈⼈＿＞ DevOps⽂化を共有＜￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

Slide 85

Slide 85 text

#devio2023 Culture（⽂化）『DevOps』が効果を発揮するためには、組織の⽂化的⼟壌、特に『⼼理的安全性』が不可⽋です ※ 正直なところ、導⼊難易度はかなり⾼い https://www.atlassian.com/ja/devops/what-is-devops/devops-culture 85 “組織が DevOps アプローチに移行するのに役立つツールやテクノロジーは用意されています。しかし、文化を変えないままツールやテクノロジーを変えることは、基盤にある弱点に対処せずにうわべだけを変えることになります”

Slide 86

Slide 86 text

#devio2023 [PR] クラスメソッド内製化⽀援サービス ● 体制づくり ● スキル開発‧定着 ● ビジネス開発 3つの領域から内製化を実現するための⾃⾛に向けた⽀援 https://classmethod.jp/services/insource/ https://classmethod.jp/services/insource/step0/ 86

Slide 87

Slide 87 text

#devio2023 今度こそまとめ 6 Banksy, 2022

Slide 88

Slide 88 text

#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

Slide 89

Slide 89 text

Slide 90

Slide 90 text

#devio2023 TL;DR ● ⽇々の開発をRefactoringしよう ○ 進め⽅、⼿段 ○ DevOpsの原則‧CALMSフレームワーク ○ 「⽊こりのジレンマ」を回避しよう ● 特に重要 ➡ リーン(Lean)の考え⽅ ○ 技術的にも⽅法的にも ○ Automationを念頭にMeasurementしながら ○ SaaS‧マネージドサービスも積極的に検討を ● 根幹には⽂化(Culture)がある ○ ⽂化のためにはShareが必要 ○ みなが同じ画⾯を⾒て同じ⾔葉を話そう ○ そのためのツール(⼿段)選定を 90

Slide 91

Slide 91 text

#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

Slide 92

Slide 92 text

#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

Slide 93

Slide 93 text

#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

Slide 94

Slide 94 text

#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

Slide 95

Slide 95 text

#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/

Slide 96

Slide 96 text

る全て独自の考察である全る全て独自の考察である全る全て独自の考察である全る　　　　　　　　　　全る全て独自の考察である全る全て独自の考察である全全て独自の考察である Special Thanks 私のバカせまい史 - フジテレビ https://www.fujitv.co.jp/bakasemaishi/

Slide 97

Slide 97 text

#devio2023 セッションアンケート DAY2 満⾜度上位のセッションを後⽇ブログで公開予定！回答へのご協⼒をよろしくお願いします。 https://forms.gle/Upi2i5PsMTEUyJ6F8

Slide 98

Slide 98 text

#devio2023 スタンプラリーに挑戦しよう！イベント会場（11階、26階）にはQRコードが設置されており、QRコードごとにクイズのヒントがもらえます。クイズに答えて豪華景品をGETしよう！ ● AWSトレーニング1⽇コース受講チケット ● クラスメソッドオリジナルグッズ

Slide 99

Slide 99 text

No content