Zenn
Open7

【マネーフォワードSRE Meetup】多様化し続けるSREのLT会

#
SRE
#
勉強会まとめ
しげるしげる

「自律した開発組織の実現を目指して、Enabling SRE」

横断 SRE と 各プロダクトチーム

  • インフラチーム
  • Enabling SRE
  • 各チーム（SRE / 開発チーム）

各チームを強制するのではなく、サポートしていくことがメイン

当初に考えていたこと

  • いきなり全体にSREを浸透させるのは難しい
  • Enabling SRE のビジョンやアクションを共有できていない

挑戦したこと

  • アーリーアダプターとなってくれるチームを探して、フォローしていく
  • 社内の SRE に関する情報を集める

ビジョンやアクションについて共有できていない

  • 社内外への発信を通して、実現したい世界や考えを伝えた

アクション

  • 実際にチームに入って、SRE の成功事例を作った
  • SREに関するアンケートやSRE成熟度表を作った
  • Enabling SREについて伝える
    • 社内イベント / ブログ / 勉強会

Q&A

  • Q. SREの成功事例を作るといいうことですが受け入れ側のチームでの反発や想定外の反応などはなかったのでしょうか？

    • A. 協力的なチームからフォローしているので、大きな反発はない

  • Q. Embedded SREとEnabling SREの違いは何ですか？

    • A.
      • Embedded = 開発チームの中に入って、自分たちも含めて SREをする
      • Enabling = 開発チームのメンバーが SRE 業もできるようにする

  • Q. アーリーアダプターを作っていくのが一番難しかったのではないかと思うのですが、一番苦労された点工夫された点などがあれば知りたいです。

    • A. slack の会話などで、やろうとしているチームにフォローに入りたいが、最初のフォローが難しかった
しげるしげる

「Platform SREによる運用負荷の最小化と開発生産性の最大化」

https://twitter.com/grezarjp/status/1562025025477025794?s=20&t=abzJ6XdwAjNz9sYzgegyRQ

ゴール

マネーフォワードの Platform SREがなにをしているかぼんやりわかること

What's Platform SRE

  • プロダクトチームが開発しているサービスを動かすための開発、運用をしている
  • 権限と責任を渡すための基盤や仕組みを作っている
  • 運用不可の最小化 / 開発生産性の最大化を目指している

Why we are here

  • 運用チームと開発チームが完全に分かれていた
    • 開発チームが増えていく中で、運用チームがボトルネックになりつつあった
    • 運用をプロダクトチームからブラックボックス化しない
    • プロダクトチームが運用も見守る = ユーザーへの価値提供の鈍化を意味する
      • Platform SRE がなるべく知見を共有できるようにする

How we do that.

  1. 簡単なインプットのみで、プロダクトがプロダクションレディになるサービスの新規構築の自動化
    • yaml ファイルなどを書くだけで、環境が整うようにしている
  2. プロダクトチームが権限を持って運用できる基盤の提供
    • AWS の閲覧 / 編集権限を付与できる
  3. マイクロサービスカタログの整備
    • Backstage を使っている
  4. マイクロサービス環境における開発を支援する開発基盤の提供
    • 手元では、自分の利用するプロダクトのみ
    • リモートに関連マイクロサービスを利用する
  5. プロダクトチームがインフラのコスト最適化できるようにしたい
  6. プロダクトチームがパフォーマンス計測するためのメトリクスの可視化

Okey, but is that SRE?

ここのプロダクトチームが SRE を実践できるように支援しているため、組織全体の信頼の底上げに貢献している。
よって、信頼性にはコミットしている。

Q&A

  • Q. MF には xx SRE が何種類ありますか？
    • A. Platform SRE / Product SRE / Enabling SRE の 3種類がある
しげるしげる

50人以上のエンジニアが開発しているmonolithicのSREの話」

クラウド会計

  • マネフォで 2番目に古いサービス
  • 50名以上のエンジニアがいる
  • 4つの開発チームがある（SRE/デザインチームを含まない）
  • インフラ：オンプレ

プロダクト全体の状態

  • 開発メンバーが多いため技術レベルがバラバラ
  • アプリチームの多くが下のレイヤーのことを把握していないことが多い

Product SRE <> Platform SRE

  • Product SRE は会社の全体のインフラもある程度の理解が必要

SREチームの状態

  • 期待
    • Rails（そこそこ詳しい）
    • インフラ / ネットワーク等に詳しい
  • 実際
    • どちらもそこまで詳しくない

SREチームのスケール

  • SREチームの求めているハードルが高いので、採用は難しい。

そもそも Product SRE が全ての領域に詳しい必要はない

  • 技術選定の時にボトルネックになりたくない
  • 一番アプリに詳しいのは開発チーム

そのため

  • 開発チームが主体になってもらうのが理想
  • 障害発生の予防にも開発 / SREの両方が頑張る必要がある

理想までの道

視覚化や CI/CD導入だけでは足りない

  • 視覚化は担当の領域しか見なくなる
  • CICDだとデプロイしただけで満足してしまうことが多い

