SRE NEXT2022の登壇資料です。 https://sre-next.dev/2022/schedule#sp15
©hey, IncheyにおけるSREの大切さ~マルチプロダクト運用の「楽しさ」と「難しさ」および今後の展望~ヘイ株式会社 プロダクト基盤本部 SRE 藤原 涼馬
View Slide
自己紹介藤原 涼馬ヘイ株式会社 プロダクト基盤本部 SRE(他にもいろいろ)経歴 SIer R&D → →趣味 自動車の運転 模型製作 各種寄稿・登壇好きなAWSサービス ECS Fargate / AWS SSO+ 他今ここ
会社概要会社名 ヘイ株式会社設立 2012年3月23日代表取締役社長 佐藤裕介資本金 1億円所在地〒150-0011東京都渋谷区東3丁目16番3号 エフ・ニッセイ恵比寿ビル4階事業内容インターネットビジネスの企画・開発・運営
従業員数・職種比率従業員数350名(2021/04 時点)エンジニア31%セールス・マーケ・事業開発30%サポート・サクセス23%デザイナー5.5%PM2.8%コーポレート8%エンジニア職の比率31%
heyの事業・STORESプラットフォームお店のデジタルをまるっとサポート。個人や中小事業の方々に向けて、お店のデジタル化をまるっと実現できる価値を提供しています。
目次● SREとはなにか● heyにおけるSREの楽しさ● heyにおけるSREの難しさ● 難しさへのSREとしての対峙
SREとはなにか?
SRE(Site Reliability Engineering)とは?1. SREとは、ソフトウェアと自動化を通じてスケーラブルで信頼性の高いシステム構築と運用を実現する2. SREチームはリリースエンジニアリングや、プロダクション環境におけるサービスの可用性、遅延対応、変更管理、緊急対応、容量管理を担当するIT OperationSoftwareEngineering参考)https://www.redhat.com/ja/topics/devops/what-is-sre※ もちろんですがこれが全てではありません
狩野モデル充足不充足充足状況満足感一元的品質満足不満魅力的品質当たり前品質品質特性● 魅力的品質○ 操作していて楽しくなるユーザー体験● 一元的品質○ 業務を遂行するのに必要な機能が揃っている● 当たり前品質○ システムや機能が意図した通りに動く
狩野モデルとSREの役割の関係品質特性● 魅力的品質○ 操作していて楽しくなるユーザー体験● 一元的品質○ 業務を遂行するのに必要な機能が揃っている● 当たり前品質○ システムや機能が意図した通りに動くリリースエンジニアリングプロダクション環境におけるサービスの可用性、遅延対応、変更管理、緊急対応、容量管理
もう一段読み替える品質特性● 魅力的品質○ 操作していて楽しくなるユーザー体験● 一元的品質○ 業務を遂行するのに必要な機能が揃っている● 当たり前品質○ システムや機能が意図した通りに動くリリースエンジニアリングプロダクション環境におけるサービスの可用性、遅延対応、変更管理、緊急対応、容量管理価値提供の支援“魅力品質、一元的品質”実現のためにリリースエンジニアリングを介して実装された機能を滞りなくユーザーに届けられるようにする
もう一段読み替える品質特性● 魅力的品質○ 操作していて楽しくなるユーザー体験● 一元的品質○ 業務を遂行するのに必要な機能が揃っている● 当たり前品質○ システムや機能が意図した通りに動くリリースエンジニアリングプロダクション環境におけるサービスの可用性、遅延対応、変更管理、緊急対応、容量管理価値提供の支援“魅力品質、一元的品質”実現のためにリリースエンジニアリングを介して実装された機能を滞りなくユーザーに届けられるようにする提供価値の維持“当たり前品質”実現のために、アーキテクチャ設計や運用設計に非機能的観点から関与し、安定運用の責務を担う。提供している価値の維持を通じて機会損失の発生を防ぐ
SREとは価値提供の支援“魅力品質、一元的品質 ”実現のためにリリースエンジニアリングを介して実装された機能を滞りなくユーザーに届けられるようにする提供価値の維持“当たり前品質”実現のために、アーキテクチャ設計や運用設計に非機能的観点から関与し、安定運用の責務を担う提供している価値の維持を通じて機会損失の発生を防ぐ上記をソフトウェアエンジニアリングの知識を活用して実現する
heyにおけるSREの楽しさ
heyにおけるSREの楽しさ(SREに限らない部分ではある)の例“ネットショップ”でお買い物このサイトのサービス提供者は...実店舗で”買い物”このお店のPOSレジは、キャッシュレス決済端末は...何かしらのサービスを”予約”通ってるスポーツジムのパーソナルトレーニングの予約システムは...
heyにおけるSREの楽しさ(SREに限らない部分ではある)の例“ネットショップ”でお買い物このサイトのサービス提供者は...実店舗で”買い物”このお店のPOSレジは、キャッシュレス決済端末は...何かしらのサービスを”予約”通ってるスポーツジムのパーソナルトレーニングの予約システムは...身近なところで使われているだけに貢献している感は強い(ただしその分責任も感じやすい)楽しさポイント
heyにおけるSREの楽しさ単一プロダクトの中で価値提供を支援する、提供されている価値を維持する
SREの活動事例(価値提供の支援事例)STORES 決済におけるElastic BeanstalkからECS Fargateへのリアーキテクチャリングhttps://speakerdeck.com/fufuhu/storesjue-ji-niokeruec2karaecs-fargatehefalseyi-xing-wu-ting-zhi-yao-jian-motian-ete
SREの活動事例(価値提供の支援事例)STORES 決済におけるElastic BeanstalkからECS Fargateへのリアーキテクチャリングhttps://speakerdeck.com/fufuhu/storesjue-ji-niokeruec2karaecs-fargatehefalseyi-xing-wu-ting-zhi-yao-jian-motian-eteプロダクト開発者ほかとの協力が”非常に”重要です
SREの活動事例(リアーキテクチャリングにおける関わり方)エンジニアリングマネジメント時間軸全体アーキテクチャ把握プロダクト固有の制約条件確認移行方式の提案と設計移行方式の実装とテスト切替実施全体スケジューリング 進捗管理
SREの活動事例(リアーキテクチャリングにおける関わり方)エンジニアリングマネジメント時間軸全体アーキテクチャ把握プロダクト固有の制約条件確認移行方式の提案と設計移行方式の実装とテスト切替実施全体スケジューリング 進捗管理SREが本来は把握しているべき(※)だが、プロダクト開発者に教えてもらいつつ推進
SREの活動事例(リアーキテクチャリングにおける関わり方)エンジニアリングマネジメント時間軸全体アーキテクチャ把握プロダクト固有の制約条件確認移行方式の提案と設計移行方式の実装とテスト切替実施全体スケジューリング 進捗管理プロダクト開発者の実現したいことを確認しつつSREとして主導して推進QAに協力してもらう範囲なども確定
SREの活動事例(リアーキテクチャリングにおける関わり方)エンジニアリングマネジメント時間軸全体アーキテクチャ把握プロダクト固有の制約条件確認移行方式の提案と設計移行方式の実装とテスト切替実施全体スケジューリング 進捗管理SRE主導で推進しつつ手が足りない部分をプロダクト開発者に支援してもらう
SREの活動事例(リアーキテクチャリングにおける関わり方)エンジニアリングマネジメント時間軸全体アーキテクチャ把握プロダクト固有の制約条件確認移行方式の提案と設計移行方式の実装とテスト切替実施全体スケジューリング 進捗管理プロダクト開発者とSREだけでなくPdMやQAにも助力いただきながら進める
SREの活動事例(リアーキテクチャリングにおける関わり方)エンジニアリングマネジメント時間軸全体アーキテクチャ把握プロダクト固有の制約条件確認移行方式の提案と設計移行方式の実装とテスト切替実施全体スケジューリング 進捗管理PdMやEMを中心に推進SREからはスケジュール的な制約や、システム面での顧客影響の情報を提供
事例を結果から眺めてみる結果として、プロダクト開発者、EM、PdM、QA、SREと関係者全員を巻き込みつつ進めることができた。
事例を結果的に眺めてみる結果として、プロダクト開発者、EM、PdM、QA、SREと関係者全員を巻き込みつつ進めることができた。ユーザーの顔が想像できる分、意思統一を図りやすいかつ、取り組みがうまくいった際に成功を共有しやすい楽しさポイント
個別プロダクトにおけるSREの活動事例個別プロダクト内での取組は他にも多々存在します。heyのプロダクトブログを参照してみてください。https://tech.hey.jp/
heyにおけるSREの難しさ
事業・組織規模の拡大従業員数350名(2021/04 時点)
事業・組織規模の拡大従業員数350名(2021/04 時点)https://note.com/naokos/n/n3e64a68bdaf3
事業・組織規模の拡大従業員数350名(2021/04 時点)https://note.com/naokos/n/n3e64a68bdaf3基本的には組織が成長することに伴う成長痛
事業・組織が拡大すると何が起きる?1. 個別プロダクトの拡大と個別最適化2. コミュニケーションパスの複雑化と知識の散在
個別プロダクトの拡大と個別最適化メリットプロダクトの拡大(≒提供機能の増加)による一元的品質の向上ドメインに合わせた個別最適化による競争優位性、魅力的品質の創出デメリットプロダクトの拡大による機能やアーキテクチャの複雑化過度な最適化 = たこつぼ化
個別プロダクトの拡大と個別最適化メリットプロダクトの拡大(≒提供機能の増加)による一元的品質の向上ドメインに合わせた個別最適化による競争優位性、魅力的品質の創出デメリットプロダクトの拡大による機能やアーキテクチャの複雑化過度な最適化 = たこつぼ化向き合わなければいけない課題
プロダクトの拡大による機能やアーキテクチャの複雑化による問題点大原則複雑なもの = 壊れやすい
プロダクトの拡大による機能やアーキテクチャの複雑化による問題点必要な複雑性の導入は避けられない不要な複雑性を避ける大原則複雑なもの = 壊れやすい
プロダクトAたこつぼ化の問題点● プロダクト間で構成や前提事項が異なりすぎる結果、学習コストが高騰● 組織として重点投資すると決めた際に機動的な人員の割り当てが困難になる個々のエンジニアの悩み言われて来てみたのは良いものの何がどうなってるのかさっぱりわからない......少しずつ学びながら進めようプロダクトBマネジメント層の悩みプロダクトBに重点投資するので人員を移動させたけれども立ち上げにxxヶ月かかるらしい困ったな
コミュニケーションパスの複雑化プロダクト間のシステム的な連携の複雑化人と人の間のコミュニケーションパスの複雑化(もちろん積極的なやりとりは推奨)プロダクトや人が増えるほどコミュニケーションパスが複雑化し、どこに情報があるのかがわからなくなる(=知識の散在)
諸問題を放置した場合に予期される未来組織規模現実的に目指したい状況理想的な状況エンジニアリング的な創出価値
諸問題を放置した場合に予期される未来組織規模現実的に目指したい状況理想的な状況エンジニアリング的な創出価値放置した場合に想定される状況(収穫逓減)
諸問題を放置した場合に予期される未来組織規模現実的に目指したい状況理想的な状況エンジニアリング的な創出価値放置した場合に想定される状況(収穫逓減)投入できる人員が増えた(=組織規模がが拡大した)にもかかわらず創出価値が増えない
諸問題を放置した場合に予期される未来組織規模現実的に目指したい状況理想的な状況エンジニアリング的な創出価値放置した場合に想定される状況(収穫逓減)この状況を避けるにはどうしたら良いか?
難しさへのSREとしての対峙
課題をまとめてみる1. 個別プロダクト、プロダクト間連携の複雑化(必要なもの不要なもの問わず)2. たこつぼ化による学習コストの高騰3. 知識の散在による知識習得、活用の効率低下
課題をまとめてみる1. 個別プロダクト、プロダクト間連携の複雑化(必要なもの不要なもの問わず)2. たこつぼ化による学習コストの高騰3. 知識の散在による知識習得、活用の効率低下プロダクトに閉じない横断的な考え方、取組の必要性
課題をまとめてみる1. 個別プロダクト、プロダクト間連携の複雑化2. たこつぼ化による学習コストの高騰3. 知識の散在による知識習得、活用の効率低下
個別プロダクト、プロダクト間連携の複雑化への対応複雑性に対応できるハイスキルエンジニアの育成各種学習機会の提供(自助努力のみに頼らない)安全に試行錯誤できる場の提供e.g. ある程度自由に利用できる パブリッククラウドアカウントe.g. 各種学習の補助
たこつぼ化による学習コストの高騰知識の散在による知識習得、活用の効率低下 への対応さまざまな知識を容易に収集、活用できるようにして歪んだアーキテクチャの導入を避ける知識の集約と活用容易化(次スライド以降で補足)外部視点の導入組織外の知見者の視点e.g. AWS TAMによる構成レビュー
知識の集約と活用の容易化横断的に活用可能な知識集約と活用の容易化● 知識の集約場所の確保● 知識活用の容易化
知識の集約と活用の容易化横断的に活用可能な知識集約と活用の容易化● 知識の集約場所の確保● 知識活用の容易化● 個別プロダクトの知識を集約するための(仮想)組織の準備● プロダクト個別の取組 ー 固有事情 = 横断的に利用可能な知識(レアケースだが重要なもののなどの知識が蓄積できるe.g. DBのメジャーバージョンアップに伴う停止時間の最小化など)
知識の集約と活用の容易化横断的に活用可能な知識集約と活用の容易化● 知識の集約場所の確保● 知識活用の容易化● 個別プロダクトの知識を集約するための(仮想)組織の準備● プロダクト個別の取組 ー 固有事情 = 横断的に利用可能な知識(レアケースだが重要なもののなどの知識が蓄積できるe.g. DBのメジャーバージョンアップに伴う停止時間の最小化など)● 横断的に利用可能なコードの提供● いわゆるソフトウェアの再利用性といった大きな課題にしっかり取り組む(まずはドメイン依存の少ない部分かつ必ず必要な部分からe.g. インフラのネットワーク、ストレージ、ログ集約など)
取り組みの結果、何を期待する?ドメイン非依存かつ魅力的品質につながりづらい部分の標準化と標準化に伴う品質改善の効率化プロダクト固有度合高低ApplicationMiddleware(Guest)OSVMNetwork &Strage魅力的品質につながりやすい当たり前品質として必要
取り組みの結果、何を期待する?当たり前品質の部分から徐々に標準化などを進めていくプロダクト1 プロダクト2 プロダクト3 プロダクトN・・・SREはスタック的に下のレイヤで当たり前品質の実現を主導
取り組みの結果、何を期待する?当たり前品質の部分から徐々に標準化などを進めていくプロダクト1 プロダクト2 プロダクト3 プロダクトN・・・SREはスタック的に下のレイヤで当たり前品質の実現を主導SREはCI/CDなどの構築支援を通じてプロダクト開発者の一元的、魅力的品質実現支援も担う
取り組みの結果、何を期待する?当たり前品質の部分から徐々に標準化などを進めていくプロダクト1 プロダクト2 プロダクト3 プロダクトN・・・SREはスタック的に下のレイヤで当たり前品質の実現を主導プロダクト開発者はスタック的に上のレイヤに注力プロダクト開発者は当たり前品質の実現は SREに任せ、一元的品質と魅力的品質の実現 に注力
まとめ自分の身近なお商売のオーナーをチームとして支えることによる責任感と達成感がheyのSREに限らない楽しさです。提供価値の拡大と維持を目的として組織規模の成長にともなう収穫逓減の影響を回避、緩和するための様々な活動を進めていきたいと考えています。SREとしては、価値提供の支援、提供価値の維持をより広く、より深く行うためのナレッジマネジメントやナレッジ活用の容易化、人員の機動的運用のための標準化などにも取り組みたいです。
価値提供の支援、提供価値の維持に興味のあるエンジニア大募集です!https://hello.hey.jp/engineer
MORE INFOheyのオープンな社内報hey notehttps://days.hey.jp/Tech イベントhey connpasshttps://hey.connpass.com/プロダクト開発の裏側を発信中hey Product Bloghttps://tech.hey.jp/heyのメディアhey MAGAZINEhttps://mag.hey.jpプロダクトのこと、技術のこと色々お話しましょうカジュアル面談 (Meety)https://meety.net/heyのひとびとを伝える動画hey Peoplehttps://vimeo.com/heyinc
ご清聴ありがとうございました!