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/2023/d3-3

MIXI ENGINEERS

March 03, 2023
Tweet

Video

More Decks by MIXI ENGINEERS

Other Decks in Technology

Transcript

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

    ・今のチームに合わせてやること・やらないことを切り分けていけば  SREと開発を併行出来るのでは? ・チームが潜在的に抱えている SREに纏わる問題点を説明し、この解消に  動くというメリットを説明すれば OKが貰えるのでは? 16
  2. ©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) より引用
  3. ©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) より引用
  4. ©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) より引用
  5. ©MIXI SREと開発を併行させる なんでも屋さん × 組み込み型SREという関わり方はおかしいことではないことがわかった ⇒ 次に“SRE”と“開発”でやること・やらないことを切り分ける 開発: ・新規機能開発 ・リファクタリング

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

    ・トイルの撲滅 ・オブザーバビリティの向上 ・リリースエンジニアリング ・オンコール対応 ・インフラの改善/運用/保守 ・セキュリティ対応 ・DX改善 開発: ・新規機能開発 ・リファクタリング ・負荷テスト/パフォーマンス改善 ・放置タスクの対応 ・不具合修正 ・スクラム 21
  7. ©MIXI マネージメント層への説得 ここまででやろうとしていることの整理はついた ⇒ ここからはマネージメント層への説得のための材料集め 想定される質疑に対する応答 ・リソースが足りなくなるのが心配 ⇒ 完全に一人分のリソースが無くなるわけじゃないので大丈夫! ⇒

    半年前に入社された3人の開発スピードも上がってきたので、減った分を賄ってくれるはず! ・必要性がイマイチ分からない ⇒ 現状をありのままに伝える ⇒ インフラを専門的に見れる人がいないと障害時の復元時間( four-keysの一つ)が長くなる ⇒ 依存ライブラリのアップデートや GKEクラスタのアップデートなど将来の問題の種を早期に対処 ⇒ 将来を見据えた投資だと思って何卒・・・ 24
  8. ©MIXI トイルの撲滅 • スクラム便利ツールの開発 • GitHub Projects betaで管理しているタスクの各ステータス毎の合計ストーリーポイント数を表示す るChrome拡張を作成 •

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

    特定のステータスの Issueに関するラベルを一括削除する機能の作成 • マイルストーン毎に必須となるリリース作業タスクなどの Issueを一括作成する機能の作成 • GitHub Projects betaからバーンダウンチャートを生成する君の作成 • QA作業円滑化のためのデバッグツールの作成 • Twitterでの任意のキーワードが含まれたツイートを Slackに通知する やってきたこと 〜SRE〜 31
  10. ©MIXI オブザーバビリティの向上 • オオカミ少年アラートにならないように必要な通知の整理 • CPU/メモリ使用率などの各種メトリクスのアラート • high-latencyアラート • Identity-Aware

    Proxyの適用が外れている環境の発見アラート • uptime checksアラート • GKEのクラスタバージョンアップアラート • Rollbar, Google Cloud Error Reportingなどを使ったエラーログの調査 /トリアージ/共有 やってきたこと 〜SRE〜 33
  11. ©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
  12. ©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
  13. ©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
  14. ©MIXI オンコール対応 • インシデント発生時対応のドキュメント作成 • ポストモーテムの導入 • 年末年始など長期休暇時の監視体制に関する周知 /対応 やってきたこと

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

    〜SRE〜 セキュリティ対応 • 部署内のIAMロールの権限管理についてルール作り • 社内セキュリティ診断結果に基づく対応 • スプレッドシート管理だった秘密情報を 1Passwordで管理するようにした • log4j2など緊急性の高いセキュリティ脆弱性への調査 /共有/啓蒙活動 • GraphQLのセキュリティ調査/対応 39
  16. ©MIXI ▪ インシデント発生時対応のドキュメント作成 遊撃部隊を始めて初期の頃に取り掛かった作業がこちらでした。 インシデントが発生した際のトリアージ/エスカレーションから始まり、「対応者」「記録者」などの役職を割り振って対応を進めましょうと いったことが書かれたドキュメントになります。 特に大事なこととして「インシデントが発生しても誰も責めない、防げなかった仕組みが悪いという考え方をしてください」といったこと は付記しておきました。 SRE本にも書かれていましたが、"非難のない文化"を根付かせたかったので開発チームにも、ここは強く強調して共有しました。 非難のない文化は、ミスが致命傷になりうるヘルスケアや航空電子工学の業界に端を発するものです。これらの業界は、す

    べての「ミス」をシステムを強化する機会と見なす環境を育んできました。 ※ ⇒ちなみにこのあと非常に大きなインシデントが起こり、  早期に取り掛かってて良かったと心底思いました オンコール対応/セキュリティ対応 41 ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム- オライリージャパン より引用
  17. ©MIXI DX改善 • CIで利用しているDockerイメージのアップグレード調査・対応 • Renovateの導入、継続的な依存ライブラリアップデート • Figmaでの新着コメントをSlackへ通知する • ログ情報を構造化ログへ対応

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

    • 開発環境の使用状況の可視化 • stagingブランチやproductionブランチからブランチを切ったり、マージしてくるのを防止する CIを作成 やってきたこと 〜SRE〜 43
  19. ©MIXI やってきたこと といったことをやってきました! 1人SREチームだと1年でこのくらいのタスク量を捌けるのかという一つの参考に していただけましたら幸いです 初期は開発:70%/SRE:30%といったリソース割り振りでやっていて、今では開発 :10%/SRE:90%くらいでかなり SREに注力してやれるようになりましたがまだまだ改善の余地があり、トライしてみたいことが大量にあります。 1人でやれることに限界はあるかもしれませんが、 SREの適切な最小人数は

    SREの探求内のSound Cloudのお 話にもあるようにエンジニアの 10%ほどなので、案外チームサイズからすると適切なのかもしれません。 ただ、実際にやってみて相談できる人がいないという状況はストレスもあり、閉塞感を抱える原因にもなるので新 規でSREチームを立ち上げる!という方がいましたら、 2名からなど複数人でやるのがいいのかもしれません。 さて、次はやってみたけども失敗した施策を見ていきましょう! 45
  20. ©MIXI ▪ Gatherの衰退 • Gatherにログインするメンバーが段々と少なくなって いった • バーチャルオフィスを使うメリットがあまり見出せな かった 事例2:相談アワー

    目安箱から半年ちょっと。 開発チームを観察すると口頭コミュニケーションが好まれる傾向を見出したので、今度は形式を変えて口頭ベー スで相談を受け付けますよ!という相談アワーを試してみました。 ちょうどバーチャルオフィスの Gatherを使いだしたところだったので、毎週1時間は必ず定位置にいるので相談 したいことがある方に来てもらう、という感じでスタートしました。 結果として、こちらの施策は成果に繋がる相談もあったのですが、 想定よりも利用頻度が少なく開始から4ヶ月で終了となりました。 ▪ 作業時間を確保したかった • これは失敗理由というよりも終了理由なのですが、 SREにかけられる時間が増えてきた時期で私の作業 時間が圧倒的に足りなくなったのもの一つの理由でし た 52
  21. ©MIXI 事例3:依存ライブラリのアップデート頻度 Renovateを導入して、今まで2年間アップデートをしてこなかった依存ライブラリを一気にアップデートし、「こりゃ 継続的にアップデートしないといかんな」と思いを新たにしました。 そこでRenovateの運用に関してのドキュメントを用意し、「一ヶ月に1回はアップデートしていこう!」と息巻いて みたものの・・・ 結局、他のタスクも逼迫していたのでアップデートに関して調査 /対応するリソースをかけられず早々に狙いは瓦 解しました マイナー/パッチ

    バージョンアップPRの自動マージをすればもう少し楽なのでしょうが、フロントエンドの依存ライ ブラリでパッチバージョンアップでも後方互換性が担保されないライブラリが多く、そちらに舵を切ることも出来ま せんでした。 一人SREではやはりリソース管理が非常にシビアになってしまうので、現実的には半期に一回アップデートして いくのが現実的なのかなと思っております。 54
  22. ©MIXI 失敗は恐れずどんどんやろう SRE本はGoogleがその方法論を「サイトリライアビリティエンジニアリング」として確立したものを紹介しているわ けですが、そこに至るまでには多くの試行と失敗がありました。 ※ Googleも失敗を重ねてSREとしてのベストプラクティスを確立させていきました。 しかし、SREは原則があるとはいえど組織 /チームの数だけ様々な形があります。つまり、その形にあった施策も 様々なものがあり、それを見つけ出していくのも一つの SREの責務だと思います。

    なので、失敗を恐れずに施策はどんどん展開していくんだと考えて行動していくのをオススメしています。失敗か ら得られる学びもあるでしょうし、そういった意味だとポストモーテムの考えを適用できそうですしね チャレンジして失敗を恐れるよりも、何もしないことを恐れろ 〜本田宗一郎氏の名言〜 55 ※ David N. Blank-Edelman (2021年) SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践 オライリージャパン より引用
  23. ©MIXI Next Action ! ここまでやってきたこと /失敗したことをご紹介させていただきましたが、次に Next Actionということで今後やって いかないといけないこと /やりたいことのお話をさせていただきます。

    この1年、どうしても優先度の関係で後回しになってしまっているタスクがかなりあり、まだまだ改善の余地があ る状況です。 まだまだ他社のSREに携わられている方々が当たり前のようにやられていることが出来ていないかもしれません が、一人でやっているという状況も加味していただきまして、ご笑覧いただけると幸いです。 57
  24. ©MIXI Four Keysの導入 GoogleのDORAチームが発表した、チームのデリバリパフォーマンスを測るための4つの指標が Four Keysで • デプロイ頻度 • 変更のリードタイム

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