SRE未経験の私がEmbedded SRE 育成プロジェクトを通じてわかった本 当の組織課題 レバテック開発部　井上峻

|　© Leverages inc. 2 自己紹介 ● 所属: ○ Levtech SRE ● 出身: ○ 東京のど真ん中 ● 趣味: ○ 茶・キーボード・スパイス ● 好きな茶: ○ なんやかんや TWGのblack tea ● 好きなキーボード: ○ UHK, zoom75 ● 好きなキー軸: ○ 黄色軸 ● 好きなキースイッチ: ○ Akko V3 Cream Yellow Pro, WS morandi, KiiBOOM Matcha Latte ● 好きなスパイス: ○ グリーンカルダモン ● 好きな酒 ○ モンキー47 ● 好きなAWSのサービス: ○ Lambda ● 2023年の目標 ○ 筋トレして脳筋になる

アジェンダ ● Embedded SREの発足 ● 学び ● レバテック開発部の現状 ● まとめ

話さないこと ● SREの詳説 ● DevOpsの詳説 ● クラウドインフラの解説

Embedded SREの発足

そもそもSREってなんだっけ？

|　© Leverages inc. 7 ● 従来の運用業務を、ソフトウェアエンジニアを雇用する ことで成立させる(Google - Site Reliability Engineering) ● 高いレベルでサイトの信頼性を維持するために、 開発速度とサイトの安定性をバランスよく維持す るための技術(今さら聞けないSREとは？) ○ Reliability(以下により確信を持って頼りにされる能力 ) ■ 正確さ・誠実さ・実績 ○ 安定したシステム<運用> + 素早い実装・修正<開発>によってユーザーの信頼性を上げる ■ いつでも使える・良いUX・素早い不具合修正・セキュリティインシデントが少ない、また はあっても誠実に対応する ● 本番環境でのサービス運用 に責任を持つ ○ コードのデプロイ、設定、モニタリング、サービスの可用性、レイテンシー、変更管理、緊急対 応、キャパシティ管理など ● SREはDevOpsの実践形態で、開発と運用のギャップを埋めること に焦点を当てる(What is SRE) SREってなんだっけぇ？

上記踏まえて

|　© Leverages inc. 9 ● 運用・障害対応が各アプリケーションチーム内で解決できない状態 ○ 属人化、サイロ化が進んでおり、これらはわかる人だけがわかる職人芸になっていた ○ インフラ環境の整備や、メンテナンスに関してはほぼ SREチームのサポートが必要になっていた ● SREエンジニアが上記が原因で本来取り組みたい SRE業務ができない状態 ○ トイルの撲滅やオブザーバビリティ環境の整備は後回しになっており、目の前の運用課題の解決 や障害のサポートに駆り出されていた ● 個々のサービスのドメイン知識までは把握しきれないので事業レベルにまで踏み込みきれない状態 ● 複数のサービスを掛け持っているので、即応出来なかったり優先度付けで後回しになる状態 => よし、これらの解決のために Embedded SREとEvangelist SREのハイブリッドを目指そうぜ！ 既存のSREチームが抱えていた問題

|　© Leverages inc. 10 ● レバレジーズグループが目指すSRE組織と同様に、レバテックもハイブリット型のSRE組織を形成することに
 ○ レバレジーズの文化にもっとも適したSREの形を模索し、Embedded SREとEvangelist SREのハイブリッドを目指すこ とにした。(SREから始める、関係者全員の幸福)
 
 レバテック開発部が目指したSRE組織

