小さなサービスでの SREとの付き合い方【MIXI TECH CONFERENCE 2023】

by MIXI ENGINEERS

Slide 1

Slide 1 text

©MIXI 小さなサービスでの SREとの付き合い方井上翔太 1

Slide 2

Slide 2 text

©MIXI 自己紹介名前：井上翔太 twitter：@syossan27 2019年にミクシィ（現MIXI）入社サーバーサイドを中心に開発していたが、最近はSRE チックなことをやっています 2

Slide 3

Slide 3 text

©MIXI 皆さん、SREやってますか？ 3

Slide 4

Slide 4 text

©MIXI 気にはなるけどまだ手が出せてない方所属会社の規模だとSREはまだ早いと思っている方 ↓ もしそんな方がいましたら、当セッションで何か得るものがあれば幸いです　 4

Slide 5

Slide 5 text

©MIXI 今日お話すること 5

Slide 6

Slide 6 text

©MIXI 1. 小さなサービスでSREって必要？ 2. やってきたこと 3. 失敗した施策の紹介 4. Next Action ! 5. まとめ 6

Slide 7

Slide 7 text

©MIXI 1. 小さなサービスでSREって必要？ 7

Slide 8

Slide 8 text

©MIXI 開発チーム人数：3人 ⇒ 8人どのくらいの規模のサービス？リリースされてから： 1年11ヶ月 MAU/WAU/DAU：ユーザー登録数：徐々に大きくはなってきてる 8

Slide 9

Slide 9 text

©MIXI で、SREは何故必要だったの？　 9

Slide 10

Slide 10 text

©MIXI 何故SREは必要となったか？〜2021の私〜 ■ 2021/03〜とある機能の実装の流れからインフラをちょこちょこと触るようになる ■ 2021/04〜負荷計測・パフォーマンスチューニング、インフラ・デプロイフローの障害時調査などのタスクに積極的に関わる ■ 〜2021/10 上記を続けながらアラートを追加したり整理したり、トイルを無くすように仕組み作りをしたり、インシデント管理をしたり・・・ 10

Slide 11

Slide 11 text

©MIXI あれ？これってSREってやつなんじゃない？　　 11

Slide 12

Slide 12 text

©MIXI 何故SREは必要となったか？気付いたら"SRE"と呼ばれることをやっていた ⇒ サービス規模に関わらず、 SREは誰かが必ずやっている SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。※ 小さなチームでは運用チームを持たないことが多いので（雰囲気兼任が多い）自然発生的に“明確な”運用チームの動きが生まれたらそれが SREとも言える ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチームオライリージャパンより引用 12

Slide 13

Slide 13 text

©MIXI よっしゃ！全力でSREや！　 13

Slide 14

Slide 14 text

©MIXI よっしゃ！全力でSREや！　 ↓ とはいかない 14

Slide 15

Slide 15 text

©MIXI 何故全力でSREやっちゃダメなのか？十二分に人的リソースがあるチームならやっても良い ⇒ しかし、スモールチームの場合には新規機能開発への致命な人的リソース不足になる可能性が ⇒ マネージメント層にもやっちゃダメと NGを喰らうことも 15

Slide 16

Slide 16 text

©MIXI 何故全力でSREやっちゃダメなのか？十二分に人的リソースがあるチームならやっても良い ⇒ しかし、スモールチームの場合には新規機能開発への致命な人的リソース不足になる可能性が ⇒ マネージメント層にもやっちゃダメと NGを喰らうことも ⇓ [対策を考えよう] ・今のチームに合わせてやること・やらないことを切り分けていけば　SREと開発を併行出来るのでは？・チームが潜在的に抱えている SREに纏わる問題点を説明し、この解消に　動くというメリットを説明すれば OKが貰えるのでは？ 16

Slide 17

Slide 17 text

