Tweet
Tweet

Slide 1

Slide 1 text

LM - SRE はこうやって 開発生産性と戦います 株式会社 Link & Motivation SRE - 川津 雄介

Slide 2

Slide 2 text

● 前職は某複写機メーカーでエンジニアして ました ● 現職では SRE ● FE→BE→OS→インフラ 全部やりたい派 ● 採用活動もしてます 自己紹介 https://github.com/megmogmog1965 https://qiita.com/megmogmog1965

Slide 3

Slide 3 text

今日のテーマ SRE の言う「開発生産性」って何？ 03 01 02 どうやって改善項目を決めるの？ LM流・改善を成果に繋げるには (布教活動) しくみ

Slide 4

Slide 4 text

01 SRE の言う「開発生産性」って何？

Slide 5

Slide 5 text

そもそも LM の開発体制は？ 開発チームはミッシ ョンで分けます。 SRE は開発室を 横断する！ 新規顧客獲得の為の 機能開発チームとか

Slide 6

Slide 6 text

開発あるある...

Slide 7

Slide 7 text

最近リリース 速くなったね！ 開発者

Slide 8

Slide 8 text

(特に何も変わって ないけど..？) 開発者

Slide 9

Slide 9 text

開発者 最近開発 遅くない？

Slide 10

Slide 10 text

(頑張って前より沢 山開発してるんだけ どなぁ...) 開発者

Slide 11

Slide 11 text

感覚じゃなくて... ものさし (指標) が必要

Slide 12

Slide 12 text

生産性指標 = 4 Key Metrics デプロイ頻度 本番環境へのリリースの頻度 (回) ※「20 回/週」とか！ リードタイム 初回の git commit から、そのコ ードが本番デプロイされるまでの 時間 ※「５日」とか！ 本番環境で発生した障害から 復旧するまでの時間 ※「平均 120 分」とか！ MTTR 本番へのリリース回数に対して、 障害が発生した割合 (%) ※「15%」とか！ 変更障害率

Slide 13

Slide 13 text

開発のスピードを表す Metrics デプロイ頻度 本番環境へのリリースの頻度 (回) ※「20 回/週」とか！ リードタイム 初回の git commit から、そのコ ードが本番デプロイされるまでの 時間 ※「５日」とか！ 本番環境で発生した障害から 復旧するまでの時間 ※「平均 120 分」とか！ デプロイ頻度 本番へのリリース回数に対して、 障害が発生した割合 (%) ※「15%」とか！ 変更障害率

Slide 14

Slide 14 text

品質が損なわれていないか Metrics デプロイ頻度 本番環境へのリリースの頻度 (回) ※「20 回/週」とか！ リードタイム 初回の git commit から、そのコ ードが本番デプロイされるまでの 時間 ※「５日」とか！ 本番環境で発生した障害から 復旧するまでの時間 ※「平均 120 分」とか！ MTTR 本番へのリリース回数に対して、 障害が発生した割合 (%) ※「15%」とか！ 変更障害率

Slide 15

Slide 15 text

バランスが重要 品質を犠牲にすれば スピードは簡単に上げられる

Slide 16

Slide 16 text

02 どうやって改善項目を決めるの？

Slide 17

Slide 17 text

State of DevOps Report - 2021 High/Mid/Low Performaer の分類 一般的な目標値のランク

Slide 18

Slide 18 text

私達は今どのレベルにいるのかな？ LM での High/Mid-*/Low の独自解釈版

Slide 19

Slide 19 text

例えば昔...

Slide 20

Slide 20 text

デプロイ頻度を上げたい

Slide 21

Slide 21 text

BEFORE…

Slide 22

Slide 22 text

元々 EB を手でデプロイしてた EB 沢山あるよ〜 ３時間かかる... リリース担当者 が決まってて 誰でもできない EB EB EB EB EB EB EB EB EB EB ミスったら...

Slide 23

Slide 23 text

AFTER !!

Slide 24

Slide 24 text

コンテナ化 (ECS) しました EB ECS

Slide 25

Slide 25 text

All Terraform 化もしました ※ 実はその前は AWS CDK (TypeScript) を使ってた

Slide 26

Slide 26 text

堅牢性・透明性の担保 静的なコード ● HCL はほぼ「設定ファイル」 ● プログラムコードの様な難しさが 無い 変更箇所が明確 ● `terraform plan` で、変更箇所が明確に分かる ● 「やってみないと分からなくて怖い...」が無い

Slide 27

Slide 27 text

Github / CodeBuild CI でデプロイ自動化 Master マージ で自動デプロイ Blue / Green にした Blue / Green にした

Slide 28

Slide 28 text

そして次は...

Slide 29

Slide 29 text

リードタイムを上げたい

Slide 30

Slide 30 text

BEFORE…

Slide 31

Slide 31 text

この木、なんの木？ 「マージ待ち、お見合い行列の木」

Slide 32

Slide 32 text

開発組織が拡大する → 複雑化 ● Master マージすると自動デプロイされるから、気軽にマージできない ● 「明日だれがリリースする？」「もうリリースブランチ(PR)作った？」

Slide 33

Slide 33 text

AFTER !!

Slide 34

Slide 34 text

(作業を〜ではなく) プロセスを自動化します

Slide 35

Slide 35 text

Git-flow にしたよ！

Slide 36

Slide 36 text

自動でリリース担当に通知 (依頼) 朝 7:00 に Slack に自動で来る ※ Feature Flags も導入してます

Slide 37

Slide 37 text

リリース用の Github PR も自動で 朝 7:00 に PR 自動で作られる

Slide 38

Slide 38 text

ステージングデプロイ → 自動テスト ステージング環境 自動デプロイ 自動テスト

Slide 39

Slide 39 text

Release ver の git tag も自動で Feature リリースなら Minor ver が上がる Hotfix リリースなら Patch ver が上がる

Slide 40

Slide 40 text

Github Actions で実現 Git 周りの自動化は Github Actions でほぼ完結します

Slide 41

Slide 41 text

03 改善を成果に繋げるには

Slide 42

Slide 42 text

仕組みは、作った後の 布教活動が重要！

Slide 43

Slide 43 text

どうやって布教するか？ 1. 全体の場で「意義・メリット」を布教！ 2. 各チームに「伝道者」 (※相談人) を作る！

Slide 44

Slide 44 text

最後に... 計測 → 改善 のサイクル 計測 今現在の最大の ボトルネックは どこか？ 改善 特定した課題をどう 「仕組み」で解決 するか？

Slide 45

Slide 45 text

THANKS 私達、株式会社 Link & Motivation は 一緒に働く新しい仲間を募集しています！ 応募ページはこちら！