Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

動画:https://youtu.be/o6G9qx--Lwk

https://techcon.mixi.co.jp/d3-3

MIXI ENGINEERS

March 03, 2023
Tweet

More Decks by MIXI ENGINEERS

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  4. ©MIXI
    気にはなるけどまだ手が出せてない方
    所属会社の規模だとSREはまだ早いと思っている方

    もしそんな方がいましたら、当セッションで
    何か得るものがあれば幸いです 
    4

    View full-size slide

  5. ©MIXI
    今日お話すること
    5

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. ©MIXI
    よっしゃ!全力でSREや! 

    とはいかない
    14

    View full-size slide

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

    View full-size slide

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

    [対策を考えよう]
    ・今のチームに合わせてやること・やらないことを切り分けていけば
     SREと開発を併行出来るのでは?
    ・チームが潜在的に抱えている SREに纏わる問題点を説明し、この解消に
     動くというメリットを説明すれば OKが貰えるのでは?
    16

    View full-size slide

  17. ©MIXI
    SREと開発を併行させる
    そもそもそれってアリなの?というところから調べる
    ⇒ SRE発祥、Google社ブログにてこんな記事が
    How SRE teams are organized, and how to get started
    (SREチームの編成方法とその始め方) ※
    この中で6つの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) より引用

    View full-size slide

  18. ©MIXI
    SREと開発を併行させる
    そもそもそれってアリなの?というところから調べる
    ⇒ SRE発祥、Google社ブログにてこんな記事が
    How SRE teams are organized, and how to get started
    (SREチームの編成方法とその始め方) ※
    この中で6つの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) より引用

    View full-size slide

  19. ©MIXI
    SREと開発を併行させる
    そもそもそれってアリなの?というところから調べる
    ⇒ SRE発祥、Google社ブログにてこんな記事が
    How SRE teams are organized, and how to get started
    (SREチームの編成方法とその始め方) ※
    この中で6つの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) より引用

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  26. ©MIXI
    < 斯々然々なので遊撃部隊を立ち上げたいです!
    いいですよ〜>
    26

    View full-size slide

  27. ©MIXI
    < 斯々然々なので遊撃部隊を立ち上げたいです!
    いいですよ〜>
    _人人人人人人人人_
    > 遊撃部隊 爆誕 <
     ̄Y^Y^Y^Y^Y^Y^Y ̄
    27

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  40. ©MIXI
    ■ インシデント発生時対応のドキュメント作成
    遊撃部隊を始めて初期の頃に取り掛かった作業がこちらでした。
    インシデントが発生した際のトリアージ/エスカレーションから始まり、「対応者」「記録者」などの役職を割り振って対応を進めましょうと
    いったことが書かれたドキュメントになります。
    特に大事なこととして「インシデントが発生しても誰も責めない、防げなかった仕組みが悪いという考え方をしてください」といったこと
    は付記しておきました。
    SRE本にも書かれていましたが、"非難のない文化"を根付かせたかったので開発チームにも、ここは強く強調して共有しました。
    非難のない文化は、ミスが致命傷になりうるヘルスケアや航空電子工学の業界に端を発するものです。これらの業界は、す
    べての「ミス」をシステムを強化する機会と見なす環境を育んできました。

    オンコール対応/セキュリティ対応
    40 ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム- オライリージャパン より引用

    View full-size slide

  41. ©MIXI
    ■ インシデント発生時対応のドキュメント作成
    遊撃部隊を始めて初期の頃に取り掛かった作業がこちらでした。
    インシデントが発生した際のトリアージ/エスカレーションから始まり、「対応者」「記録者」などの役職を割り振って対応を進めましょうと
    いったことが書かれたドキュメントになります。
    特に大事なこととして「インシデントが発生しても誰も責めない、防げなかった仕組みが悪いという考え方をしてください」といったこと
    は付記しておきました。
    SRE本にも書かれていましたが、"非難のない文化"を根付かせたかったので開発チームにも、ここは強く強調して共有しました。
    非難のない文化は、ミスが致命傷になりうるヘルスケアや航空電子工学の業界に端を発するものです。これらの業界は、す
    べての「ミス」をシステムを強化する機会と見なす環境を育んできました。

    ⇒ちなみにこのあと非常に大きなインシデントが起こり、
     早期に取り掛かってて良かったと心底思いました
    オンコール対応/セキュリティ対応
    41 ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム- オライリージャパン より引用

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  46. ©MIXI
    3. 失敗した施策の紹介
    46

    View full-size slide

  47. ©MIXI
    事例1:目安箱
    47

    View full-size slide

  48. ©MIXI
    事例1:目安箱
    この施策は遊撃部隊を立ち上げる少し前になるのですが、開発チームが潜在的に抱えているトイルだったり、
    DX改善の芽を拾い上げようという目的で「ここがもう少し便利になったらいいのにな」「こういうツール導入できな
    いかな?」などを投じてもらう目安箱を設置しました。
    Google Formsを使って、いつでも何かあったら投票してねと呼びかけてみましたが投票数が少なく、当初期待し
    た目立った効果を上げることは出来ず撤廃することとなりました。
    これについては「導入時期の問題」と「トイルの自覚」の2点がそもそもの失敗の原因だと分析しました。
    48

    View full-size slide

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

    View full-size slide

  50. ©MIXI
    事例2:相談アワー
    50

    View full-size slide

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

    View full-size slide

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

    52

    View full-size slide

  53. ©MIXI
    事例3:依存ライブラリのアップデート頻度
    53

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  56. ©MIXI
    4. Next Action !
    56

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  61. ©MIXI
    これ以外にもまだまだやりたい!
    大きな粒度で今後やりたいことをご紹介させていただきましたが、これ以外にもまだまだやらなければいけない /
    やりたいことはたくさんあります!
    ただ、リソースの関係から出来ることには限界があります。
    今年の1月に発表された 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)
    より引用

    View full-size slide

  62. ©MIXI
    5. まとめ
    62

    View full-size slide

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

    View full-size slide

  64. ©MIXI
    SREが必要だと感じたら思い切ってやってみよう!
    ご清聴ありがとうございました
    64

    View full-size slide