©MIXI SREと開発を併行させるそもそもそれってアリなの？というところから調べる ⇒ SRE発祥、Google社ブログにてこんな記事が How SRE teams are organized, and how to get started （SREチームの編成方法とその始め方） ※ この中で６つのSREの導入が紹介されていました 17 ※ Goolge Cloud Blog 「How SRE teams are organized, and how to get started」 https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started (参照 2023/02/21) より引用

Slide 18

Slide 18 text

©MIXI SREと開発を併行させるそもそもそれってアリなの？というところから調べる ⇒ SRE発祥、Google社ブログにてこんな記事が How SRE teams are organized, and how to get started （SREチームの編成方法とその始め方） ※ この中で６つのSREの導入が紹介されていました 1. Kitchen Sink, a.k.a. “Everything SRE” （SREも開発もやるなんでも屋さん） 2. Infrastructure （K8s周りの保守や, Google CloudなどにデプロイされたCI/CDなどの保守） 3. Tools （SREに関するツールを開発・導入・運用） 4. Product/application （主要なアプリケーションのみの信頼性向上を担う） 5. Embedded （特定の開発チームに組み込まれた SRE） 6. Consulting （開発チームに組み込まれない SRE） 18 ※ Goolge Cloud Blog 「How SRE teams are organized, and how to get started」 https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started (参照 2023/02/21) より引用

Slide 19

Slide 19 text

©MIXI SREと開発を併行させるそもそもそれってアリなの？というところから調べる ⇒ SRE発祥、Google社ブログにてこんな記事が How SRE teams are organized, and how to get started （SREチームの編成方法とその始め方） ※ この中で６つのSREの導入が紹介されていました 1. Kitchen Sink, a.k.a. “Everything SRE” （SREも開発もやるなんでも屋さん） 2. Infrastructure （K8s周りの保守や, Google CloudなどにデプロイされたCI/CDなどの保守） 3. Tools （SREに関するツールを開発・導入・運用） 4. Product/application （主要なアプリケーションのみの信頼性向上を担う） 5. Embedded （特定の開発チームに組み込まれた SRE） 6. Consulting （開発チームに組み込まれない SRE）これだ！ 19 ※ Goolge Cloud Blog 「How SRE teams are organized, and how to get started」 https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started (参照 2023/02/21) より引用

Slide 20

Slide 20 text

©MIXI SREと開発を併行させるなんでも屋さん × 組み込み型SREという関わり方はおかしいことではないことがわかった ⇒ 次に“SRE”と“開発”でやること・やらないことを切り分ける開発：・新規機能開発・リファクタリング・負荷テスト/パフォーマンス改善・放置タスクの対応・不具合修正・スクラム SRE：・SLI/SLO, エラーバジェットの策定・トイルの撲滅・オブザーバビリティの向上・リリースエンジニアリング・オンコール対応・インフラの改善/運用/保守・セキュリティ対応・DX改善 20

Slide 21

Slide 21 text

©MIXI SREと開発を併行させるなんでも屋さん × 組み込み型SREという関わり方はおかしいことではないことがわかった ⇒ 次に“SRE”と“開発”でやること・やらないことを切り分ける SRE：・SLI/SLO, エラーバジェットの策定・トイルの撲滅・オブザーバビリティの向上・リリースエンジニアリング・オンコール対応・インフラの改善/運用/保守・セキュリティ対応・DX改善開発：・新規機能開発・リファクタリング・負荷テスト/パフォーマンス改善・放置タスクの対応・不具合修正・スクラム 21

Slide 22

Slide 22 text

©MIXI やることは多いが何とかなりそう　 22

Slide 23

Slide 23 text

©MIXI SREと開発を併行させるただ、このまま“SRE”というポジションで開始すると SREはプロダクトの機能開発も兼ねる人と勘違いされないか？ ⇒ 何か別の言い方が出来るポジションで始めたい！ Misoca社様がやってらっしゃる「遊軍チーム」の取り組みがこれからやろうとしていることとしっくり来たのでお名前を拝借した ⇒ 「遊撃部隊」という名前で始めよう！ 23

Slide 24

Slide 24 text

