【新卒向け】なんとなくでも知っておいてほしいDevOps

本スライドは、2023年のサイバーエージェント新卒エンジニア研修にて、DevOpsについて講義した際の資料を一部修正したものです。

Transcript

1. 【新卒向け】 なんとなくでも知っておいてほしいDevOps CyberZ SRE 藤井 貴大
2. この資料は2023年サイバーエージェント 新卒エンジニア向け研修で使われたものです おことわり
3. 自己紹介 藤井 貴大 (Fujii Takahiro) 2019年新卒入社 株式会社CyberZ 開発本部 プロダクト開発局 SRE OPENREC.tvや新規サービスなどにSREとして従事 好きなサービスはAmazon DynamoDB
4. • 本日のゴール • はじめに: DevOpsとは • ケーススタディ • 具体的取り組み • まとめ 目次
5. 本日のゴール 1.「DevOps」とは一体何なのか、なんとなくでも理解する 2. 一般的にDevOpsと呼ばれるいくつかの取り組みについて触れる
6. はじめに: DevOpsとは 「チームのサイロ化を取り除いたりして、 素早いソフトウェア開発を行う方法論」 (今回の発表内ではそう定めることとします)
7. はじめに: DevOpsとは 「チームのサイロ化を取り除いたりして、 素早いソフトウェア開発を行う方法論」 🤔 ？

