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