|　© Leverages inc. 11 ● SRE engineers are embedded into cross-functional teams that own the the end-to-end lifecycle of a product, from build through decommission. ● This can take two shapes. First is a matrix SRE organization where engineers belong to a single capability and are also embedded full time within a product team (this is the Slalom Build SRE model). Alternatively, product teams may hire their own dedicated SRE engineers. ● The SRE engineer role is a hands on reliability/scalability Subject Matter Expert that helps the team adopt the engineering practices and tooling to ensure right-sized scalability and reliability throughout the lifecycle. ● The entire team participates in an on-call rotation.(The Many Shapes of Site Reliability Engineering) ● レバテックにおけるEmbedded SREとは(SREから始める、関係者全員の幸福 ) ○ ドメイン知識を持ち、事業を理解した人材 ○ Embedded SREは開発チーム内のアプリケーションエンジニアから選出する ○ 上記の知識を持ちながら、サービスのインフラ運営、監視、トイル撲滅、 SLOの策定など、SREの実務を行い DevOpsの実現をする ○ これらによって下記を実現 ■ ドメイン知識を持っているので、踏み込んだパフォーマンス改善が出来る ■ 自身のサービスだけ集中できるので、即応しやすい Embedded SREとは？

|　© Leverages inc. 12 ● レバテックにおけるEvangelist SREとは(SREから始める、関係者全員の幸福) ○ SREプラットフォームの構築 ○ SREのトレーニング ○ ノウハウやベストプラクティスを各チームから吸い上げて全社に浸透させる ○ 上記活動を通じて、下記リスクと問題を解決する ■ Embedded SREのみの体制だとで、チーム内に知識が閉じて局所最適に陥 る ■ アプリケーションエンジニアに任せるため、技術レベルがチーム毎に違い、技 術選定や運用体制に関して発生するリスクマネジメントができない Evangelist SREとは？

しかし...

|　© Leverages inc. 14 Embedded SREができる、アプ リケーションエンジニアがい ねぇ！

ほんなら育てよう💡

|　© Leverages inc. 16 ● ゴール ○ ※レバテックではクラウドとして主にAWSを使用している ○ レバテックで使われているツールでの基本インフラ構築ができる (Ansible, CDK, Terraform) ○ 障害対応の主担当ができる ○ パフォーマンス、アーキテクチャの最適化を立案、実行できる ● プロセス ○ 事前課題を行ってもらう ○ 1クォーター1ヶ月毎に時間を囲って教育の時間を確保 ○ 教育の時間では各チームの業務はやらない Embedded SRE育成プロジェクトの発足

|　© Leverages inc. 17 一方その頃のわたし インフラの混み入っ たことはわからんか らSREにお願いしよ SREって障害対応お助 けマンとインフラおじさん の集まりなのか、助かる わ〜 偉い人が頑張って考えてる間に、こんなこと思いながらマイクロサービス等の 開発・保守運用をしていた(誠に遺憾である)

|　© Leverages inc. 18 ある日

|　© Leverages inc. 19 しーも、しーも？ お前Embedded SREやれん べ？ チャラ男上司 わい あ、はい

|　© Leverages inc. 20 しーも、しーも？ お前Embedded SREやれん べ？ チャラ男上司 わい あ、はい あ、でも自信とかはあんまりな いかもしれません... じゃあ決まりね～！ おつかれいぃ〜

|　© Leverages inc. 21 こうしてEmbedded SREに任命され、事前課題として以下が課された ● AWSを使用して社内営業支援システムのインフラ再現 ● 読書課題: ○ Site Reliability Engineering ● 動画課題: ○ SREの概念、はじめ方 ○ SREの原則の 　 かくしてEmbedded SRE生活が始まった...

|　© Leverages inc. 22 ● 監視・オブザーバビリティ・ SLI/SLOについてのインプット /アウトプット ○ 入門監視 ○ オブザーバビリティエンジニアリング ○ SLO サービスレベル目標 ● Terraform・Ansibleについてインプット ○ 実践Terraform　AWSにおけるシステム設計とベストプラクティス ○ Ansible実践ガイド ● IaC化されていないクラウドリソースを IaC化 ○ インフラリソースはTerraformで管理 ○ コンフィグ周りはAnsibleで管理 ● アプリケーションチームに対して SREワークショップを開催 ● 各アプリケーションチームの SLI/SLO設定のサポート 実際にEmbedded SREの教育期間で行ったこと

