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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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