8. はじめに: DevOpsとは 「チームのサイロ化を取り除いたりして、素早いソフトウェア開発 を行う方法論」 まずここについて
9. 研修中、こんなことありませんでした？ (例として、サーバーサイドエンジニアの目線に立って)
10. ケーススタディ 事例① 修正をデプロイしたら別のところでエラー 〜数分後〜 ここエラーになってるよ〜 直したからすぐデプロイするわ！ (数行の変更だしちゃんとチェックしなくても 大丈夫でしょ) こんどはこっちが壊れてるんだけど......
11. ケーススタディ 事例② 手動でAWSリソースをいじって壊す インフラできたで〜 (ちょっとここ気になるから手動でいじっちゃお。 正確にインフラ構成把握してないけど多分大丈夫 でしょ) 誰かAWSリソース触った？ここ壊れてるんだけど......
12. 実際のプロダクト開発でできますか？ そんな雑なこと (もちろん今回の研修ではそういった経験も学びにしてください！)
13. 事例① リリース前に手動でのチェックをちゃんとするようにする 　・次第に大変になって負荷が高まる 　　・=> 可能な限り自動テストなどの導入 　・さらなる品質チェックの均一化と効率化 => QAチーム発足 事例② インフラの知識を高め、気をつけて作業するようにする 　・ヒューマンエラーはゼロにできないので仕組みで解決する 　　・=> TerraformなどのIaCを導入し、安全なCD基盤を構築 　・よりよいインフラ運用の探求 => 運用専門部隊の設立 ケーススタディ 例えばどのように品質を担保するか
14. 各チームが協調し品質が安定 開発 QA 運用 機能開発に集中 品質チェックに集中 効率的・安定的な運用に 集中
15. 一方で、チーム間連携に課題が生じることも 開発 QA 運用 リリースするとバグ出る からできるだけリリース しないでほしい (安定性に目標を置く) すぐ公開したいのにQA が通らなくて出せない (機能開発に目標を置く) QAに1週間かかるから 週に2回リリースはキツ い (品質に目標を置く) 開発速度低下
16. 一方で、チーム間連携に課題が生じることも 開発 QA 運用 リリースするとバグ出る からできるだけリリース しないでほしい (安定性に目標を置く) すぐ公開したいのにQA が通らなくて出せない (機能開発に目標を置く) QAに1週間かかるから 週に2回リリースはキツ い (品質に目標を置く) 開発速度低下 チーム間のやりとりの問題 で、適切な情報共有などがさ れないようになることを サイロ化といいます。
17. はじめに: DevOpsとは 「チームのサイロ化を取り除いたりして、素早いソフトウェア開発を行 う方法論」 品質を優先するなら サイロ化は仕方がない？
18. 品質と開発速度はトレードオフか否か 一見、いずれかを取ればもう一方が損なわれそうですが......
19. 品質と開発速度は（多くの場合）両立できる GitHubのような超巨大なコードベースですら、毎日何回もデプロイしている “200万行近い規模のコード、Railsを毎週アップデート ブログによると現在のGitHub.comは200万行近い規模のコードとなっており、1000人以上のエ ンジニアが開発に取り組んでいるとのことです。 そして1日に20回以上デプロイをし、毎週Railsをアップデートしているとも説明されています。” 引用: https://www.publickey1.jp/blog/23/github200railsrailsruby.html
20. チーム間の連携の問題を解決し、品質と 開発速度を両立するのが「DevOps」 開発 (dev) 運用 (ops) QA DevOps！ ※ QAが名前に入っていないです がDevOpsという名前の成り立ち によるものなので気にしなくて良 いです。今回は説明のためQAも 入れた図にしました。
21. 噛み砕いて言うと (組織や事業の大きさに関わらず) 今回の研修のように、必要に応じて役割をまたいで密に連携して素早く開発 しつつ、テストや運用をしっかりおこなって、安定したサービスを提供する 必要がある。
22. DevOpsとは 「チームのサイロ化を取り除いたりして、 素早いソフトウェア開発を行う方法論」 なんのために？ 素早いとはどういう意味？
23. 開発速度が遅い組織と早い組織の違い DORAの市場調査によると、開発速度の早い(※)組織は、市場競争力も高い と言われている。つまりテクノロジーを扱う企業にとって、開発速度 ≒ 市場 競争力といっても過言ではない。 開発速度を追求することが企業の利益につながるということ。 ※ 開発のリードタイムや、デプロイ頻度、障害復旧時間、変更障害率などが良い状態 のこと 例えば、一日に数回以上デプロイしているグループをハイパフォーマーとしている
24. まとめると 不具合を少なく障害の影響を小さくしたまま、 短い期間に何度もデプロイを行う（行える）ことこそが、 開発生産性が高く競争力のある組織へと繋がる。 ※ 不具合や障害はゼロにはできないので、 ある程度それを許容して開発速度を重視するような考え方
25. DevOpsとは 「チームのサイロ化を取り除いたりして、 素早いソフトウェア開発を行う方法論」 技術のことではない？
26. DevOpsの能力 (参考) プロダクト
 技術 (ツール) プロセス (進め方) 文化 (人) まず文化を醸成し、 プロセスを整備する。 そしてそれを実現する技術を以っ て開発体験の向上を図る。 結果プロダクトが良くなる。 そういう方法論がDevOps。 ※ 「モダンなツールを使おう」と いうものではない 計測 (モニタ リング)
