SRELounge#7(2019/1/18 @メルカリ本社)
気づき、所感
- SRE は DevOps が浸透している環境が前提となっている気がする
- SRE のチーム形態としては、アプリケーション開発チームとは別になってた方が良さそう
- 運用チームという存在についてはそれほど否定的ではなく、横串で一元化したほうが良い部分ももちろんある。(特にセキュリティ周り)
- とはいえ権限分離は良いことではない。サイロ化は避けるべきであり、熟知はせずとも相互理解する姿勢が必要。権限移譲なども。
- 部門的なアレで DevOps できないならせめて SRE だけでも独立して DevOps すべき。(開発-運用の垣根を超えないといけない)
- チームとしてはいろんなスキルセットを持った人が集まった方が良さそう。
- Gunosy は 12 月から SRE 定義を始めてもう決まって登壇してる。スピード感と 1 点集中大事。(片手間良くない)
- SRE の定義の大切もだけど、周囲への共有と理解してもらうことも大事。
- トイルの可視化はしたい。TImeTracker？Redmine？
- やることも大事だけど、人が足りない今、やらないことを決めるのも同じくらい大事。
- 1on1 やりたい。SRE 策定と平行して上下の相互理解。
SRE の理解
- サービス形態や人の関わりかたによっても SRE 像は変わる
- でも、社内での認識の違いは埋めた方がいい
- 定義を共有する。公開する。
Gunosy の定義とか方針
- 「SRE はシステムにおける問題解決のプロフェッショナル集団である」
- 「自身がボトルネックにならない」
- 「 SRE しかできないことを減らす」
サイロ化
SRE はサービスごとにサイロ化(メルカリ)
チーム
メルカリ
担当範囲は信頼性に関わることはほぼ対応(メルカリ)
同じ SRE でも出身分野がみんな違う → 多様性のあるチームが良い
ストレングスファインダー → 他のメンバーのも見れるようにする。すごく便利(メルカリ)
Gunosy
1on1
supeee
事業の成長に責任をもつグループ
事業の信頼性に責任をもつグループ
サービスの成長曲線とフェーズごとの動き
初期
- サービス開始時は成功に集中する
- インフラ、キャパプラ、構成管理ツールの選定、
- インフラチューニングなど
成長期
非推奨、廃止の徹底
オンボーディング
用語の統一
ドキュメントの整備
→ バラバラ
ポストモーテム
開発が書いて SRE がレビュー
→ 障害管理台帳やめたい
トイル
- EM,PM 含めて関係者全員が理解する必要がある(50%ルール)
- SRE 自身がボトルネックにならないこと
-
SRE しかできないことを減らす
-
トイルの割合はツールで可視化する
- toggle が良さげ。簡単に計測できる
- Jira や Redmine でもタグ付けするなどして漏れなく管理
- エラーバジェットと同様に Toil limit を設ける。制限を厳守
Q. linit を越える時はどういう動きをする？
A. 緊急度が高いのはしゃあない
上に上げて人増やす、時間の調整
SLO
高すぎても低すぎてもいけない。
SLO を守るためリリースに 2 時間かかります →×
自分達に必要性を感じられる目標
SRE エンジニアの採用
SRE をやってきた人はまだ少ないし、
どこも重要ポジションに居る人が多いので抜けづらい。
転職エージェントは「SRE？なにそれ？」状態 → リファラル採用しよう！
メルカリ
https://speakerdeck.com/oguma/srede-teamkai-fa-tipstobesutopurakuteisutupoihe-ka
Gunosy
https://speakerdeck.com/aibou/sre-lounge-number-7-gunosyban-sremitusiyon-ce-ding