©MIXI マネージメント層への説得ここまででやろうとしていることの整理はついた ⇒ ここからはマネージメント層への説得のための材料集め想定される質疑に対する応答・リソースが足りなくなるのが心配 ⇒ 完全に一人分のリソースが無くなるわけじゃないので大丈夫！ ⇒ 半年前に入社された３人の開発スピードも上がってきたので、減った分を賄ってくれるはず！・必要性がイマイチ分からない ⇒ 現状をありのままに伝える ⇒ インフラを専門的に見れる人がいないと障害時の復元時間（ four-keysの一つ）が長くなる ⇒ 依存ライブラリのアップデートや GKEクラスタのアップデートなど将来の問題の種を早期に対処 ⇒ 将来を見据えた投資だと思って何卒・・・ 24

Slide 25

Slide 25 text

©MIXI 準備も出来たし、いざ説得！ 25

Slide 26

Slide 26 text

©MIXI ＜斯々然々なので遊撃部隊を立ち上げたいです！いいですよ〜＞ 26

Slide 27

Slide 27 text

©MIXI ＜斯々然々なので遊撃部隊を立ち上げたいです！いいですよ〜＞＿人人人人人人人人＿＞　遊撃部隊爆誕＜￣Y^Y^Y^Y^Y^Y^Y￣ 27

Slide 28

Slide 28 text

©MIXI 2. やってきたこと 28

Slide 29

Slide 29 text

©MIXI やってきたことまずはSREを行うチーム（1人）の設立が出来ましたここからは設立から１年ちょっとの間にやってきたことをザザッと紹介します。開発領域に関しては今回の趣旨とはズレますので割愛致しますが、大きいタスクでアプリの新規開発や Webアプリの機能開発、GraphQLのfragment colocationに対応するためのリファクタリングなどを行っておりました。 29

Slide 30

Slide 30 text

©MIXI トイルの撲滅 • スクラム便利ツールの開発 • GitHub Projects betaで管理しているタスクの各ステータス毎の合計ストーリーポイント数を表示するChrome拡張を作成 • 特定のステータスの Issueに関するラベルを一括削除する機能の作成 • マイルストーン毎に必須となるリリース作業タスクなどの Issueを一括作成する機能の作成 • GitHub Projects betaからバーンダウンチャートを生成する君の作成 • QA作業円滑化のためのデバッグツールの作成 • Twitterでの任意のキーワードが含まれたツイートを Slackに通知するやってきたこと〜SRE〜 30

Slide 31

Slide 31 text

Slide 32

Slide 32 text

©MIXI トイルの撲滅 ■ タスクの各ステータス毎の　合計ストーリーポイント数を表示するChrome拡張スプリントプランニング時に何ポイント積んだのかなど確認したいときに役立ちます ■ バーンダウンチャートを生成する君日毎のポイント消化数などのデータをBigQueryに貯めていき、グラフに起こしています 32

Slide 33

Slide 33 text

©MIXI オブザーバビリティの向上 • オオカミ少年アラートにならないように必要な通知の整理 • CPU/メモリ使用率などの各種メトリクスのアラート • high-latencyアラート • Identity-Aware Proxyの適用が外れている環境の発見アラート • uptime checksアラート • GKEのクラスタバージョンアップアラート • Rollbar, Google Cloud Error Reportingなどを使ったエラーログの調査 /トリアージ/共有やってきたこと〜SRE〜 33

Slide 34

Slide 34 text

©MIXI リリースエンジニアリング • Argo CD • バージョンアップ対応（ v1.7 -> v2.3） • Syncが回り続ける問題の解決 • Sync Failed問題の解決 • Migrage JobのSyncが終わらない問題の解決 • Argo CDのapp - repo server間の疎通断調査/対応 • bulletによるN+1問題の検出、Slack通知 • Kubeconformを利用したHelm Templateのチェック機構 • git-pr-releaseを用いたリリースPR作成機能の作成 • リリースPRのCI完了を通知する機能の作成 • developブランチが更新されたら全ての開発環境を最新に更新する機能の作成やってきたこと〜SRE〜 34

