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

https://dev.classmethod.jp/news/devio-2023/

Transcript

1. DevOpsとSREのために知るべき 3つの原則 〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜 08 July 2023 渡辺聖剛＠クラスメソッド株式会社
2. #devio2023 Q : みなさんの職種(ロール)について 1. エンジニア・プログラマー 2. 技術責任者 3. 情報システム部門 2
3. #devio2023 早速ですが、 ⽇々の開発業務、 忙しくないですか？
4. #devio2023 開発環境 = Software Development Life Cycle 機能実装 コード記述 （IaC含む） コミット ・PR コードのレ ビュー テストビル ド デプロイ用 ブランチへ のマージ 本番ビルド 本番ビルド （アプリケー ション）に対 するテスト 本番環境へ のデプロイ 本番環境に てアプリ ケーション が動作して いる状態 実行状態の 観測・計測 本番環境へ の操作・運 用 インシデン ト対応 ポストモー テム 計測結果や フィード バックを受 けての次の 開発計画 Code Review Build Test Deploy Run Measure Improve Plan Repeat Operate 4
5. #devio2023 開発者は忙しい • 開発のCI/CDループ。 毎⽇コードは書かれている • 問題があるコードは、即座に 顧客体験の悪化を引き起こす • だから、⽇々のコードレビューは 本当に重要 • しかし、組織の事情によっては そこを⼗分に⼿厚くできない • 規模に依らずそんな組織が多い • なぜなら、開発者たちは やることが多く忙しいからだ 5 https://youtu.be/uC2jIRm0eAM（意訳）
6. #devio2023 でも要求はどんどん増える : 2013 → 2023 https://httparchive.org/reports/state-of-the-web#bytesTotal デスクトップ ➡ 2.7倍 モバイル ➡ 4.9倍 サーバー側の 処理内容 ➡ ????倍 6
7. #devio2023 「速いは正義」という時代 | ⾚の⼥王仮説 • 開発速度 ≒ 変化する / 変化に対応する速度 • 処理性能(レスポンスタイム)の速さ ⽇々⾛り続けないと ついていけない！ 7 https://agora-web.jp/archives/516141.html https://www.genpaku.org/alice02/alice02j.html “ここではだね、 同じ場所にとどまるだけで、 もう必死で走らなきゃいけないんだよ” ———— ルイス・キャロル 「鏡の国のアリス」
8. #devio2023 ここで聞こえてくる 「忙しすぎて、  環境のメンテとかできないよ」 との声
9. #devio2023 RPGにおける武器と狩り場のジレンマ • はやく経験値や素材を稼ぎたい • レベルアップなどの理由で、 装備や狩り場が適正では なくなった そのまま狩り続けるのか？ それとも、 拠点に戻って装備を整え 適切な狩り場に移動する？ https://commons.wikimedia.org/wiki/File:LARP.jpg 9 ※画像はイメージです
10. #devio2023 わかりにくいと⾔われたので で例えてもらった 4⼈1チーム同⼠での対戦 • 敵を2体倒し、 ⾃分ひとりで最前線をキープ • 敵も同様に⾃拠点に攻め込んでいて、 味⽅ 3 vs 敵 2 で状況が膠着 （通常はこのままでも勝てる） • ⾃分が戻ることで 4 vs 2、 早期解決を⽬指せるが、 せっかく上げた戦線を下げることになる ⾃分ひとりで前線を維持し続けるか？ 拠点に戻り、戦況とチーム体制を整えてから 再び前線を上げるか？ https://commons.wikimedia.org/wiki/Main_Page 10 ※画像はイメージです
11. #devio2023 そんな装備で大丈夫か？ 短期的には良い判断だが、 その後⽣産性はじわじわ低下 短期的には⽣産性が落ちるが、 中⻑期的には こちらが上に いわゆる「⽊こりのジレンマ」 ぼろぼろの斧で ⽊を切り続けるのか？ それとも まず斧を研いで、 その後の⽊を切るペースを あげるか？ https://webtan.impress.co.jp/e/2017/06/27/26149 http://elshaddai.jp/elshaddai_crim/freedeta.html 11 ➡ 課題を感じているなら 「斧を研ぐ」時間をとる検討を
12. #devio2023 忙しいなかですが なんとかアップデートしてほしい... というわけで、 開発環境を 「リファクタリング」しませんか？
13. #devio2023 本⽇お話しすること https://dev.classmethod.jp/news/devops-webinar/ 13
14. #devio2023 今年の 2 ⽉から毎⽉開催 • 2023/02/03 • 2023/03/03 • 2023/04/07 • 2023/05/10 • 2023/06/07 • 2023/07/06 ご参加‧ご協⼒いただいた皆様⽅、 本当にありがとうございました！ 14
15. #devio2023 ウェビナーアンケートより 15
16. #devio2023 ウェビナーアンケートより 16
17. #devio2023 今⽇お話しすること 開発環境の「リファクタリング」 どうやって進めましょう？ • どこを • どのように • どうやって‧何を使って 17
18. #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
19. #devio2023 本⽇のゴール ⽇々の開発の状況を思い返して 「オレたちみんな、毎⽇たいへんなことやってんな...」 「実はもっと 楽に 効率あげられるんじゃないかな？」 と、思えるようになること 19
20. #devio2023 今⽇お話ししないこと • SDLCステップごとの具体的な解決策の提⽰ （語り尽くせません！） • 具体的なツールの紹介 （銀の弾丸はありません！！） • 開発環境 ≠ コーディング環境 （好きなIDEを使ってください！） （でもコーディングを助ける話はします） 20
21. #devio2023 こちらも是⾮視聴を！ AWS事業本部コンサルティング部 mokoさんのセッション 勝⼿に姉妹編的なセッションだと思いました （ついさっきそう思いました
22. #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
23. #devio2023 [PR]【7/24（⽉）福岡】DevelopersIO 2023 福岡 https://dev.classmethod.jp/news/devio-2023-fukuoka/ 23
24. #devio2023 開発環境の Refactoring（リファクタリング） 1 1
25. #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 この考え方を 開発環境そのものにも適応する
26. #devio2023 「開発環境」を「リファクタリング」する SDLCの全体の流れを変えずに パーツ単位で改善していく • ⼿段を変える ◦ ⼿作業 ➡ ⾃動化 • 道具(ツール)を変える ◦ 使いにくい道具 ➡ 使いやすい道具 基本原則：影響範囲を「最⼩に」抑える （ゼロにする、ではない！） 26
27. #devio2023 最⼩単位で⼩さく始める：リーン Lean “Think big, act small, fail fast; learn rapidly” ———— Lean Software Development: An Agile Toolkit 27
28. #devio2023 さらに Automation ⾃動化 Measurement 計測‧測定 • 「機械的に実⾏される所」を 増やす • 現状把握と効果測定 28
29. #devio2023 ちょっと並べ替えて ❏ Culture （⽂化） ❏ Automation （⾃動化） ❏ Lean （リーン） ❏ Measurement （測定） ❏ Share （共有） 29
30. #devio2023 実は ❏ Culture （⽂化） ❏ Automation （⾃動化） ❏ Lean （リーン） ❏ Measurement （測定） ❏ Share （共有） 30
31. #devio2023 実は : CALMSフレームワーク ❏ Culture （⽂化） ❏ Automation （⾃動化） ❏ Lean （リーン） ❏ Measurement （測定） ❏ Share （共有） https://www.atlassian.com/ja/devops/frameworks/calms-framework DevOpsフレームワークのひとつ 31
32. #devio2023 つまり DevOpsの原則‧フレームワークにそって 開発環境をリファクタリングしましょう ...という提案です 32
33. #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)”
34. #devio2023 Q : DevOpsとは... 1. Dev と Ops 2. Dev も Ops も 3. Dev の Ops 4. Dev が Ops ある意味 全部 正解 34
35. #devio2023 Automation/Lean/Measurement 2
36. #devio2023 Automation/Lean/Measurement 2
37. #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
38. #devio2023 端的に⾔えば Automation ≠ オートメーション
 とかく「如何にコードで置き換えるか」のような議論になりがちですが... 「その⼿続きは本当に必要なのか？」 「もっと簡素化‧簡略化できるのでは？」 「コードを書かなくても⽅法はあるのでは？」 もっとも効果的な⽅法で「⼿作業を回避」することが重要です 38