学び

|　© Leverages inc. 24 学び ● SREエンジニアはインフラおじさんじゃない ● SREはそもそもアプリケーションエンジニアを楽にするための取り 組みでもある ● SREはDevOpsの実践 ● DevOpsとアジャイルの関係 ● レバテックのSREがやるべきこと

SREエンジニアはインフラおじさんじゃない

|　© Leverages inc. 26 レバテック開発部での光景 あー、インフラ起 因のエラーだ ヘルプ・ミー！SREメーーーン！ エンジニア

|　© Leverages inc. 27 レバテック開発部での光景 SREエンジニア どうしたん？ 話聞こうか？ なんかインフラ周りで落ちてる から調査頼むわ 重めのタスク エンジニア

|　© Leverages inc. 28 レバテック開発部での光景 SREエンジニア どうしたん？ 話聞こうか？ 調査頼むわ〜！ 重めのタスク エンジニアズ

|　© Leverages inc. 29 レバテック開発部での光景 SREエンジニア 重めのタスク 重めのタスク 調査頼む わ〜！

|　© Leverages inc. 30 ● SREエンジニアは信頼性を高める活動全てが業務範囲であり、 アプリケーションも信頼性を高める 上で必要であれ ば業務範囲になる ● 信頼性の維持の観点でインフラ領域において優先度が高い ため、インフラ作業が多いと考えている ● 上記により、元々インフラエンジニアだったエンジニアが業務領域を拡大して SREエンジニアになっているパターン が 多々有り、インフラ領域に詳しいため、インフラおじさん化しやすいと考える ● DevOpsを実践するのがSREであるため、Infrastructure as Codeを実現することが仕事に入ることで、単なるイン フラおじさん扱いされることが多い ● そもそもWebエンジニアにおいて一部しかわからないエンジニアになるということは、相当なプロフェッショナルスキル を求められるため、よほどフロントエンドやバックエンド、インフラ等に専門知識があるわけではないのであれば、全て の知識は網羅的に持っておいて当然である (自戒・早くfrontやれおれ &ここでは話を単純にするために、フロント、 バック、インフラと分けたが、当然アーキテクトや PM等別の切り口の分け方もある) => SREはインフラに詳しい人が多い確率は高いが、だからといってなんでもかんでもぶん投げれば良いものではない し、自分のようなアプリケーション出身のエンジニアのインフラ知識レベルはみんなとあんま変わらん SREエンジニアはインフラおじさんじゃない

|　© Leverages inc. 31 ● SREエンジニアは信頼性を高める活動全てが業務範囲であり、 アプリケーションも信頼性を高める 上で必要であれ ば業務範囲になる ● 信頼性の維持の観点でインフラ領域において優先度が高い ため、インフラ作業が多いと考えている ● 上記により、元々インフラエンジニアだったエンジニアが業務領域を拡大して SREエンジニアになっているパターン が 多々有り、インフラ領域に詳しいため、インフラおじさん化しやすいと考える ● DevOpsを実践するのがSREであるため、Infrastructure as Codeを実現することが仕事に入ることで、単なるイン フラおじさん扱いされることが多い ● そもそもWebエンジニアにおいて一部しかわからないエンジニアになるということは、相当なプロフェッショナルスキル を求められるため、よほどフロントエンドやバックエンド、インフラ等に専門知識があるわけではないのであれば、全て の知識は網羅的に持っておいて当然である (自戒・早くfrontやれおれ &ここでは話を単純にするために、フロント、 バック、インフラと分けたが、当然アーキテクトや PM等別の切り口の分け方もある) => SREはインフラに詳しい人が多い確率は高いが、だからといってなんでもかんでもぶん投げれば良いものではない し、自分のようなアプリケーション出身のエンジニアのインフラ知識レベルはみんなとあんま変わらん SREエンジニアはインフラおじさんじゃない Evangelist SREの方々、たくさんヘルプ投げててすみませんでした

SREはそもそもアプリケーションエンジニアを楽 にするための取り組みでもある