Slide 35

Slide 35 text

Slide 36

Slide 36 text

©MIXI リリースエンジニアリング ■ developブランチが更新されたら全ての開発環境を最新に更新する QA作業等の関係から複数の開発環境が存在しており、QA時にはfeatureブランチから適宜デプロイしています。そのため、環境によっては久しくデプロイされていないがために古いコードで動いているという状況があり、QAの妨げになっていました。（フロントエンドは最新だがAPIは古いとか）そこで、developブランチにfeatureブランチがマージされるなどして更新された際に各環境に最新のdevelopブランチを自動でデプロイするような仕組み作りをしたわけです。 36

Slide 37

Slide 37 text

©MIXI インフラの改善/運用/保守 • インフラドキュメントの作成 /整理 • 廃止された古いTLSバージョンを制限した TLSポリシーの適用 • 社内セキュリティ脆弱性指摘への調査 /対応 • Locustを用いた負荷環境の作成 • GKEクラスタ/ノードプールのバージョンアップ調査 /対応 • 一部のPodがTerminated, NodeShutdownのステータスで残り続ける問題の解決 • 非推奨となったKubernetes External SecretsからExternal Secrets Operatorへの移行作業 • External Secrets Operatorのアップグレード調査 /対応 • Workload Identityの導入 • Cloud SQL Proxyのバージョンアップ調査 /対応 • Cloud SQL Proxyシャットダウン時にActive Connectionが存在していても終了してしまう問題の解決やってきたこと〜SRE〜 37

Slide 38

Slide 38 text

©MIXI オンコール対応 • インシデント発生時対応のドキュメント作成 • ポストモーテムの導入 • 年末年始など長期休暇時の監視体制に関する周知 /対応やってきたこと〜SRE〜セキュリティ対応 • 部署内のIAMロールの権限管理についてルール作り • 社内セキュリティ診断結果に基づく対応 • スプレッドシート管理だった秘密情報を 1Passwordで管理するようにした • log4j2など緊急性の高いセキュリティ脆弱性への調査 /共有/啓蒙活動 • GraphQLのセキュリティ調査/対応 38

Slide 39

Slide 39 text

Slide 40

Slide 40 text

©MIXI ■ インシデント発生時対応のドキュメント作成遊撃部隊を始めて初期の頃に取り掛かった作業がこちらでした。インシデントが発生した際のトリアージ/エスカレーションから始まり、「対応者」「記録者」などの役職を割り振って対応を進めましょうといったことが書かれたドキュメントになります。特に大事なこととして「インシデントが発生しても誰も責めない、防げなかった仕組みが悪いという考え方をしてください」といったことは付記しておきました。 SRE本にも書かれていましたが、"非難のない文化"を根付かせたかったので開発チームにも、ここは強く強調して共有しました。非難のない文化は、ミスが致命傷になりうるヘルスケアや航空電子工学の業界に端を発するものです。これらの業界は、すべての「ミス」をシステムを強化する機会と見なす環境を育んできました。 ※ オンコール対応/セキュリティ対応 40 ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム- オライリージャパンより引用

Slide 41

Slide 41 text

©MIXI ■ インシデント発生時対応のドキュメント作成遊撃部隊を始めて初期の頃に取り掛かった作業がこちらでした。インシデントが発生した際のトリアージ/エスカレーションから始まり、「対応者」「記録者」などの役職を割り振って対応を進めましょうといったことが書かれたドキュメントになります。特に大事なこととして「インシデントが発生しても誰も責めない、防げなかった仕組みが悪いという考え方をしてください」といったことは付記しておきました。 SRE本にも書かれていましたが、"非難のない文化"を根付かせたかったので開発チームにも、ここは強く強調して共有しました。非難のない文化は、ミスが致命傷になりうるヘルスケアや航空電子工学の業界に端を発するものです。これらの業界は、すべての「ミス」をシステムを強化する機会と見なす環境を育んできました。 ※ ⇒ちなみにこのあと非常に大きなインシデントが起こり、　早期に取り掛かってて良かったと心底思いましたオンコール対応/セキュリティ対応 41 ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム- オライリージャパンより引用

