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

MIXI TECH CONFERENCE 2023
にてお話した井上の資料です。

動画：https://youtu.be/o6G9qx--Lwk
セッション詳細：https://techcon.mixi.co.jp/2023/d3-3

1. ©MIXI 小さなサービスでの SREとの付き合い方 井上 翔太 1
2. ©MIXI 自己紹介 名前：井上 翔太 twitter：@syossan27 2019年にミクシィ（現MIXI）入社 サーバーサイドを中心に開発していたが、最近はSRE チックなことをやっています 2
3. ©MIXI 皆さん、SREやってますか？ 3
4. ©MIXI 気にはなるけどまだ手が出せてない方 所属会社の規模だとSREはまだ早いと思っている方 ↓ もしそんな方がいましたら、当セッションで 何か得るものがあれば幸いです　 4
5. ©MIXI 今日お話すること 5
6. ©MIXI 1. 小さなサービスでSREって必要？ 2. やってきたこと 3. 失敗した施策の紹介 4. Next Action ! 5. まとめ 6
7. ©MIXI 1. 小さなサービスでSREって必要？ 7
8. ©MIXI 開発チーム人数：3人 ⇒ 8人 どのくらいの規模のサービス？ リリースされてから： 1年11ヶ月 MAU/WAU/DAU： ユーザー登録数： 徐々に大きくはなってきてる 8
9. ©MIXI で、SREは何故必要だったの？　 9
10. ©MIXI 何故SREは必要となったか？ 〜2021の私〜 ▪ 2021/03〜 とある機能の実装の流れからインフラをちょこちょこと触るようになる ▪ 2021/04〜 負荷計測・パフォーマンスチューニング、インフラ・デプロイフローの障害時調査などのタスクに積極的に関わる ▪ 〜2021/10 上記を続けながらアラートを追加したり整理したり、トイルを無くすように仕組み作りをしたり、インシデント管理を したり・・・ 10
11. ©MIXI あれ？これってSREってやつなんじゃない？　　 11
12. ©MIXI 何故SREは必要となったか？ 気付いたら"SRE"と呼ばれることをやっていた ⇒ サービス規模に関わらず、 SREは誰かが必ずやっている SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもので す。※ 小さなチームでは運用チームを持たないことが多いので（雰囲気兼任が多い） 自然発生的に“明確な”運用チームの動きが生まれたらそれが SREとも言える ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム オライリージャパン より引用 12
13. ©MIXI よっしゃ！全力でSREや！　 13
14. ©MIXI よっしゃ！全力でSREや！　 ↓ とはいかない 14
15. ©MIXI 何故全力でSREやっちゃダメなのか？ 十二分に人的リソースがあるチームならやっても良い ⇒ しかし、スモールチームの場合には新規機能開発への致命な人的リソース不足になる可能性が ⇒ マネージメント層にもやっちゃダメと NGを喰らうことも 15
16. ©MIXI 何故全力でSREやっちゃダメなのか？ 十二分に人的リソースがあるチームならやっても良い ⇒ しかし、スモールチームの場合には新規機能開発への致命な人的リソース不足になる可能性が ⇒ マネージメント層にもやっちゃダメと NGを喰らうことも ⇓ [対策を考えよう] ・今のチームに合わせてやること・やらないことを切り分けていけば 　SREと開発を併行出来るのでは？ ・チームが潜在的に抱えている SREに纏わる問題点を説明し、この解消に 　動くというメリットを説明すれば OKが貰えるのでは？ 16
17. ©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) より引用
18. ©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) より引用
19. ©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) より引用
20. ©MIXI SREと開発を併行させる なんでも屋さん × 組み込み型SREという関わり方はおかしいことではないことがわかった ⇒ 次に“SRE”と“開発”でやること・やらないことを切り分ける 開発： ・新規機能開発 ・リファクタリング ・負荷テスト/パフォーマンス改善 ・放置タスクの対応 ・不具合修正 ・スクラム SRE： ・SLI/SLO, エラーバジェットの策定 ・トイルの撲滅 ・オブザーバビリティの向上 ・リリースエンジニアリング ・オンコール対応 ・インフラの改善/運用/保守 ・セキュリティ対応 ・DX改善 20
21. ©MIXI SREと開発を併行させる なんでも屋さん × 組み込み型SREという関わり方はおかしいことではないことがわかった ⇒ 次に“SRE”と“開発”でやること・やらないことを切り分ける SRE： ・SLI/SLO, エラーバジェットの策定 ・トイルの撲滅 ・オブザーバビリティの向上 ・リリースエンジニアリング ・オンコール対応 ・インフラの改善/運用/保守 ・セキュリティ対応 ・DX改善 開発： ・新規機能開発 ・リファクタリング ・負荷テスト/パフォーマンス改善 ・放置タスクの対応 ・不具合修正 ・スクラム 21
22. ©MIXI やることは多いが何とかなりそう　 22
23. ©MIXI SREと開発を併行させる ただ、このまま“SRE”というポジションで開始すると SREはプロダクトの機能開発も兼ねる人と 勘違いされないか？ ⇒ 何か別の言い方が出来るポジションで始めたい！ Misoca社様がやってらっしゃる 「遊軍チーム」の取り組みが これからやろうとしていることとしっくり来たのでお名前を拝借した ⇒ 「遊撃部隊」という名前で始めよう！ 23
24. ©MIXI マネージメント層への説得 ここまででやろうとしていることの整理はついた ⇒ ここからはマネージメント層への説得のための材料集め 想定される質疑に対する応答 ・リソースが足りなくなるのが心配 ⇒ 完全に一人分のリソースが無くなるわけじゃないので大丈夫！ ⇒ 半年前に入社された３人の開発スピードも上がってきたので、減った分を賄ってくれるはず！ ・必要性がイマイチ分からない ⇒ 現状をありのままに伝える ⇒ インフラを専門的に見れる人がいないと障害時の復元時間（ four-keysの一つ）が長くなる ⇒ 依存ライブラリのアップデートや GKEクラスタのアップデートなど将来の問題の種を早期に対処 ⇒ 将来を見据えた投資だと思って何卒・・・ 24
25. ©MIXI 準備も出来たし、いざ説得！ 25
26. ©MIXI ＜ 斯々然々なので遊撃部隊を立ち上げたいです！ いいですよ〜＞ 26
27. ©MIXI ＜ 斯々然々なので遊撃部隊を立ち上げたいです！ いいですよ〜＞ ＿人人人人人人人人＿ ＞　遊撃部隊 爆誕 ＜ ￣Y^Y^Y^Y^Y^Y^Y￣ 27
28. ©MIXI 2. やってきたこと 28
29. ©MIXI やってきたこと まずはSREを行うチーム（1人）の設立が出来ました ここからは設立から１年ちょっとの間にやってきたことをザザッと紹介します。 開発領域に関しては今回の趣旨とはズレますので割愛致しますが、大きいタスクでアプリの新規開発や Webア プリの機能開発、GraphQLのfragment colocationに対応するためのリファクタリングなどを行っておりました。 29
30. ©MIXI トイルの撲滅 • スクラム便利ツールの開発 • GitHub Projects betaで管理しているタスクの各ステータス毎の合計ストーリーポイント数を表示す るChrome拡張を作成 • 特定のステータスの Issueに関するラベルを一括削除する機能の作成 • マイルストーン毎に必須となるリリース作業タスクなどの Issueを一括作成する機能の作成 • GitHub Projects betaからバーンダウンチャートを生成する君の作成 • QA作業円滑化のためのデバッグツールの作成 • Twitterでの任意のキーワードが含まれたツイートを Slackに通知する やってきたこと 〜SRE〜 30
31. ©MIXI トイルの撲滅 • スクラム便利ツールの開発 • GitHub Projects betaで管理しているタスクの各ステータス毎の合計ストーリーポイント数を表示す るChrome拡張を作成 • 特定のステータスの Issueに関するラベルを一括削除する機能の作成 • マイルストーン毎に必須となるリリース作業タスクなどの Issueを一括作成する機能の作成 • GitHub Projects betaからバーンダウンチャートを生成する君の作成 • QA作業円滑化のためのデバッグツールの作成 • Twitterでの任意のキーワードが含まれたツイートを Slackに通知する やってきたこと 〜SRE〜 31
32. ©MIXI トイルの撲滅 ▪ タスクの各ステータス毎の 　 合計ストーリーポイント数を表示するChrome拡張 スプリントプランニング時に何ポイント積んだのかなど 確認したいときに役立ちます ▪ バーンダウンチャートを生成する君 日毎のポイント消化数などのデータをBigQueryに貯めていき、 グラフに起こしています 32
33. ©MIXI オブザーバビリティの向上 • オオカミ少年アラートにならないように必要な通知の整理 • CPU/メモリ使用率などの各種メトリクスのアラート • high-latencyアラート • Identity-Aware Proxyの適用が外れている環境の発見アラート • uptime checksアラート • GKEのクラスタバージョンアップアラート • Rollbar, Google Cloud Error Reportingなどを使ったエラーログの調査 /トリアージ/共有 やってきたこと 〜SRE〜 33
34. ©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
35. ©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〜 35
36. ©MIXI リリースエンジニアリング ▪ developブランチが更新されたら全ての開発環境を最新に更新する QA作業等の関係から複数の開発環境が存在しており、QA時にはfeatureブランチから適宜デプロイしています。 そのため、環境によっては久しくデプロイされていないがために古いコードで動いているという状況があり、QAの妨げになっていまし た。（フロントエンドは最新だがAPIは古いとか） そこで、developブランチにfeatureブランチがマージされるなどして更新された際に各環境に最新のdevelopブランチを自動でデプ ロイするような仕組み作りをしたわけです。 36
37. ©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
38. ©MIXI オンコール対応 • インシデント発生時対応のドキュメント作成 • ポストモーテムの導入 • 年末年始など長期休暇時の監視体制に関する周知 /対応 やってきたこと 〜SRE〜 セキュリティ対応 • 部署内のIAMロールの権限管理についてルール作り • 社内セキュリティ診断結果に基づく対応 • スプレッドシート管理だった秘密情報を 1Passwordで管理するようにした • log4j2など緊急性の高いセキュリティ脆弱性への調査 /共有/啓蒙活動 • GraphQLのセキュリティ調査/対応 38
39. ©MIXI オンコール対応 • インシデント発生時対応のドキュメント作成 • ポストモーテムの導入 • 年末年始など長期休暇時の監視体制に関する周知 /対応 やってきたこと 〜SRE〜 セキュリティ対応 • 部署内のIAMロールの権限管理についてルール作り • 社内セキュリティ診断結果に基づく対応 • スプレッドシート管理だった秘密情報を 1Passwordで管理するようにした • log4j2など緊急性の高いセキュリティ脆弱性への調査 /共有/啓蒙活動 • GraphQLのセキュリティ調査/対応 39
40. ©MIXI ▪ インシデント発生時対応のドキュメント作成 遊撃部隊を始めて初期の頃に取り掛かった作業がこちらでした。 インシデントが発生した際のトリアージ/エスカレーションから始まり、「対応者」「記録者」などの役職を割り振って対応を進めましょうと いったことが書かれたドキュメントになります。 特に大事なこととして「インシデントが発生しても誰も責めない、防げなかった仕組みが悪いという考え方をしてください」といったこと は付記しておきました。 SRE本にも書かれていましたが、"非難のない文化"を根付かせたかったので開発チームにも、ここは強く強調して共有しました。 非難のない文化は、ミスが致命傷になりうるヘルスケアや航空電子工学の業界に端を発するものです。これらの業界は、す べての「ミス」をシステムを強化する機会と見なす環境を育んできました。 ※ オンコール対応/セキュリティ対応 40 ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム- オライリージャパン より引用
41. ©MIXI ▪ インシデント発生時対応のドキュメント作成 遊撃部隊を始めて初期の頃に取り掛かった作業がこちらでした。 インシデントが発生した際のトリアージ/エスカレーションから始まり、「対応者」「記録者」などの役職を割り振って対応を進めましょうと いったことが書かれたドキュメントになります。 特に大事なこととして「インシデントが発生しても誰も責めない、防げなかった仕組みが悪いという考え方をしてください」といったこと は付記しておきました。 SRE本にも書かれていましたが、"非難のない文化"を根付かせたかったので開発チームにも、ここは強く強調して共有しました。 非難のない文化は、ミスが致命傷になりうるヘルスケアや航空電子工学の業界に端を発するものです。これらの業界は、す べての「ミス」をシステムを強化する機会と見なす環境を育んできました。 ※ ⇒ちなみにこのあと非常に大きなインシデントが起こり、 　早期に取り掛かってて良かったと心底思いました オンコール対応/セキュリティ対応 41 ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム- オライリージャパン より引用
42. ©MIXI DX改善 • CIで利用しているDockerイメージのアップグレード調査・対応 • Renovateの導入、継続的な依存ライブラリアップデート • Figmaでの新着コメントをSlackへ通知する • ログ情報を構造化ログへ対応 • 開発環境の使用状況の可視化 • stagingブランチやproductionブランチからブランチを切ったり、マージしてくるのを防止する CIを作成 やってきたこと 〜SRE〜 42
43. ©MIXI DX改善 • CIで利用しているDockerイメージのアップグレード調査・対応 • Renovateの導入、継続的な依存ライブラリアップデート • Figmaでの新着コメントをSlackへ通知する • ログ情報を構造化ログへ対応 • 開発環境の使用状況の可視化 • stagingブランチやproductionブランチからブランチを切ったり、マージしてくるのを防止する CIを作成 やってきたこと 〜SRE〜 43
44. ©MIXI ▪ 開発環境の使用状況の可視化 QAなどの関係で複数の開発環境があるというお話はしましたが、この開発環境の利用管理にTrelloを使った手動管理をしていまし た。 しかし、手動で管理していると利用が終わっているのにそのままになっていたり、開発環境どこか空いてますか？などの余計なコミュ ニケーションコストが発生したりしていました。 そこで利用状況を可視化し、PRからデプロイすることで利用開始になり、PRクローズで利用終了となるような仕組みを作りました。 　 がGitHubのREADME上に表示され、利用中の箇所を押下すると 利用しているPRに遷移します。 詳しい内容は私のブログの 「開発環境の使用状況分かるくん」を作って 冗長コミュニケーションを無くした話 の記事で！ DX改善 44
45. ©MIXI やってきたこと といったことをやってきました！ 1人SREチームだと1年でこのくらいのタスク量を捌けるのかという一つの参考に していただけましたら幸いです 初期は開発:70%/SRE:30%といったリソース割り振りでやっていて、今では開発 :10%/SRE:90%くらいでかなり SREに注力してやれるようになりましたがまだまだ改善の余地があり、トライしてみたいことが大量にあります。 １人でやれることに限界はあるかもしれませんが、 SREの適切な最小人数は SREの探求内のSound Cloudのお 話にもあるようにエンジニアの 10%ほどなので、案外チームサイズからすると適切なのかもしれません。 ただ、実際にやってみて相談できる人がいないという状況はストレスもあり、閉塞感を抱える原因にもなるので新 規でSREチームを立ち上げる！という方がいましたら、 2名からなど複数人でやるのがいいのかもしれません。 さて、次はやってみたけども失敗した施策を見ていきましょう！ 45
46. ©MIXI 3. 失敗した施策の紹介 46
47. ©MIXI 事例１：目安箱 47
48. ©MIXI 事例１：目安箱 この施策は遊撃部隊を立ち上げる少し前になるのですが、開発チームが潜在的に抱えているトイルだったり、 DX改善の芽を拾い上げようという目的で「ここがもう少し便利になったらいいのにな」「こういうツール導入できな いかな？」などを投じてもらう目安箱を設置しました。 Google Formsを使って、いつでも何かあったら投票してねと呼びかけてみましたが投票数が少なく、当初期待し た目立った効果を上げることは出来ず撤廃することとなりました。 これについては「導入時期の問題」と「トイルの自覚」の２点がそもそもの失敗の原因だと分析しました。 48
49. ©MIXI 事例１：目安箱 この施策は遊撃部隊を立ち上げる少し前になるのですが、開発チームが潜在的に抱えているトイルだったり、 DX改善の芽を拾い上げようという目的で「ここがもう少し便利になったらいいのにな」「こういうツール導入できな いかな？」などを投じてもらう目安箱を設置しました。 Google Formsを使って、いつでも何かあったら投票してねと呼びかけてみましたが投票数が少なく、当初期待し た目立った効果を上げることは出来ず撤廃することとなりました。 これについては「導入時期の問題」と「トイルの自覚」の２点がそもそもの失敗の原因だと分析しました。 ▪ 導入時期の問題 • リリースからまだ日が経っておらず、問題として出やす い運用に関するトイルが生まれていなかった • 新規メンバーが入ってまだ間もないタイミングだった ▪ トイルの自覚 • トイルは自覚されずに律儀に対応されてしまうことが ほとんど 49
50. ©MIXI 事例２：相談アワー 50
51. ©MIXI 事例２：相談アワー 目安箱から半年ちょっと。 開発チームを観察すると口頭コミュニケーションが好まれる傾向を見出したので、今度は形式を変えて口頭ベー スで相談を受け付けますよ！という相談アワーを試してみました。 ちょうどバーチャルオフィスの Gatherを使いだしたところだったので、毎週１時間は必ず定位置にいるので相談 したいことがある方に来てもらう、という感じでスタートしました。 結果として、こちらの施策は成果に繋がる相談もあったのですが、 想定よりも利用頻度が少なく開始から４ヶ月で終了となりました。 51
52. ©MIXI ▪ Gatherの衰退 • Gatherにログインするメンバーが段々と少なくなって いった • バーチャルオフィスを使うメリットがあまり見出せな かった 事例２：相談アワー 目安箱から半年ちょっと。 開発チームを観察すると口頭コミュニケーションが好まれる傾向を見出したので、今度は形式を変えて口頭ベー スで相談を受け付けますよ！という相談アワーを試してみました。 ちょうどバーチャルオフィスの Gatherを使いだしたところだったので、毎週１時間は必ず定位置にいるので相談 したいことがある方に来てもらう、という感じでスタートしました。 結果として、こちらの施策は成果に繋がる相談もあったのですが、 想定よりも利用頻度が少なく開始から４ヶ月で終了となりました。 ▪ 作業時間を確保したかった • これは失敗理由というよりも終了理由なのですが、 SREにかけられる時間が増えてきた時期で私の作業 時間が圧倒的に足りなくなったのもの一つの理由でし た 52
53. ©MIXI 事例３：依存ライブラリのアップデート頻度 53
54. ©MIXI 事例３：依存ライブラリのアップデート頻度 Renovateを導入して、今まで２年間アップデートをしてこなかった依存ライブラリを一気にアップデートし、「こりゃ 継続的にアップデートしないといかんな」と思いを新たにしました。 そこでRenovateの運用に関してのドキュメントを用意し、「一ヶ月に１回はアップデートしていこう！」と息巻いて みたものの・・・ 結局、他のタスクも逼迫していたのでアップデートに関して調査 /対応するリソースをかけられず早々に狙いは瓦 解しました マイナー/パッチ バージョンアップPRの自動マージをすればもう少し楽なのでしょうが、フロントエンドの依存ライ ブラリでパッチバージョンアップでも後方互換性が担保されないライブラリが多く、そちらに舵を切ることも出来ま せんでした。 一人SREではやはりリソース管理が非常にシビアになってしまうので、現実的には半期に一回アップデートして いくのが現実的なのかなと思っております。 54
55. ©MIXI 失敗は恐れずどんどんやろう SRE本はGoogleがその方法論を「サイトリライアビリティエンジニアリング」として確立したものを紹介しているわ けですが、そこに至るまでには多くの試行と失敗がありました。 ※ Googleも失敗を重ねてSREとしてのベストプラクティスを確立させていきました。 しかし、SREは原則があるとはいえど組織 /チームの数だけ様々な形があります。つまり、その形にあった施策も 様々なものがあり、それを見つけ出していくのも一つの SREの責務だと思います。 なので、失敗を恐れずに施策はどんどん展開していくんだと考えて行動していくのをオススメしています。失敗か ら得られる学びもあるでしょうし、そういった意味だとポストモーテムの考えを適用できそうですしね チャレンジして失敗を恐れるよりも、何もしないことを恐れろ 〜本田宗一郎氏の名言〜 55 ※ David N. Blank-Edelman (2021年) SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践 オライリージャパン より引用
56. ©MIXI 4. Next Action ! 56
57. ©MIXI Next Action ! ここまでやってきたこと /失敗したことをご紹介させていただきましたが、次に Next Actionということで今後やって いかないといけないこと /やりたいことのお話をさせていただきます。 この１年、どうしても優先度の関係で後回しになってしまっているタスクがかなりあり、まだまだ改善の余地があ る状況です。 まだまだ他社のSREに携わられている方々が当たり前のようにやられていることが出来ていないかもしれません が、一人でやっているという状況も加味していただきまして、ご笑覧いただけると幸いです。 57
58. ©MIXI SLI/SLO/エラーバジェットの策定 本来なら真っ先に策定しないといけないものでしたが、開発チームに対してのインパクトがあるタスクを優先した ために後回しとなってしまっていました。 可用性の部分はザックリとメトリクスとして観測できるようにはしているのですが、クリティカルユーザージャー ニーの抽出からのSLI、SLO及びエラーバジェットの策定はまだの状況です・・・ この２年弱でユーザー数 /リクエスト数ともにかなり増えたので、そろそろやらねばと焦っております ちなみに、ご存じの方も多いと思いますが策定については GoogleがCloud アーキテクチャ センター内にて「SLO の定義」で説明されていたり、 Google Cloud ブログでも「Setting SLOs: a step-by-step guide」で架空のサービ スをもとに解説されているのでオススメです。 （個人的には"策定"という点ではSRE本やSREの探求を読むより、後者の記事を読む方がスッと理解できました） 58
59. ©MIXI プレビュー環境の自動作成 Pull-Request毎にプレビュー環境を自動で作成する仕組みを作りたいなとずっと思いながら、まだ作れておらず ・・・ この仕組みについては、メルカリ /Wantedly/リブセンス/はてななどの各社様が取り組まれてテックブログ等で発 表されています。 弊チームとしてもQA等を行う際の開発環境の枯渇問題には悩まされており、早めに導入したいお気持ちがあり ます。 （ただ実装のカロリーが高そう・・・　　） 59
60. ©MIXI Four Keysの導入 GoogleのDORAチームが発表した、チームのデリバリパフォーマンスを測るための４つの指標が Four Keysで • デプロイ頻度 • 変更のリードタイム • サービス復旧までの時間 • デプロイによる障害発生率 の４つのメトリクスを指します。 継続的なチームのパフォーマンスを計測し、導入した施策等の効果を見るためにも是非とも Four Keysを測りた いなとは思っていましたが、こちらも後回しに・・・ （ベクトルは違うが、スクラムのベロシティで生産性が測れたため） 60
61. ©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) より引用
62. ©MIXI 5. まとめ 62
63. ©MIXI ここまで取り組んできたことのお話をさせていただきましたが、いかがだったでしょうか？ この規模のチームサイズで SREをやって結局どうだったの？という問いには「大変だったけどやってよかった！」 という答えになります。 もし遊撃部隊を立ち上げず、片手間で作業を回していたらトイルも残ったままで生産性が上がらない状況が続い ていたでしょうし、インフラ障害に対しても迅速に検知 /対応するということができなかったかもしれません。 一人や小規模でやっていると最初は文化の醸成や、トイルの洗い出し、アラートの整理などインパクトの薄い作 業に追われ、割り込みタスクも少なくない状況で SREを進めていくのは中々精神を削られます。 ただ、段々とサービスの健全性が積み上がっていく楽しみを味わえるのは一つのモチベーションになるのかなと 思います また個人的な話で恐縮ですが、これまで SREやGoogle Cloud/K8s等の関連するスキルに対して生半可な知識 しか持っていなかったので、 SREの導入はスキルを高められるとても良い機会となりました。 まとめ 63
64. ©MIXI SREが必要だと感じたら思い切ってやってみよう！ ご清聴ありがとうございました 64