DevOps実現のための私たちのSREのあり方

2024/09/06Commune × 弁護士ドットコム × Leverages
『SREの組織と文化』　〜レバレジーズ・コミューン・弁護士ドットコムが語る！取り組みと挑戦〜
----------------------------
組織のDevOpsの浸透具合や当時のSREチームが抱える悩み等を鑑みて、
独立していたチームを解体するに至った意思決定の中身、その結果何が起きたか？を話しました。

Transcript

1. DevOps実現のための 
 私たちのSREのあり方 
 〜独立したチームから開発に寄り添う立場へ〜
 
 レバレジーズ株式会社
 下畑 剣一郎

2. 名前
 下畑 剣一郎（しもはた けんいちろう）
 経歴
 2016年〜 SIerを2社
 2022年〜 レバレジーズ株式会社にJoin
 今の仕事
 EM / SRE LD
 最近の 激アツ Topic 
 11月にフルマラソン初めて出ます🏃 
 事業部内外で声かけてみて未経験者が9人あつまった（正気か？）
 フッ軽人材おおい職場で楽しい
 自己紹介

3. こんなサービスつくってます 
 NALYSYS（ナリシス） 
 HRTech系SaaS
 目的はEmployee Experience の改善
 人材の枯渇や流動性の高まり等の社会課題を受けて
 人と企業の出会い に可能な限り意味を持たせる 
 サービスバリュー 
 • 社員の行動エンジンを探るお手伝い
 • 社員に楽しく働いてもらうための打ち手の改善のお手伝い
 →効率的かつ効果的なEXリサーチ/改善のサポート 

4. 話すこと
 副題
 「〜独立したチームから開発に寄り添う立場へ〜」 
 元々SREチームが独立して存在していたが
 • DevOpsの浸透具合
 • SREチームが抱える悩み
 • 開発チームが抱える悩み
 を鑑みて
 チームを解体するに至った意思決定の中身、その結果何が起きたか？

5. リリースデプロイに関して 
 CI/CDは各サービス出来ている（GitHub Actions/Cloud Build）
 インフラ作業に関して 
 Terraformを利用した構成管理
 開発者からの要望を受けてSREが対応
 運用に関して 
 Slackチャンネルにログ/メトリクスのアラートを通知
 アラートが発生した時に開発チーム/SREチームが中身を解析
 対応が必要であれば対応
 当時の組織内のDevOps浸透状況 

6. インフラ作業の悩み 
 簡易で細々とした作業が多く、自分たちがやる意味が薄れていた
 監視の悩み 
 オオカミアラートが多かった
 「顧客が困っているときにだけアラートが鳴る」状態を求めて
 SLOアラート設定を検討し始めていた
 メンバーの悩み 
 事業貢献感の乏しさ→意味づけしたけど限界はある 
 開発者の悩みのキャッチアップのしにくさ
 開発の悩みを自分ごとにしにくく評論家になりがち
 →これってSREあるあるですかね？ 
 当時のSREチームの悩み 

7. 当時？の開発チームの悩み 
 HRTech系は競合も強く・・・
 採用ムズカしいけど、たくさん機能開発したい！ 

8. 課題並べてみた 
 • SREでも事業貢献したい
 • 開発者と密に悩みを共有しあいたい
 • 開発者増やしたい
 • 評論家にならず、自分ごととして動く
 • 構成変更の民主化
 • 早くSLOアラートを全サービスに展開したい

9. 見えてきた打ち手 
 • SREでも事業貢献したい
 • 開発者と密に悩みを共有しあいたい
 • 開発者増やしたい
 • 評論家にならず、自分ごととして動く 
 →俺たちも開発する？ 
 • 構成変更の民主化
 →開発者の隣でTerraform教えてあげる？ 
 • 早くSLOアラートを全サービスに展開したい
 →SLO一緒に考える？ 
 SREが開発と密に関わるために 
 SREチームから開発チームのメンバーに 

10. チームをぶっこわすと決めてからの動き 
 • マネージャーや各チームへの根回し
 • SLI設定のための計装
 • SLOの啓蒙や設定方法のドキュメント用意
 • SRE担当者が持つべき意識や期待する動きの設定
 （Working Agreement）

11. 具体をちょっとだけ紹介 
 実際のWorking Agreement から抜粋

12. 開発者と一緒に事業を考えるSREに 
 狙い通りだったこと 
 • SLOに関しての知識を持つSREがCUJ検討から入り込み、
 スムーズにSLOアラートを全サービス展開
 • 簡単な構成変更は開発者がPRを上げてSREはレビューするだけ
 • 開発リソース増
 副次的な効果 
 • 機能設計にSRE担当者が入ることによる手戻り減
 • クラウドサービスの知見を活かした有効活用
 • 各SREの担当するサービスの明確化
 • 基本兼業になるためSRE担当者を増やしやすい

13. 1年くらい運用してみて 
 悩みもある 
 SRE担当者のリソース確保の調整難易度増 
 元々リスクとして承知はしていたが、
 将来的に対応が必要で工数の大きいタスクは
 スタックされていっている状況
 →今後も状況に合わせた打ち手を考え続ける 

14. • SLO運用のような明確に事業に影響のある施策以外、
 SREが事業貢献感を得ることが難しい
 ◦ 事業会社で働くSREは事業目線をもっていることも多い
 ◦ 意味づけでケアすることに限界を覚えたら
 開発チームに配置させることも悪い選択肢ではない
 
 • SREは開発チームを顧客と見做す側面もある
 ◦ 開発の現場を知ることで見えてくる課題は大いにある
 
 • 今どういう状況なのか？を多角的にみて判断し、
 誰がどのように関わるかを整理すると効果的な施策が打てる
 ◦ どの面をピックアップするかの一例として参考にしていただけたら
 まとめ・所感