39. #devio2023 「⼿動で⾏う作業を最⼩化すること」によって... • ⼈的要因による事故やミスを抑制 ➡ 正確性‧再現性が向上 • 作業時間‧実⾏時間の短縮 • 作業の持続可能性が向上 （属⼈スキルからの脱却） https://www.atlassian.com/ja/devops/what-is-devops 39 “DevOpsの基本的なプラクティスは、ソフトウェア開発ライフサイクルを 可能な限り自動化することです。これにより、開発者がコードを書いたり、 新しい機能を開発したりする時間が増えます。 自動化は CI/CD パイプラインの重要な要素であり、人的ミスの削減と チームの生産性向上に役立ちます。” ———— 自動化 - 5 つの重要な DevOps の原則 | Atlassian
40. #devio2023 端的に⾔えば Automation ≠ 機能実装
 サービスとして提供するためではなく、 そのための⼿段を改善するのが⽬的 ➡「⼤きく完全なもの」は ⽬指さない https://commons.wikimedia.org/wiki/File:160216-N-XT273-025_(25055215346).jpg 40
41. #devio2023 Automation/Lean/Measurement 2
42. #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
43. #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
44. #devio2023 Lean ➡ 「継続的な改善に努める」 「⾃動化して終わり」ではない (ここも錯覚しやすいポイント) 「やっている時間が無い」 からこそ 持続可能な範囲で 試⾏‧遂⾏することが重要 https://pxhere.com/en/photo/930678 44
45. #devio2023 「作ったものは壊したくない」➡ わかります！ もちろん「全てを作り直せ」と ⾔っているわけではないです 残すべきものは残しましょう （その判断をしましょう） 最初からライフサイクルを 意識しておくといいですね！ 45
46. #devio2023 Think big, act small • いま⾏っている「マニュアル作業」をそのまま⾃動化すると、 その作業の本質が覆い隠される危険性がある ◦ ⾃動化しようとしているその作業、 最初は（本来は）ワークアラウンドのはずではなかったですか？ • 全体(big)をみた上で、 なるべく局所(small)的な変更‧導⼊を⼼がけましょう https://www.oreilly.co.jp/books/9784873119137/ “問題の重大性を覆い隠すようなスクリプトを書くことは、 本当の問題を修正しないため中長期的には無駄であり、さらに 潜在的には後にもっと問題を引き起こす要因となりえます。” ————John Looney, 「サイトリライアビリティワークブック」（一部要約） 46
47. #devio2023 Automation/Lean/Measurement 2
48. #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
49. #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
50. #devio2023 Measurement (計測) 50 アプリケーションの挙動 ➡ APM (Application Performance Management) インフラ/システムの挙動 ➡ システム監視 (CPU/メモリ/システムログ etc...) 実⾏環境の挙動の監視 (異常の発⽣➡即時アラート) Infrastructure Application APM System Monitoring Dashboard
51. #devio2023 Measurement (計測) 51 Code Review Build Test Deploy Run Measure Improve Plan Operate こちらは 誰が⾒ていますか？ Infrastructure Application APM System Monitoring Dashboard SDLC
52. #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
53. #devio2023 計測(Measure) ≠ 監視(Monitor) 監視 (Monitor) : ⽬的をもって閾値を設定、超過/下回ったら警報 計測 (Measure) : 「いまがどうであるか」の測定 • 現状把握のための計測(Measure)を！ ◦ 警報ありきの監視(Monitor)ではありません • 持続性のある計測⽅法の採⽤を！ ◦ Excelに⼿⼊⼒強制： 労⼒と⽐較して、正確な情報が採れる保証がありません 53
54. #devio2023 可観測性(Observability) 異常検知‧警報のためでなく、 「いまシステムがどうであるか」を把握するための 計測 (Measurement) Metric / (Event)Log / Trace etc... ➡ そのためのもの！ https://www.oreilly.co.jp/books/9784814400126/ 54 “システムがどのような状態になったとしても、それがどんなに 斬新で奇妙なものであっても、どれだけ理解し説明できるかを 示す尺度です” ————Charity Majors、Liz Fong-Jones、George Miranda「オブザーバビリティ・エンジニアリング」
55. #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
56. #devio2023 ここまでのまとめ Automation‧Lean‧Measurement
57. #devio2023 ここまでのまとめ ❏ Culture （⽂化） ❏ Automation （⾃動化） ❏ Lean （リーン） ❏ Measurement （測定） ❏ Share （共有） https://www.atlassian.com/ja/devops/frameworks/calms-framework 反復的な手作業の排除 再現性・正確性の向上 継続的な改善を前提 最小限の範囲から段階的に 現状の状況把握・可視化 (詳細よりも大局を意識) どのように始めるか・進めるか 何から始めると効果的か・行った効果は 57
58. #devio2023 ちょっと休憩：こちらの解答 1. Dev と Ops 2. Dev も Ops も 3. Dev の Ops 4. Dev が Ops 58
59. #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
60. #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
61. #devio2023 3. Dev の Ops ➡ 現在の理想像 Operations for Development Lifecycle 「開発サイクルを  うまく回す(運⽤する)」 MLOpsやDataOpsなど 最近の造語にもニュアンス合致 61
62. #devio2023 では、具体的にはどうすれば？
63. #devio2023 実践のためのヒント 3
64. #devio2023 まず : Measurement 可観測性(Observability)を向上させよう • システムに対して • SDLC全体に対して • 継続的な計測と可視化‧記録 • ⼈の⼿による現状把握も「可観測性の第⼀歩」 どこに対して⾏うべきか / ⾏った結果どうだったか すべて分かる状態にしてから進めるのが理想です とはいえ、そこで詰まらないように！ 64
65. #devio2023 やり⽅は：Lean ⼤きく変えず、少しずつ変える 変えるべき箇所が⼤きかったら ➡ まずタスクを分解しよう 変更は永続的とはなりえない。 継続的な改善を 65
66. #devio2023 ⼿段：Automation Adobe Fireflyによる⽣成 - “Illustration of a car driven by a humanoid robot” 66 なるべく⼈の⼿を介さないような⽅向性 まず⼿順を整理してから⾏おう（テスト駆動） ⾃動化そのものが⽬的にならないように！ 問 : ⾃動運転⾞両にほんとうに必要なものはなんでしたか？
67. #devio2023 これもAutomation ⼿作業 (⾮コード化処理 / ⼿動実⾏) コード (スクリプト / IaC / ⾃動実⾏) ⼿製ツール スクリプト 既製品 (OSS / SaaS / マネージドサービス ) 67
68. #devio2023 SaaS‧マネージドサービス推奨 • OOTB (Out-of-the-box) で すぐ使える ◦ ドキュメントも揃っている • インフラも運⽤も込み ◦ メンテナンスや障害対応に ⼯数を割かなくて良い • ツール側で勝⼿に進化 ◦ 意図しない進化のリスクも • 「継続的な⾒直し」がしやすい ◦ 利⽤契約 (OpEx) がほとんど 買い切り (CapEx) ではない 68
69. #devio2023 SaaS‧マネージドサービスの強み https://forge-vtt.com/features “SaaS を使えば数分で動く仕組みが 手に入り、しかも始めたタイミングから ドキュメントなども手に入ります。” —— Mike Julian 「入門　監視」 69
70. #devio2023 こんなことをやってくれるSaaSがあります • アプリケーションのエラー発⽣ → トレースログの可視化 • IaCコードのセキュリティスキャン、評価 • フロントエンドテストの定期実⾏ • システムやアプリケーションメトリックの異常なふるまいの検知 • 様々な出⼒‧計測結果を⼀元で可視化 • IaCステータス管理 • Git commitから⾃動でbuild → test → deploy実⾏ • フィーチャーフラグの管理 • 認証認可基盤 70
71. #devio2023 誰がやる？ 4
72. #devio2023 だから「開発者は忙しい」って⾔ってるだろ！ 72 https://youtu.be/uC2jIRm0eAM
73. #devio2023 とはいえ 現場の状況や問題について、 ⼀番詳しいのは現場の開発者 ➡ 最適解の⼀番近くに 「机上の空論の押しつけ」は 回避したい なんとかならないものか... 73
74. #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
75. #devio2023 というか、 開発環境‧開発⼯程も 「サービスの⼀部である」 と位置づけるのであれば、 その品質や「信頼性」を 担保するための役割が 既にあったりしませんか...？ https://www.oreilly.co.jp/books/9784873117911/ https://www.oreilly.co.jp/books/9784873119137/ https://www.oreilly.co.jp/books/9784873119618/ 75
76. #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
77. #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
78. #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
79. #devio2023 というか 結局のところ (残念ながら) 「現状打開しないと」 という意識の元で 「誰かが」やるしかないです 『Lean』の考え⽅のもと ちょっとずつ、無理なく、 少しずつ『Automation』を 導⼊していってみませんか？ 斧とぎ専任チームも選択肢に！ ➡ その結果が『Refactoring』に繋がっていきます！
80. #devio2023 [PR] クラスメソッドの⽀援サービス（例） https://classmethod.jp/aws/services/iac/ https://classmethod.jp/aws/services/cloud-assessment/ 80
81. #devio2023 まとめ...の前に 5
82. #devio2023 CALMSの残りのふたつ ❏ Culture （⽂化） ❏ Automation （⾃動化） ❏ Lean （リーン） ❏ Measurement （測定） ❏ Share （共有） 82
83. #devio2023 Share（共有） = サイロの撤廃 • チーム内で情報を共有する ◦ 開発〜運⽤〜ビジネス • 共有のための時間も改善の対象 ◦ 「その準備は必要ですか？」 ◦ 「どんな価値を⽣みますか？」 ➡ 全員が同じツールを使い、 専⽤のダッシュボードで現状把握 ➡ 忌憚のないディスカッション → ⼼理的安全性 ➡ チーム全員でDevOps⽂化を共有 https://www.pexels.com/photo/people-taking-slices-of-pizza-from-plate-5907904/ 83
84. #devio2023 ＿⼈⼈⼈⼈⼈⼈⼈⼈⼈⼈＿ ＞ DevOps⽂化を共有 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣
85. #devio2023 Culture（⽂化） 『DevOps』が効果を発揮するためには、 組織の⽂化的⼟壌、 特に『⼼理的安全性』が不可⽋です ※ 正直なところ、導⼊難易度はかなり⾼い https://www.atlassian.com/ja/devops/what-is-devops/devops-culture 85 “組織が DevOps アプローチに移行するのに役立つ ツールやテクノロジーは用意されています。 しかし、文化を変えないままツールやテクノロジーを 変えることは、基盤にある弱点に対処せずにうわべだ けを変えることになります”
86. #devio2023 [PR] クラスメソッド 内製化⽀援サービス • 体制づくり • スキル開発‧定着 • ビジネス開発 3つの領域から 内製化を実現するための ⾃⾛に向けた⽀援 https://classmethod.jp/services/insource/ https://classmethod.jp/services/insource/step0/ 86
87. #devio2023 今度こそ まとめ 6 Banksy, 2022
88. #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
89. #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
90. #devio2023 TL;DR • ⽇々の開発をRefactoringしよう ◦ 進め⽅、⼿段 ◦ DevOpsの原則‧CALMSフレームワーク ◦ 「⽊こりのジレンマ」を回避しよう • 特に重要 ➡ リーン(Lean)の考え⽅ ◦ 技術的にも⽅法的にも ◦ Automationを念頭にMeasurementしながら ◦ SaaS‧マネージドサービスも積極的に検討を • 根幹には⽂化(Culture)がある ◦ ⽂化のためにはShareが必要 ◦ みなが同じ画⾯を⾒て同じ⾔葉を話そう ◦ そのためのツール(⼿段)選定を 90
91. #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
92. #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
93. #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
94. #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
95. #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/
96. る全て独自の考察である全 る全て独自の考察である全 る全て独自の考察である全 る　　　　　　　　　　全 る全て独自の考察である全 る全て独自の考察である全 全て独自の考察である Special Thanks 私のバカせまい史 - フジテレビ https://www.fujitv.co.jp/bakasemaishi/
97. #devio2023 セッションアンケート DAY2 満⾜度上位のセッションを後⽇ブログで公開予定！ 回答へのご協⼒をよろしくお願いします。 https://forms.gle/Upi2i5PsMTEUyJ6F8
98. #devio2023 スタンプラリーに挑戦しよう！ イベント会場（11階、26階）にはQRコー ドが設置されており、QRコードごとにクイ ズのヒントがもらえます。 クイズに答えて豪華景品をGETしよう！ • AWSトレーニング1⽇コース受講チケット • クラスメソッドオリジナルグッズ