Slide 42

Slide 42 text

©MIXI DX改善 • CIで利用しているDockerイメージのアップグレード調査・対応 • Renovateの導入、継続的な依存ライブラリアップデート • Figmaでの新着コメントをSlackへ通知する • ログ情報を構造化ログへ対応 • 開発環境の使用状況の可視化 • stagingブランチやproductionブランチからブランチを切ったり、マージしてくるのを防止する CIを作成やってきたこと〜SRE〜 42

Slide 43

Slide 43 text

Slide 44

Slide 44 text

©MIXI ■ 開発環境の使用状況の可視化 QAなどの関係で複数の開発環境があるというお話はしましたが、この開発環境の利用管理にTrelloを使った手動管理をしていました。しかし、手動で管理していると利用が終わっているのにそのままになっていたり、開発環境どこか空いてますか？などの余計なコミュニケーションコストが発生したりしていました。そこで利用状況を可視化し、PRからデプロイすることで利用開始になり、PRクローズで利用終了となるような仕組みを作りました。　がGitHubのREADME上に表示され、利用中の箇所を押下すると利用しているPRに遷移します。詳しい内容は私のブログの「開発環境の使用状況分かるくん」を作って冗長コミュニケーションを無くした話の記事で！ DX改善 44

Slide 45

Slide 45 text

©MIXI やってきたことといったことをやってきました！ 1人SREチームだと1年でこのくらいのタスク量を捌けるのかという一つの参考にしていただけましたら幸いです初期は開発:70%/SRE:30%といったリソース割り振りでやっていて、今では開発 :10%/SRE:90%くらいでかなり SREに注力してやれるようになりましたがまだまだ改善の余地があり、トライしてみたいことが大量にあります。１人でやれることに限界はあるかもしれませんが、 SREの適切な最小人数は SREの探求内のSound Cloudのお話にもあるようにエンジニアの 10%ほどなので、案外チームサイズからすると適切なのかもしれません。ただ、実際にやってみて相談できる人がいないという状況はストレスもあり、閉塞感を抱える原因にもなるので新規でSREチームを立ち上げる！という方がいましたら、 2名からなど複数人でやるのがいいのかもしれません。さて、次はやってみたけども失敗した施策を見ていきましょう！ 45

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

©MIXI 事例１：目安箱この施策は遊撃部隊を立ち上げる少し前になるのですが、開発チームが潜在的に抱えているトイルだったり、 DX改善の芽を拾い上げようという目的で「ここがもう少し便利になったらいいのにな」「こういうツール導入できないかな？」などを投じてもらう目安箱を設置しました。 Google Formsを使って、いつでも何かあったら投票してねと呼びかけてみましたが投票数が少なく、当初期待した目立った効果を上げることは出来ず撤廃することとなりました。これについては「導入時期の問題」と「トイルの自覚」の２点がそもそもの失敗の原因だと分析しました。 ■ 導入時期の問題 • リリースからまだ日が経っておらず、問題として出やすい運用に関するトイルが生まれていなかった • 新規メンバーが入ってまだ間もないタイミングだった ■ トイルの自覚 • トイルは自覚されずに律儀に対応されてしまうことがほとんど 49

Slide 50

Slide 50 text

Slide 51

Slide 51 text

©MIXI 事例２：相談アワー目安箱から半年ちょっと。開発チームを観察すると口頭コミュニケーションが好まれる傾向を見出したので、今度は形式を変えて口頭ベースで相談を受け付けますよ！という相談アワーを試してみました。ちょうどバーチャルオフィスの Gatherを使いだしたところだったので、毎週１時間は必ず定位置にいるので相談したいことがある方に来てもらう、という感じでスタートしました。結果として、こちらの施策は成果に繋がる相談もあったのですが、想定よりも利用頻度が少なく開始から４ヶ月で終了となりました。 51

