SRE未経験の私がEmbedded SRE育成プロジェクトを通じてわかった本当の組織課題

Transcript

1. SRE未経験の私がEmbedded SRE 育成プロジェクトを通じてわかった本 当の組織課題 レバテック開発部　井上峻
2. |　© Leverages inc. 2 自己紹介 • 所属: ◦ Levtech SRE • 出身: ◦ 東京のど真ん中 • 趣味: ◦ 茶・キーボード・スパイス • 好きな茶: ◦ なんやかんや TWGのblack tea • 好きなキーボード: ◦ UHK, zoom75 • 好きなキー軸: ◦ 黄色軸 • 好きなキースイッチ: ◦ Akko V3 Cream Yellow Pro, WS morandi, KiiBOOM Matcha Latte • 好きなスパイス: ◦ グリーンカルダモン • 好きな酒 ◦ モンキー47 • 好きなAWSのサービス: ◦ Lambda • 2023年の目標 ◦ 筋トレして脳筋になる
3. アジェンダ • Embedded SREの発足 • 学び • レバテック開発部の現状 • まとめ
4. 話さないこと • SREの詳説 • DevOpsの詳説 • クラウドインフラの解説
5. Embedded SREの発足
6. そもそもSREってなんだっけ？
7. |　© Leverages inc. 7 • 従来の運用業務を、ソフトウェアエンジニアを雇用することで成立させる(Google - Site Reliability Engineering) • 高いレベルでサイトの信頼性を維持するために、開発速度とサイトの安定性をバランスよく維持するための技術(今 さら聞けないSREとは？) ◦ Reliability(以下により確信を持って頼りにされる能力) ▪ 正確さ・誠実さ・実績 ◦ 安定したシステム<運用> + 素早い実装・修正<開発>によってユーザーの信頼性を上げる ▪ いつでも使える・良いUX・素早い不具合修正・セキュリティインシデントが少ない、またはあっても誠実 に対応する • 本番環境でのサービス運用に責任を持つ ◦ コードのデプロイ、設定、モニタリング、サービスの可用性、レイテンシー、変更管理、緊急対応、キャパシティ管 理など • SREはDevOpsの実践形態で、開発と運用のギャップを埋めることに焦点を当てる(What is SRE) SREってなんだっけぇ？
8. 上記踏まえて
9. |　© Leverages inc. 9 • 運用・障害対応が各アプリケーションチーム内で解決できない状態 ◦ 属人化、サイロ化が進んでおり、これらはわかる人だけがわかる職人芸になっていた ◦ インフラ環境の整備や、メンテナンスに関してはほぼSREチームのサポートが必要になっていた • SREエンジニアが上記が原因で本来取り組みたいSRE業務ができない状態 ◦ トイルの撲滅やオブザーバビリティ環境の整備は後回しになっており、目の前の運用課題の解決 や障害のサポートに駆り出されていた • 個々のサービスのドメイン知識までは把握しきれないので事業レベルにまで踏み込みきれない状態 • 複数のサービスを掛け持っているので、即応出来なかったり優先度付けで後回しになる状態 => よし、これらの解決のためにEmbedded SREとEvangelist SREのハイブリッドを目指そうぜ！ 既存のSREチームが抱えていた問題
10. |　© Leverages inc. 10 • レバレジーズグループが目指すSRE組織と同様に、レバテックもハイブリット型のSRE組織を形成することに ◦ レバレジーズの文化にもっとも適したSREの形を模索し、Embedded SREとEvangelist SREのハイブリッ ドを目指すことにした。(SREから始める、関係者全員の幸福) レバテック開発部が目指したSRE組織
11. |　© 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とは？
12. |　© Leverages inc. 12 • レバテックにおけるEvangelist SREとは(SREから始める、関係者全員の幸福) ◦ SREプラットフォームの構築 ◦ SREのトレーニング ◦ ノウハウやベストプラクティスを各チームから吸い上げて全社に浸透させる ◦ 上記活動を通じて、下記リスクと問題を解決する ▪ Embedded SREのみの体制だとで、チーム内に知識が閉じて局所最適に陥る ▪ アプリケーションエンジニアに任せるため、技術レベルがチーム毎に違い、技術選 定や運用体制に関して発生するリスクマネジメントができない Evangelist SREとは？
13. しかし...
14. |　© Leverages inc. 14 Embedded SREができる、 アプリケーションエンジニアが いねぇ！
15. ほんなら育てよう💡
16. |　© Leverages inc. 16 • ゴール ◦ ※レバテックではクラウドとして主にAWSを使用している ◦ レバテックで使われているツールでの基本インフラ構築ができる (Ansible, CDK, Terraform) ◦ 障害対応の主担当ができる ◦ パフォーマンス、アーキテクチャの最適化を立案、実行できる • プロセス ◦ 事前課題を行ってもらう ◦ 1クォーター1ヶ月毎に時間を囲って教育の時間を確保 ◦ 教育の時間では各チームの業務はやらない Embedded SRE育成プロジェクトの発足
17. |　© Leverages inc. 17 一方その頃のわたし インフラの混み入っ たことはわからんか らSREにお願いし よ SREって障害対応お助 けマンとインフラおじさ んの集まりなのか、助か るわ〜 偉い人が頑張って考えてる間に、こんなこと思いながらマイクロサービス等 の開発・保守運用をしていた(誠に遺憾である)
18. |　© Leverages inc. 18 ある日
19. |　© Leverages inc. 19 しーも、しーも？ お前Embedded SREやれん べ？ チャラ男上司 わい あ、はい
20. |　© Leverages inc. 20 しーも、しーも？ お前Embedded SREやれん べ？ チャラ男上司 わい あ、はい あ、でも自信とかはあんまりな いかもしれません... じゃあ決まりね～！ おつかれいぃ〜
21. |　© Leverages inc. 21 こうしてEmbedded SREに任命され、事前課題として以下が課された • AWSを使用して社内営業支援システムのインフラ再現 • 読書課題: ◦ Site Reliability Engineering • 動画課題: ◦ SREの概念、はじめ方 ◦ SREの原則の 　 かくしてEmbedded SRE生活が始まった...
22. |　© Leverages inc. 22 • 監視・オブザーバビリティ・SLI/SLOについてのインプット/アウトプット ◦ 入門監視 ◦ オブザーバビリティエンジニアリング ◦ SLO サービスレベル目標 • Terraform・Ansibleについてインプット ◦ 実践Terraform　AWSにおけるシステム設計とベストプラクティス ◦ Ansible実践ガイド • IaC化されていないクラウドリソースをIaC化 ◦ インフラリソースはTerraformで管理 ◦ コンフィグ周りはAnsibleで管理 • アプリケーションチームに対してSREワークショップを開催 • 各アプリケーションチームのSLI/SLO設定のサポート 実際にEmbedded SREの教育期間で行ったこと
23. 学び
24. |　© Leverages inc. 24 学び • SREエンジニアはインフラおじさんじゃない • SREはそもそもアプリケーションエンジニアを楽にするための取 り組みでもある • SREはDevOpsの実践 • DevOpsとアジャイルの関係 • レバテックのSREがやるべきこと
25. SREエンジニアはインフラおじさんじゃない
26. |　© Leverages inc. 26 レバテック開発部での光景 あー、インフラ起 因のエラーだ ヘルプ・ミー！SREメーーーン！ エンジニア
27. |　© Leverages inc. 27 レバテック開発部での光景 SREエンジニア どうしたん？ 話聞こうか？ なんかインフラ周りで落ちてる から調査頼むわ 重めのタスク エンジニア
28. |　© Leverages inc. 28 レバテック開発部での光景 SREエンジニア どうしたん？ 話聞こうか？ 調査頼むわ〜！ 重めのタスク エンジニアズ
29. |　© Leverages inc. 29 レバテック開発部での光景 SREエンジニア 重めのタスク 重めのタスク 調査頼む わ〜！
30. |　© Leverages inc. 30 • SREエンジニアは信頼性を高める活動全てが業務範囲であり、アプリケーションも信頼性を高める上で必要であれば業 務範囲になる • 信頼性の維持の観点でインフラ領域において優先度が高いため、インフラ作業が多いと考えている • 上記により、元々インフラエンジニアだったエンジニアが業務領域を拡大してSREエンジニアになっているパターンが 多々有り、インフラ領域に詳しいため、インフラおじさん化しやすいと考える • DevOpsを実践するのがSREであるため、Infrastructure as Codeを実現することが仕事に入ることで、単なるイ ンフラおじさん扱いされることが多い • そもそもWebエンジニアにおいて一部しかわからないエンジニアになるということは、相当なプロフェッショナルスキル を求められるため、よほどフロントエンドやバックエンド、インフラ等に専門知識があるわけではないのであれば、全ての 知識は網羅的に持っておいて当然である(自戒・早くfrontやれおれ &ここでは話を単純にするために、フロント、バッ ク、インフラと分けたが、当然アーキテクトやPM等別の切り口の分け方もある) => SREはインフラに詳しい人が多い確率は高いが、だからといってなんでもかんでもぶん投げれば良いものではないし、 自分のようなアプリケーション出身のエンジニアのインフラ知識レベルはみんなとあんま変わらん SREエンジニアはインフラおじさんじゃない
31. |　© Leverages inc. 31 • SREエンジニアは信頼性を高める活動全てが業務範囲であり、アプリケーションも信頼性を高める上で必要であれば業 務範囲になる • 信頼性の維持の観点でインフラ領域において優先度が高いため、インフラ作業が多いと考えている • 上記により、元々インフラエンジニアだったエンジニアが業務領域を拡大してSREエンジニアになっているパターンが 多々有り、インフラ領域に詳しいため、インフラおじさん化しやすいと考える • DevOpsを実践するのがSREであるため、Infrastructure as Codeを実現することが仕事に入ることで、単なるイ ンフラおじさん扱いされることが多い • そもそもWebエンジニアにおいて一部しかわからないエンジニアになるということは、相当なプロフェッショナルスキル を求められるため、よほどフロントエンドやバックエンド、インフラ等に専門知識があるわけではないのであれば、全ての 知識は網羅的に持っておいて当然である(自戒・早くfrontやれおれ &ここでは話を単純にするために、フロント、バッ ク、インフラと分けたが、当然アーキテクトやPM等別の切り口の分け方もある) => SREはインフラに詳しい人が多い確率は高いが、だからといってなんでもかんでもぶん投げれば良いものではないし、 自分のようなアプリケーション出身のエンジニアのインフラ知識レベルはみんなとあんま変わらん SREエンジニアはインフラおじさんじゃない Evangelist SREの方々、たくさんヘルプ投げててすみませんでした
32. SREはそもそもアプリケーションエンジニアを楽 にするための取り組みでもある
33. |　© Leverages inc. 33 • そもそもSREはDevOpsの実践であるのであれば、アプリケーションエンジニア の負荷も減って楽になる • 弊社開発部では運用チームと開発チームが別れていないため、全エンジニアの開 発体験向上や負荷軽減が見込める • そうであれば、専任のSREsがDevOpsを推進するのではなく、全エンジニア一 丸となってSRE活動を理解し、実践するべきであると考える • SREチームを単にエンジニアのヘルプデスクにするのは間違っている • しかしながら、専任のSREsはDevOpsを実現する方法を教えていく義務はある と思うので、各エンジニアが考えるきっかけを作ることが大切だと考える SREはそもそもアプリケーションエンジニアを楽にする取り組みでもある
34. SREはDevOpsの実践
35. |　© Leverages inc. 35 • お恥ずかしながら自分はDevOpsとSREの相関関係を知らなかった • DevOpsは、迅速で高品質なサービス提供によりビジネス価値を高めるためのアプローチ • SREはDevOpsの実践形態で、開発と運用のギャップを埋めることに焦点を当てる • SREは、運用に精通したエンジニアを開発チームに配置し、コミュニケーションとワークフローの問題を解消 する • DevOpsは開発プロセスの効率化に、SREはサイト信頼性と新機能のバランスに焦点を当てる • DevOpsのベストプラクティス ◦ 継続的インデクラレーション ◦ 継続的デリバリー ◦ マイクロサービス ◦ Infrastructure as Code ◦ モニタリングとロギング ◦ コミュニケーションと共同作業 SREはDevOpsの実践
36. DevOpsとアジャイルの関係
37. |　© Leverages inc. 37 • DevOpsのベストプラクティスとしてマイクロサービスがあげられているように、アプリケーションをよ り柔軟にして革新を素早くする特徴がある ◦ アジャイルとの親和性が非常に高いため、前提としてアジャイル開発を採用することはより DevOpsの実現に効果的である • DevOpsは、迅速で高品質なサービス提供によりビジネス価値を高めるためのアプローチ等、アジャイ ルと被る部分は多いが、違う部分もある ◦ DevOpsはDev(開発)とOps(運用)の壁を取り払ってプロセスを効率的にすることに価値お いて、ツールを用いてCI/CDや自動化を合理化するが、アジャイルはプロセスやツールよりも個 人との対話に価値を置く等違いもある ◦ DevOpsはそもそも運用と開発の壁を取り除いて合理的に開発と運用のサイクルを回そうねと いうところがスタートなのに対し、アジャイルは不確実性と変化に対応し、低価格で高品質の製品 を開発するためにというところがスタート DevOpsとアジャイルの関係
38. レバテックのSREがやるべきこと
39. |　© Leverages inc. 39 • レバテックのSREがやるべきことは、DevOpsの概要とメリットを地道に伝えて行き、SREを専任 SREだけでなく、アプリケーションエンジニアのメンバーにも実践してもらうように仕向けていくこと が大切だとわかった ◦ SREワークショップを各チームに対して実施することで、かつての自分と同様、そもそも DevOpsとSREについて全く知らないエンジニアが多かった ◦ しかしながら、DevOpsとSREについて説明すると、割と好反応であり、SLI/SLOの設定もして 自分達の業務の効率化を図りたいという意志が見えた ◦ オブザーバビリティやSREについて発表したが、ちゃんと覚えていなかったし、まとめた資料を ちゃんと読み返した人も少なかったため、ワークショップにすることで初めて理解したメンバーも 多かった ◦ 理屈はわかってもどうすればいいか分からなかったが、卑近なシステムに置き換えて考えること で、イメージが湧いたという声があった レバテックのSREがやるべきこと
40. こういった活動を通してレバテック開発部の現 状はどう変化したか？
41. レバテック開発部の現状
42. |　© Leverages inc. 42 レバテック開発部の現状 我々ってDevOpsに向かって 行ってたんだ！ 何目指してたのかわからな かった〜！
43. |　© Leverages inc. 43 レバテック開発部の現状 我々ってDevOpsに向かって 行ってたんだ！ 何目指してたのかわからな かった〜！ SREに対して理解が深まった分、目指したい方向性をみんながなんとなく理解した
44. |　© Leverages inc. 44 レバテック開発部の現状 ログ構造化しといたで〜！ 神
45. |　© Leverages inc. 45 レバテック開発部の現状 ログ構造化しといたで〜！ 神 一部のチームではSRE活動につながることを自発的に行うようになった
46. 一方で...
47. |　© Leverages inc. 47 レバテック開発部の現状 運用対応に追われて設定する暇 がないよ〜 よっしゃぁSLI/SLO設定して、運 用作業を最適化するぞ！ 次の日 SREワークショップ直後
48. |　© Leverages inc. 48 レバテック開発部の現状 運用対応に追われて設定する暇 がないよ〜 よっしゃぁSLI/SLO設定して、運 用作業を最適化するぞ！ 次の日 SREワークショップ直後 やったほうが良いことはわかっているが、現実問題時間が作れない
49. |　© Leverages inc. 49 レバテック開発部の現状 教育プロジェクトにより増えたSREs あれなんか増えてんじゃーん
50. |　© Leverages inc. 50 レバテック開発部の現状 SREエンジニア 重めのタスク 調査頼む わ〜！
51. |　© Leverages inc. 51 レバテック開発部の現状 SREエンジニア 重めのタスク 調査頼む わ〜！ 未だにインフラおじさん扱いのムーブが目立つ
52. |　© Leverages inc. 52 レバテック開発部の現状 DevOpsとアジャイ ルって親和性あるけ ど、アジャイル文化 根付いてないよな？ あれDevOpsの方法 でマイクロサービス があったけど、モノリ スを切り出すスキル ある人少ないよな？ 技術的負債をまず解 消しないと何も動け なくないか？ 事業部からの依頼が 逼迫しててDevOps に向かうタスクの優 先度があげられない よな？ まず理解してもらわ ないとだよな？
53. |　© Leverages inc. 53 レバテック開発部の現状 DevOpsとアジャイ ルって親和性あるけ ど、アジャイル文化 根付いてないよな？ あれDevOpsの方法 でマイクロサービス があったけど、モノリ スを切り出すスキル ある人少ないよな？ 技術的負債をまず解 消しないと何も動け なくないか？ 事業部からの依頼が 逼迫しててDevOps に向かうタスクの優 先度があげられない よな？ まず理解してもらわ ないとだよな？ そもそもDevOpsを実践するための前提が整っていない
54. まとめ
55. |　© Leverages inc. 55 • Embedded SRE育成プロジェクトを通じてレバテック開発部内にSREの役割や DevOpsの意義が広く知れ渡ったが、実践にはその地盤が整っていない ◦ 今まで上がっていた組織課題はDevOps実現が前提の課題や、一歩進んだと ころが多かった印象(主観) 課題
56. |　© Leverages inc. 56 課題 DevOps SRE デベロッパー 運用問題 事業部理解 アジャイルマインド醸成 スキル不足 DevOpsを阻む壁 技術負債
57. |　© Leverages inc. 57 課題 DevOps SRE デベロッパー 運用問題 事業部理解 アジャイルマインド醸成 スキル不足 DevOpsを阻む壁 技術負債 まずここにアプ ローチする
58. |　© Leverages inc. 58 • 運用問題 ◦ オブザーバビリティツールの活用や自動化によって負担を軽減したい • アジャイルマインド醸成 ◦ 自律型組織にして、DevOpsサイクルをよりよく回すために、まず第一にア ジャイルマインドを醸成に力を入れたい ◦ アジャイル専門チームとコラボしてイネイブリングしていきたい(誰か良いア ジャイルコーチおらんかな...w) • スキル不足 ◦ インフラ実装についてはイネイブリングしていって、責務をアプリケーション エンジニア側に寄せたい これから改善していくこと
59. 終わり