SLO 導入における課題

  • 重要な機能の要件を定義するときの課題
    • パフォーマンスよりエラーやバグのことに集中したい
  • 開発を止めること
    • 納得できるまでの相談が大変

改善の取り組み

  • 視覚化
    • 機能レベルの監視、APM
  • アクションできる
    • 実験できる環境の提供
    • 開発者が慣れたものと新しいインターフェイスを提供
    • 勉強会をする
  • モチベーションを作る
    • ビジネスの価値につながる
    • キャリアアップを感じる

more

  • 開発文化を古い文化から新しい文化にする必要がある
  • Goal
    • 障害発生が少なくなる方法
  • Non-goal
    • インフラツールの使い方

Q&A

  • Q. SLOの定義をしっかりすると、経営陣とも関わってきてしまって、リソース調整などもしないといけないと思うのですが、そこはどうやってクリアされましたか？
    • A. パフォーマンス & コストが可視化ができるようにして進めていった。
しげるしげる

「サービスと開発者に最も近いProduct SREsとして取り組んでいるコト」

していること

  • HR 領域の Product SRE

プロダクトチームが、SREプラクティスを実行できるまで支援するのがお仕事

プロダクトチームとコミュニケーションする上で、信頼階層を積み上げる
モニタリングが厳しいと言う話があるので、Datadog とかを活用している

SLO の活用

各プロダクトに合わせたSLOを実装する

  • ある程度運用されているシステム
    • 暫定 SLO があった
      • SLI の洗い出しをプロダクト側にお願いした
  • 新しいシステム
    • シンプルな SLO の定義から進めていく

運用負荷を上げないところからはじめていく

SRE 内の PJ 管理は、 github で管理している

SRE / プロダクトチームの違いは？

SREチームが入った方が良いことに入る
元々プロダクトチームが走れることは、フォローしない

チームによって異なるシステム課題解決

各チームのフェーズが異なりスキルセットも違う
直近の問題・将来の懸念点をロードマップにまとめようとしている
SRE に入って欲しいタスクは Help wanted label をつけてもらうようにしている

Q&A

  • Q. プロダクトSREやEnabling SREなど様々なSREの役割がマネーフォワードさんではあるようですが、お互いの領分が重なってしまったり協力してなにか課題を一緒に解決するようなことはあるのでしょうか？
    • A. 壁打ちをすることはあるが、タスクが被ることはない
  • Q. シンプルなSLOの導入にあたって、どういった観点で（優先度付けなど）を行っていますか？サービスの特徴によって変数などはあるのでしょうか
    • A. レイテンシやエラーの数などコアな部分から見ている
しげるしげる

サイトの信頼性の前にチームとしての信頼性を高めよう

https://twitter.com/yoshiken_tut/status/1562037351039516672?s=20&t=bnyrRIB9h_m6gVO-qXG-kg

対象

これから SRE チームを作る人（組織）作りたての SRE チーム

ワード

トイル？SLO？ポストモーテム？

SER / DevOps はゴールではなく手段。

  • ゴールは会社・事業・フェーズによって変わる

SREを理解し、共感し、納得してもらうことが大切。

立ち上げ時にしたこと

チーム検証を作成し、ゴールを共有した

- SREチームとは
- 役割
- 行動指針
- スコープ
- 今季優先事項

※偉い人たちと合意を取ってから周知をした方が良い

SREが他のチームに関与して、成功体験を得てもらう

費用可視化→削減
エラー検索向上→ELB + Athena基盤作成

SLO 単体に特に意味はない

  • 副次的な効果の方に意味がある
  • 疑問点にはしっかり答える
    • 愚直に回答と啓蒙活動をする

まとめ

他のチームに、SREを理解し、共感し、納得してもらうことが大切

しげるしげる

経済ニュースメディアのSREの役割と可観測性への取り組み

サービス

News Picks
プラットフォームでもあり、コミュニティでもある

大きな本体のプロダクトの中に SRE が1チームある

SREチームのミッションと活動の4つの軸

  1. ユーザー体験を守る
  2. 開発者体験を高める
  3. レガシーを捨てる
  4. セキュリティ・コストを適正化する

4つの軸を使って、ユーザー・事業・開発者の全てに価値を提供したい

やりたいことや要望に対して、できることは限られる

SRE / 開発者チーム = 1:5 の割合が良い

それぞれメトリクス化して優先順位付け

  1. ユーザー体験を守る
    • new relic
  2. 開発者体験を高める
    • new relic
    • findy teams
  3. レガシーを捨てる
    • AWS Healthダッシュボード
    • slack
  4. セキュリティ・コストを適正化する
    • yamory
    • AWS Cost Exploer& QuickSight

議論を深めていく

トリガー / 計画のタイミング / 優先判断基準 が変わってくる

まとめ

  • 優先度の判断について、会話を重ねてチーム内で納得感を醸成していくと良さそう

Q&A

  • Q. スプリントプランニングの例で優先度の並び換えをおこなうという話でしたがプロダクトオーナーやマネージャーとタフな交渉になったことはありますか？もしあればどう工夫されたかお聞きしてみたいです。
    • A. 四半期ごとの開発計画で、開発チームに対して、なにをやるかを決めて、コミットしている