Slide 52

Slide 52 text

©MIXI ■ Gatherの衰退 • Gatherにログインするメンバーが段々と少なくなっていった • バーチャルオフィスを使うメリットがあまり見出せなかった事例２：相談アワー目安箱から半年ちょっと。開発チームを観察すると口頭コミュニケーションが好まれる傾向を見出したので、今度は形式を変えて口頭ベースで相談を受け付けますよ！という相談アワーを試してみました。ちょうどバーチャルオフィスの Gatherを使いだしたところだったので、毎週１時間は必ず定位置にいるので相談したいことがある方に来てもらう、という感じでスタートしました。結果として、こちらの施策は成果に繋がる相談もあったのですが、想定よりも利用頻度が少なく開始から４ヶ月で終了となりました。 ■ 作業時間を確保したかった • これは失敗理由というよりも終了理由なのですが、 SREにかけられる時間が増えてきた時期で私の作業時間が圧倒的に足りなくなったのもの一つの理由でした 52

Slide 53

Slide 53 text

Slide 54

Slide 54 text

©MIXI 事例３：依存ライブラリのアップデート頻度 Renovateを導入して、今まで２年間アップデートをしてこなかった依存ライブラリを一気にアップデートし、「こりゃ継続的にアップデートしないといかんな」と思いを新たにしました。そこでRenovateの運用に関してのドキュメントを用意し、「一ヶ月に１回はアップデートしていこう！」と息巻いてみたものの・・・結局、他のタスクも逼迫していたのでアップデートに関して調査 /対応するリソースをかけられず早々に狙いは瓦解しましたマイナー/パッチバージョンアップPRの自動マージをすればもう少し楽なのでしょうが、フロントエンドの依存ライブラリでパッチバージョンアップでも後方互換性が担保されないライブラリが多く、そちらに舵を切ることも出来ませんでした。一人SREではやはりリソース管理が非常にシビアになってしまうので、現実的には半期に一回アップデートしていくのが現実的なのかなと思っております。 54

Slide 55

Slide 55 text

©MIXI 失敗は恐れずどんどんやろう SRE本はGoogleがその方法論を「サイトリライアビリティエンジニアリング」として確立したものを紹介しているわけですが、そこに至るまでには多くの試行と失敗がありました。 ※ Googleも失敗を重ねてSREとしてのベストプラクティスを確立させていきました。しかし、SREは原則があるとはいえど組織 /チームの数だけ様々な形があります。つまり、その形にあった施策も様々なものがあり、それを見つけ出していくのも一つの SREの責務だと思います。なので、失敗を恐れずに施策はどんどん展開していくんだと考えて行動していくのをオススメしています。失敗から得られる学びもあるでしょうし、そういった意味だとポストモーテムの考えを適用できそうですしねチャレンジして失敗を恐れるよりも、何もしないことを恐れろ〜本田宗一郎氏の名言〜 55 ※ David N. Blank-Edelman (2021年) SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践オライリージャパンより引用

Slide 56

Slide 56 text

Slide 57

Slide 57 text

©MIXI Next Action ! ここまでやってきたこと /失敗したことをご紹介させていただきましたが、次に Next Actionということで今後やっていかないといけないこと /やりたいことのお話をさせていただきます。この１年、どうしても優先度の関係で後回しになってしまっているタスクがかなりあり、まだまだ改善の余地がある状況です。まだまだ他社のSREに携わられている方々が当たり前のようにやられていることが出来ていないかもしれませんが、一人でやっているという状況も加味していただきまして、ご笑覧いただけると幸いです。 57

Slide 58

Slide 58 text

