SRE Lounge 主催者が見てきた 各社のSRE的取り組み 第6回名古屋若手Webエンジニア交流会 @katsuhisa__ / Katsuhisa Kitano #wakateweb_nagoya

● 北野 勝久 / @katsuhisa__ ● SRE @ Studist Corporation ● Organizer of SRE Lounge / Rails Developers Meetup ● Developers Summit, / July Tech Festa 登壇 etc. ● Linux カーネルと同い年

マニュアル作成・共有プラットフォーム

No content

今日話すこと ● SRE Lounge とは ● SRE Lounge 過去発表の中から、 各社の優れたSRE的取り組みをいくつかご紹介 ○ また、それらの取り組みを スタディスト SREチームにどのようにマージしたか

SRE Lounge とは

SRE Lounge 目的 ● SRE Book の内容は、Google のDevOps であり、 他社による様々なかたちがあるはず ○ 『Seeking SRE』の出版からも分かる通り ● →各社の意見交換の場をつくる

SRE Lounge 歴史 ● UZABASE のSRE チームのメンバーが 発足させた勉強会（2018/1） ○ 先日、生誕一周年をむかえた ● クローズドで 小規模な勉強会運営をしていたが より 多くのSRE と交流を図るためオープンな勉強会に ○ このタイミングで、私は運営側に参加

SRE Lounge 参加者数推移 オープン化

SRE Lounge 特徴 ● 1回の勉強会で、 複数社のプラクティスを知ることができる ● 双方向なやり取りができる勉強会 ○ 質疑応答が必ずある ● 飲み物は開会時点で用意しておき カジュアルな雰囲気で ● 運営の主体は、特定企業ではなく コミュニティ

SRE Lounge #7 の風景

過去のSRE Lounge 登壇企業の 取り組みを一部ご紹介 + スタディストSREチームにどのようにマージしてきたか

No content

弱者のSRE戦略 ● 小さなチームでのSRE実践に焦点をあてた発表 ○ Googleと同じ闘いはできないので自分たちで考える ● SRE的取り組みを 各個撃破 , 情報戦 , 接近戦 に分類 ○ 各個撃破 ■ 技術課題に対して、優先順位をつけて対応 ○ 情報戦 ■ 外部の情報と内部の情報を収集する ● 外部：パブリッククラウドやOSS ● 内部：プロダクトの方向性や、課題解決の優先度 ○ 接近戦 ■ 決定権を持つ人に信頼してもらう

スタディストSREでのマージ ● 各個撃破 ○ > 技術課題に対して、優先順位をつけて対応 ○ SRE タスクをバックログ管理し、優先順位の見極め ● 情報戦 ○ > 外部の情報と内部の情報を収集する ○ 週次打合せで、全社方針のアップデートや、技術情報を共有 ● 接近戦 ○ > 決定権を持つ人に信頼してもらう ○ スタディストSREにとって周囲に信頼されることがいかに大事かを ドキュメントで共有している

No content

BacklogにおけるSREの事例 ● SREの業務範囲と組織構造の変遷に焦点をあてた発表 ○ 組織が大きくなると、 全員が開発と運用の兼務は難しい ○ SREの業務範囲は際限なく広がる ● SREをマトリックス的に配置する ○ MTTRを改善 ○ 運用ミス減少 ○ ただし、スピードの観点で課題も

スタディストSREでのマージ ● 組織構造 ○ > SREをマトリックス的に配置する ○ 特定の開発Prj. に対してSREをアサイン ■ ただし、継続的な機能開発をするスクラムチームに SREをアサインする取り組みは現状やっていない ● その代わり、開発者が 開発に必要なインフラ環境を 自分たちで構築できるよう権限付与 ○ そのためのシステム境界整備をSREが実施 ○ 今後、Terraform template を整備予定 ● SREチーム自体が一つのスクラムチームのため ○ SREも運用で使うツールやシステム開発を行っている

No content

freeeにおけるSRE的取り組み ● サービス規模拡大、組織規模拡大に どう対処してきたかをまとめた発表 ○ 自動化、共通基盤化の推進 ■ AWSのマネージドサービスや、SaaSを積極活用 ■ 定期的な見直しで正しくチューニング ○ 知識共有の見直し、権限整理、開発手法見直し ■ SREオンボーディング ■ SREヒーロー / SRE留学というSREチームへの短期受け入れ ■ 障害振り返り会 ■ アラート対応の一部移管 ■ テスト自動化

スタディストSREでのマージ ● 知識共有の見直し、権限整理、開発手法見直し ○ > SREオンボーディング ○ 我々も実施 ■ SRE本の輪読や、AWS上に同じ構成を再現する研修など ○ > SREヒーロー / SRE留学というSREチームへの短期受け入れ ○ 今後やってみたい ■ SREチームの取り組みを開発チームに紹介することからはじめる ○ > 障害振り返り会 ○ 我々も実施しているが、SREチーム内に閉じているので、 freeeさんのように開発チーム全体を巻き込んだ形を模索したい

No content

SRE的チーム開発Tipsとベストプラクティスっぽい何か ● SREとして活動する中で得たチーム開発Tipsや ベストプラクティスの紹介 ● SREのスキルマップを描き、 チームとしてカバー領域が多様になる状態を目指す ● ToilがSRE機能を損なうことを関係者で理解する ○ Toil Limitを設け、厳守する ■ Togglを使い、自己管理に活用 ● 組織フェーズに応じて、SREの焦点する領域を変化

スタディストSREでのマージ ● > SREのスキルマップを描き、 > チームとしてカバー領域が多様になる状態を目指す ● 我々もスキルマップを作成 ○ 現状の用途は異なっており、 チームの重点領域をチーム内で合意するために利用 ■ Onboardingでの重点領域を定めている ○ 各人の得意スキルをお互いに書く取り組みは 真似したい

スタディストSREでのマージ ● ToilがSRE機能を損なうことを関係者で理解する ○ > Toil Limitを設け、厳守する ○ 現在、カンバンでSREチームのタスク管理をしており、 カンバン内にOpsを格納するレーンを設けている ■ すべてのタスクに対応コストのポイントを付与 ■ Opsに要したポイント / 全体の進捗ポイントで、 Toil limit を計測 ● > 組織フェーズに応じて、SREの焦点する領域を変化 ● チームで変化する方向性について合意するため、 SREチームの今後について話す時間を設けている

まとめ

The tale is not for copying —though perhaps for emulating— but it can inspire the next step for all of us. by 『Site Reliability Engineering』 - Foreword https://landing.google.com/sre/sre-book/chapters/foreword/

SRE Lounge あそびにきてね （名古屋や関西でもやりたい！）

引用スライド 弱者のSRE戦略 / SRE strategy for small team https://speakerdeck.com/rmanzoku/sre-strategy-for-small-team BacklogにおけるSREの事例 / SRE Lounge #5 https://speakerdeck.com/nulabinc/sre-lounge-number-5 freeeにおけるSRE的取り組み https://speakerdeck.com/atk/freeeniokerusrede-qu-rizu-mi SRE的team開発Tipsとベストプラクティスっぽい何か https://speakerdeck.com/oguma/srede-teamkai-fa-tipstobesutopurakuteisutupoihe-ka

● 北野 勝久 / @katsuhisa__ ● SRE @ Studist Corporation ● Organizer of SRE Lounge / Rails Developers Meetup ● Developers Summit, / July Tech Festa 登壇 etc. ● Linux カーネルと同い年