|　© Leverages inc. 33 ● そもそもSREはDevOpsの実践であるのであれば、アプリケーションエンジニ アの負荷も減って楽になる ● 弊社開発部では運用チームと開発チームが別れていないため、全エンジニア の開発体験向上や負荷軽減が見込める ● そうであれば、専任のSREsがDevOpsを推進するのではなく、全エンジニア一 丸となってSRE活動を理解し、実践するべきであると考える ● SREチームを単にエンジニアのヘルプデスクにするのは間違っている ● しかしながら、専任のSREsはDevOpsを実現する方法を教えていく義務はあ ると思うので、各エンジニアが考えるきっかけを作ることが大切だと考える SREはそもそもアプリケーションエンジニアを楽にする取り組みでもある

SREはDevOpsの実践

|　© Leverages inc. 35 ● お恥ずかしながら自分は DevOpsとSREの相関関係を知らなかった ● DevOpsは、迅速で高品質なサービス提供によりビジネス価値を高めるため のアプローチ ● SREはDevOpsの実践形態で、開発と運用のギャップを埋めること に焦点を当てる ● SREは、運用に精通したエンジニアを開発チームに配置し、コミュニケーションとワークフローの問 題を解消する ● DevOpsは開発プロセスの効率化 に、SREはサイト信頼性と新機能のバランス に焦点を当てる ● DevOpsのベストプラクティス ○ 継続的インデクラレーション ○ 継続的デリバリー ○ マイクロサービス ○ Infrastructure as Code ○ モニタリングとロギング ○ コミュニケーションと共同作業 SREはDevOpsの実践

DevOpsとアジャイルの関係

|　© Leverages inc. 37 ● DevOpsのベストプラクティスとしてマイクロサービスがあげられているように、 アプリケーションをより柔 軟にして革新を素早くする 特徴がある ○ アジャイルとの親和性が非常に高い ため、前提としてアジャイル開発を採用することはより DevOpsの実現に効果的である ● DevOpsは、迅速で高品質なサービス提供によりビジネス価値を高めるためのアプローチ等、 アジャイル と被る部分は多いが、違う部分もある ○ DevOpsはDev(開発)とOps(運用)の壁を取り払ってプロセスを効率的にすることに価値 おいて、 ツールを用いてCI/CDや自動化を合理化するが、 アジャイルはプロセスやツールよりも個人との対 話に価値を置く等違いもある ○ DevOpsはそもそも運用と開発の壁を取り除いて合理的に開発と運用のサイクルを回そう ねという ところがスタートなのに対し、アジャイルは 不確実性と変化に対応し、低価格で高品質の製品を開 発するためにというところがスタート DevOpsとアジャイルの関係

レバテックのSREがやるべきこと

|　© Leverages inc. 39 ● レバテックのSREがやるべきことは、DevOpsの概要とメリットを地道に伝えて行き、 SREを専任SREだけ でなく、アプリケーションエンジニアのメンバーにも実践してもらうように仕向けていく ことが大切だとわ かった ○ SREワークショップを各チームに対して実施することで、かつての自分と同様、そもそも DevOpsと SREについて全く知らないエンジニアが多かった ○ しかしながら、DevOpsとSREについて説明すると、割と好反応であり、 SLI/SLOの設定もして自分 達の業務の効率化を図りたいという意志が見えた ○ オブザーバビリティや SREについて発表したが、ちゃんと覚えていなかったし、まとめた資料をちゃ んと読み返した人も少なかったため、ワークショップにすることで初めて理解したメンバーも多かっ た ○ 理屈はわかってもどうすればいいか分からなかったが、卑近なシステムに置き換えて考えること で、イメージが湧いたという声があった レバテックのSREがやるべきこと

こういった活動を通してレバテック開発部の現 状はどう変化したか？

レバテック開発部の現状

|　© Leverages inc. 42 レバテック開発部の現状 我々ってDevOpsに向かって 行ってたんだ！ 何目指してたのかわからな かった〜！