27. DevOpsとは 「チームのサイロ化を取り除いたりして、素早い開発を行う方法論」 他には？
28. サイロの排除以外も多岐にわたる 開発をして、それをエンドユーザーに届け、フィードバックを得てさらなる サービス開発をする。その一連のサイクルをまわすために、サイロの排除以 外もさまざまな要素がDevOpsにはある。
29. では具体的に何をするのか 代表的な取り組みの一例をご紹介
30. 一日に何十回もデプロイするためには、適したブランチ運用、Git運用があ る。いわゆるGit Flowなどよりも、開発速度を重視したフローが好ましい (場合がある) ・Git Flow 　・feature -> develop -> release -> master ・トランクベース 　・feature -> main (trunk) を短いスパンで [技術] トランクベース開発 (参考)
31. [技術] トランクベース開発 (参考) ・機能ごとではなく、小さなバッチサイズにして作業(1つのPRを小さく) ・1日1回以上作業ブランチをトランクに取り込む ・フィーチャーフラグなどを活用し、いつでもデプロイできるように
32. [技術] フィーチャーフラグ コードとは別のデータソースにフラグ管理を任せ、アプリケーションをリ リースすることなく機能のON/OFFを制御する CA発のOSS「Bucketeer」などがある ・デプロイと機能公開の切り離し ・トランクベースとの相性◎ ・大きな機能も細かく分けてリリースできる
33. [技術] Continuous Integration, 自動テスト 短いスパンで開発〜リリース〜フィードバックのサイクルを回すためには、 さまざまな自動化を行うことが必須。 各種テストコード(ユニット・結合・E2E等)を整備し、変更による影響がな いことを自動で確認することが大事。
34. [技術] Continuous Delivery リリース作業が煩雑なままでは、デプロイ頻度を上げようと思っても上げら れません。 例えばKubernetes(EKS)やECSなど、コンテナ技術とそれをオーケストレー ションするシステムに乗っかることで、 よりソフトウェアデリバリを容易にできます。
35. [技術] IaC, GitOps TerraformやCDKなどでInfrastructure as Code（IaC）環境を構築するこ とで、日々のサービス開発で発生する運用業務を容易にする必要がある。 また、インフラ構成以外についても、GitOpsと呼ばれるコードによって設 定値や構成を管理することが肝要。
36. [プロセス] A/Bテスト 機能をリリースするには、まず「狙い」があり、それが実際にどうだったか の「測定」が必要になる。ユーザーに機能を出し分けてその動きを計測する A/Bテストの仕組みを用いたりして、作った機能を客観的に評価し、良い フィードバックループを回すことが、昨今の目まぐるしいサービス開発では 重要になっている。
37. QAやインフラ（SRE）など、アプリケーション開発に直接関わらないチー ムも機能開発の初期段階（例えば要件定義）から参加することで、連携コス トが減ったりして素早い開発サイクルが回せるようになる。 [プロセス] QAやインフラチームも機能開発に 開発 (dev) インフラ (ops) QA
38. [文化] DevOpsの啓蒙・文化醸成 DevOpsはあくまで方法論のため、その実現には組織全体の協力・協調が必 須になる（場合によってはエンジニア以外も含めて） DevOpsとは何なのか、なぜ推進する必要があるのか、どのように進めるの か、という啓蒙を行ったり、勉強会やLT、分科会などを通してDevOps的取 り組みが進めやすい文化を醸成する必要がある 今日の講義もその取り組みの内の一つ
39. [計測] FourKeys 「開発生産性」を評価する下記の四指標。これらを計測することで自組織の 開発の生産性を可視化し改善に活かす。GitHubのイベントを収集するOSS やSaaSなどがある 　　　　　　　　　　　　・変更のリードタイム 　　　　　　　　　　　　・デプロイ頻度 　　　　　　　　　　　　・障害復旧時間 (MTTR) 　　　　　　　　　　　　・変更障害率 計測
40. Q. では全ての組織で同じDevOpsソリュー ションを採るべきか？
41. A. もちろんそんなことはない 何もない状態から集まって開発を始めた研修とは違い、みなさんが配属される先 には既に人がいて、組織があり、文化が醸成され、そこに根付いた開発プロセス がある。 どのように開発速度を向上させエンジニアとして貢献できるようになるかは、 事業のフェーズなどさまざまな要因を考慮して行う必要がある。 Q. 全ての組織で同じDevOps ソリューションを採るべきか？
42. 再掲: 本日のゴール 1.「DevOps」とは一体何なのか、なんとなくでも理解する 2. 一般的にDevOpsと呼ばれるいくつかの取り組みについて触れる
43. まとめ 1. DevOpsとは a. チームのサイロ化を取り除いたりして、素早いソフトウェア開 発を行う方法論 b. 一に文化、二にプロセス。三に技術。計測も忘れずに。 2. DevOpsのさまざまな取り組み a. 啓蒙・文化醸成 b. A/Bテスト、バリューストリームマッピング c. トランクベース、フィーチャーフラグ、CI/CD、IaC/GitOps d. FourKeys計測 e. 他にもたくさん...... (道のりは長く険しい)
44. 参考 • DevOpsの能力 - Google Cloud • Effective DevOps • アジャイル、CI/CD、DevOpsの違いとは