©MIXI SLI/SLO/エラーバジェットの策定本来なら真っ先に策定しないといけないものでしたが、開発チームに対してのインパクトがあるタスクを優先したために後回しとなってしまっていました。可用性の部分はザックリとメトリクスとして観測できるようにはしているのですが、クリティカルユーザージャーニーの抽出からのSLI、SLO及びエラーバジェットの策定はまだの状況です・・・この２年弱でユーザー数 /リクエスト数ともにかなり増えたので、そろそろやらねばと焦っておりますちなみに、ご存じの方も多いと思いますが策定については GoogleがCloud アーキテクチャセンター内にて「SLO の定義」で説明されていたり、 Google Cloud ブログでも「Setting SLOs: a step-by-step guide」で架空のサービスをもとに解説されているのでオススメです。（個人的には"策定"という点ではSRE本やSREの探求を読むより、後者の記事を読む方がスッと理解できました） 58

Slide 59

Slide 59 text

©MIXI プレビュー環境の自動作成 Pull-Request毎にプレビュー環境を自動で作成する仕組みを作りたいなとずっと思いながら、まだ作れておらず・・・この仕組みについては、メルカリ /Wantedly/リブセンス/はてななどの各社様が取り組まれてテックブログ等で発表されています。弊チームとしてもQA等を行う際の開発環境の枯渇問題には悩まされており、早めに導入したいお気持ちがあります。（ただ実装のカロリーが高そう・・・　　） 59

Slide 60

Slide 60 text

©MIXI Four Keysの導入 GoogleのDORAチームが発表した、チームのデリバリパフォーマンスを測るための４つの指標が Four Keysで • デプロイ頻度 • 変更のリードタイム • サービス復旧までの時間 • デプロイによる障害発生率の４つのメトリクスを指します。継続的なチームのパフォーマンスを計測し、導入した施策等の効果を見るためにも是非とも Four Keysを測りたいなとは思っていましたが、こちらも後回しに・・・（ベクトルは違うが、スクラムのベロシティで生産性が測れたため） 60

Slide 61

Slide 61 text

©MIXI これ以外にもまだまだやりたい！大きな粒度で今後やりたいことをご紹介させていただきましたが、これ以外にもまだまだやらなければいけない / やりたいことはたくさんあります！ただ、リソースの関係から出来ることには限界があります。今年の１月に発表された 2022年の Accelerate State of DevOps Report を読むとこういったことが書かれていました。信頼性は旅である DORAは、組織変革には「J カーブ」があると説明しています。これは、挫折と教訓の後にのみ永続的な成功がもたらされるという現象です。 SRE に対する投資は、より高い信頼性を生み出すでしょうか。答えはイエスですが、注意が必要なのは、初めからそうはならないという点です。※ SREはとかく時間がかかるものです。やりたいことは多くあれど、焦らず地道にやっていきたいものです 61 ※ Goolge Cloud Blog 「2022年のState of DevOps Reportにおける信頼性とSRE」 https://cloud.google.com/blog/ja/products/devops-sre/sre-in-the-2022-state-of-devops-report (参照 2023/02/21) より引用

Slide 62

Slide 62 text

Slide 63

Slide 63 text

©MIXI ここまで取り組んできたことのお話をさせていただきましたが、いかがだったでしょうか？この規模のチームサイズで SREをやって結局どうだったの？という問いには「大変だったけどやってよかった！」という答えになります。もし遊撃部隊を立ち上げず、片手間で作業を回していたらトイルも残ったままで生産性が上がらない状況が続いていたでしょうし、インフラ障害に対しても迅速に検知 /対応するということができなかったかもしれません。一人や小規模でやっていると最初は文化の醸成や、トイルの洗い出し、アラートの整理などインパクトの薄い作業に追われ、割り込みタスクも少なくない状況で SREを進めていくのは中々精神を削られます。ただ、段々とサービスの健全性が積み上がっていく楽しみを味わえるのは一つのモチベーションになるのかなと思いますまた個人的な話で恐縮ですが、これまで SREやGoogle Cloud/K8s等の関連するスキルに対して生半可な知識しか持っていなかったので、 SREの導入はスキルを高められるとても良い機会となりました。まとめ 63