|　© Leverages inc. 43 レバテック開発部の現状 我々ってDevOpsに向かって 行ってたんだ！ 何目指してたのかわからな かった〜！ SREに対して理解が深まった分、目指したい方向性をみんながなんとなく理解した

|　© Leverages inc. 44 レバテック開発部の現状 ログ構造化しといたで〜！ 神

|　© Leverages inc. 45 レバテック開発部の現状 ログ構造化しといたで〜！ 神 一部のチームではSRE活動につながることを自発的に行うようになった

一方で...

|　© Leverages inc. 47 レバテック開発部の現状 運用対応に追われて設定する暇 がないよ〜 よっしゃぁSLI/SLO設定して、運 用作業を最適化するぞ！ 次の日 SREワークショップ直後

|　© Leverages inc. 48 レバテック開発部の現状 運用対応に追われて設定する暇 がないよ〜 よっしゃぁSLI/SLO設定して、運 用作業を最適化するぞ！ 次の日 SREワークショップ直後 やったほうが良いことはわかっているが、現実問題時間が作れない

|　© Leverages inc. 49 レバテック開発部の現状 教育プロジェクトにより増えたSREs あれなんか増えてんじゃーん

|　© Leverages inc. 50 レバテック開発部の現状 SREエンジニア 重めのタスク 調査頼む わ〜！

|　© Leverages inc. 51 レバテック開発部の現状 SREエンジニア 重めのタスク 調査頼む わ〜！ 未だにインフラおじさん扱いのムーブが目立つ

|　© Leverages inc. 52 レバテック開発部の現状 DevOpsとアジャイ ルって親和性あるけ ど、アジャイル文化 根付いてないよな？ あれDevOpsの方法 でマイクロサービス があったけど、モノリ スを切り出すスキル ある人少ないよな？ 技術的負債をまず解 消しないと何も動け なくないか？ 事業部からの依頼が 逼迫しててDevOps に向かうタスクの優 先度があげられない よな？ まず理解してもらわ ないとだよな？

|　© Leverages inc. 53 レバテック開発部の現状 DevOpsとアジャイ ルって親和性あるけ ど、アジャイル文化 根付いてないよな？ あれDevOpsの方法 でマイクロサービス があったけど、モノリ スを切り出すスキル ある人少ないよな？ 技術的負債をまず解 消しないと何も動け なくないか？ 事業部からの依頼が 逼迫しててDevOps に向かうタスクの優 先度があげられない よな？ まず理解してもらわ ないとだよな？ そもそもDevOpsを実践するための前提が整っていない

まとめ

|　© Leverages inc. 55 ● Embedded SRE育成プロジェクトを通じてレバテック開発部内にSREの役割や DevOpsの意義が広く知れ渡ったが、実践にはその地盤が整っていない ○ 今まで上がっていた組織課題はDevOps実現が前提の課題や、一歩進んだところ が多かった印象(主観) 課題

|　© Leverages inc. 56 課題 DevOps SRE デベロッパー 運用問題 事業部理解 アジャイルマインド醸成 スキル不足 DevOpsを阻む壁 技術負債

|　© Leverages inc. 57 課題 DevOps SRE デベロッパー 運用問題 事業部理解 アジャイルマインド醸成 スキル不足 DevOpsを阻む壁 技術負債 まずここにアプ ローチする

|　© Leverages inc. 58 ● 運用問題 ○ オブザーバビリティツールの活用や自動化によって負担を軽減したい ● アジャイルマインド醸成 ○ 自律型組織にして、DevOpsサイクルをよりよく回すために、まず第一に アジャイルマインドを醸成に力を入れたい ○ アジャイル専門チームとコラボしてイネイブリングしていきたい(誰か良い アジャイルコーチおらんかな...w) ● スキル不足 ○ インフラ実装についてはイネイブリングしていって、責務をアプリケーショ ンエンジニア側に寄せたい これから改善していくこと

終わり