Tweet
Tweet

Slide 1

Slide 1 text

あなたの興味は信頼性？ それとも生産性？ SREとしてのキャリアに悩む みなさまに伝えたい選択肢

Slide 2

Slide 2 text

Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association Organizer @SRE Kaigi

Slide 3

Slide 3 text

Platform Engineering推進の団体をやっています 一般社団法人 クラウドネイティブイノベーターズ協会 Platform Engineering Meetup

Slide 4

Slide 4 text

質問 SREで居続けるの 難しくないですか？

Slide 5

Slide 5 text

SREが登場してから22年 GoogleでSREが提唱されたのが2003年(!) オライリーからSite Reliability Engineeringが出版 されたのが2016年。 日本語版は2017年の8月 これ以降、日本でも採用する事例が増えてきた

Slide 6

Slide 6 text

どうしてSREが必要とされたんだろう そのほうがかっこいいから システムの複雑化 安定性に対する要求 クラウド化(による自動化の余地) ベストプラクティスの導入

Slide 7

Slide 7 text

どうしてSREが必要とされたんだろう そのほうがかっこいいから システムの複雑化 →といいつつ、本当にマイクロサービスやってる組織がどのくらいあるのか 安定性に対する要求 →誰に聞いたってそりゃ障害が少なくて安定しているほうがいいって言う クラウド化(による自動化の余地) →ベンダーの後押しもあり自動化に注目があつまった ベストプラクティスの導入 →流行り物に乗った方がいろんな知見を効率よく得られてコスパ・タイパがいい

Slide 8

Slide 8 text

そして生まれるなんちゃってSRE ● インフラ運用チームが名前を変えただけ ● 開発者数名で始めたスタートアップが 「クラウドと自動化できる便利な人が欲しい」という理由でSREを設置 ● 人材募集する際に、人を集めやすいカテゴリにした方がいいからSREを設置 ● 大手企業が「新しい取り組みやってます」アピールのため

Slide 9

Slide 9 text

そして生まれるなんちゃってSRE ● インフラ運用チームが名前を変えただけ ● 開発者数名で始めたスタートアップが 「クラウドと自動化できる便利な人が欲しい」という理由でSREを設置 ● 人材募集する際に、人を集めやすいカテゴリにした方がいいからSREを設置 ● 大手企業が「新しい取り組みやってます」アピールのため ビジネスの合理性を考えると、必ずしも問題とも言えない でもこういうSREのイベントに来ると、「このままで良いんだろうか･･･」と悩む

Slide 10

Slide 10 text

今日話したいと思っていること みなさんの悩みをスパっと解決できるものではないです 自分がありたいエンジニア像を描く際の材料を提供する

Slide 11

Slide 11 text

そもそも信頼性って何だっけ？

Slide 12

Slide 12 text

そもそも信頼性って何だっけ？ ● SLO ● SLI ● MTTR ● MTBF ● …

Slide 13

Slide 13 text

信頼性を上げる最も効率のいい方法

Slide 14

Slide 14 text

なにもしないこと

Slide 15

Slide 15 text

何かするから障害がおきる “障害のほとんどはデプロイによって引き起こされる。 したがって、デプロイが増えると障害も増え、結果と してインシデント管理、軽減策、ポストモーテムが必 要となる” エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうの か より引用 言い方を変えると、デプロイをしなければ障害は減る

Slide 16

Slide 16 text

だからデプロイ減らしましょ ･･･とはならない (よね？) 今の世の中勝ち残るには、素早く開発して素早く市場に投入するという取り組み が必須。だからこそ、アジャイル開発やDevOpsが必要とされる でもそれだとインシデントが増えるので、SREが必要となる アジャイルもやってないしDevOpsも形だけ。リリース頻度変わってないのに SREとか言い始めると、「なんちゃってSRE」の可能性がとても高い。 おそらくあなたに求められるのは、信頼性向上ではなく クラウドが出来る便利屋さん 注: こうは書いてますけど、「便利屋さん上等！オレがなんとかしてやる」と いう意気込みでいるのは全然アリだとおもいます。ここで言いたいのは、前段 のアジャイルやDevOpsがろくに回ってないのに、形だけSREやっても意味が 無いので、もっと先にやるべきことがあるよね、ということです

Slide 17

Slide 17 text

Four Keys ● デプロイの頻度 ○ 変更を本番環境にデプロイ、あるいはエンドユーザーにリリースした頻度 ● 変更のリードタイム ○ 変更のコミットから、本番環境で正常に実行されるまでの時間 ● 変更失敗率 ○ デプロイによって本番環境で障害が発生する割合 ● デプロイ失敗時の復元までの時間 ○ 本番環境での障害から復元までにかかる時間 Four Keysがよく取り上げられますが、大きく分けると上下 2つに分けられます。上だけ高める、下だけ高めるのは難し くない。全部高めるのが大事だし、チャレンジングな点

Slide 18

Slide 18 text

SREの探求 より引用

Slide 19

Slide 19 text

SREの探求 より引用 Site Reliability Engineer として求められる領域

Slide 20

Slide 20 text

SREの探求 より引用 Site Reliability Engineer として求められる領域 実態

Slide 21

Slide 21 text

SREの探求 より引用 Site Reliability Engineer として求められる領域 実態 ここばっかり やっている人もいる 開発側もなんとかしないといけない、となって、 結局右から左のSREではなく左から右の取り組み まで全部やってるっていう

Slide 22

Slide 22 text

そんな中で出てきたもの Platform Engineering

Slide 23

Slide 23 text

Platform Engineeringとは 開発者体験と生産性を向上させるために セルフサービスで利用できるツールチェーンとワークフローを 設計・構築する分野 定義で言うとこういうのがあります

Slide 24

Slide 24 text

あーあれでしょ 共通基盤作ろうってやつでしょ 大きな会社なら必要あるかもだけど ウチはまだそういう感じじゃないかなー って思う人いるかもしれないので、ちょっと違った表 現をしてみます

Slide 25

Slide 25 text

真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が 高すぎる これをやり切れ る人材は少ない

Slide 26

Slide 26 text

https://www.infoq.com/articles/platform-engineering-primer/ より引用 認知負荷の増大が問題に クラウドの浸透、クラウドネイティブ技術の登場、マイクロサービス化の流れ、 エンジニアの責任範囲の拡大により認知負荷が大変なことに

Slide 27

Slide 27 text

くっそめんどくさい！ 自分もコード書くことありますが、コード書く頭の時 にデプロイのこと考えるのちょう面倒くさい

Slide 28

Slide 28 text

くっそめんどくさい！

Slide 29

Slide 29 text

認知負荷の増大による生産性の低下が 無視出来なくなりつつある この「くっそめんどくさい」が世界中で起きているの が今

Slide 30

Slide 30 text

じゃあ、どうすればいいのか

Slide 31

Slide 31 text

くっそめんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい

Slide 32

Slide 32 text

くっそめんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい その道のプロ = Platform Team その道のプロを体系だって作っていく取り組み = Platform Engineering 開発者側からみたPlatform Engineeringの理解は、この程度でいいと思います

Slide 33

Slide 33 text

くっそめんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい どうお願いするのか。その任せ方、関わり方 教えを請う？ 手伝って貰う？ それとも･･･

Slide 34

Slide 34 text

Team Topologies 価値のあるソフトウェアを素早く届けられるよ うにするための組織設計。 4タイプのチーム定義と、3つのインタラクショ ンモードが定義されている。

Slide 35

Slide 35 text

4つのチームタイプ Stream-aligned team ビジネスのストリームに沿って配置するチー ム。ビジネスの中心 Complicated Subsystem team 複雑なサブシステムやコンポーネントを扱う チーム。その分野のスペシャリストが集まる Enabling team 他のチームが新しい技術やスキルを身につける 支援をするチーム ★Platform team インフラやツール、共通サービスなどのプラッ トフォームを提供するチーム

Slide 36

Slide 36 text

3つのインタラクションモード ファシリテーション 一方のチームが他のチームの障害を取り除くた めに支援をしたり、支援されたりする。同時に 複数のチームと連携することもある コラボレーション 2つのチームが密接に協力して作業する。同時に コラボレーションできるのは1チームまで ★X-as-a-Service 他のチームが提供するものをサービスとして利 用する関係性。責任分界点が明確。疎結合。

Slide 37

Slide 37 text

その道のプロ(= Platform Team)との関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発

Slide 38

Slide 38 text

その道のプロとの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発 最終的にはここを目指す この過程も大事

Slide 39

Slide 39 text

Platform Teamが担うこと ● 開発者の認知負荷軽減を一番の目的として取り組む ● 開発の助けになるような情報を整理する ● あらゆる技術に精通することは難しく、ガバナンスを効かせていく必要もあ るので、Platform Teamは技術の『標準』を定めていく ● スムーズに取り組めるようオンボーディングの仕組みをととのえる ● 必要に応じて勉強会やワークショップの開催を行う ● 開発者からの質問や問い合わせに対して対応する ● 開発者がセルフサービスで利用できる、自動化されたプラットフォーム を作っていく

Slide 40

Slide 40 text

自分のやってることって こっちなのでは？ 🤔 っていう話をすると、いまSREをやっている人も、実 態としてはこっちなんでは？という人もいるかも

Slide 41

Slide 41 text

SREの探求 より引用 SRE Platform Engineering

Slide 42

Slide 42 text

ここで言いたいこと 「SREじゃなくてPlatform Engineeringやれ」とか、 「それはSREって名乗るべきじゃない」とか そういう主張をしたいわけでは全くないです 既に確立されたSREチームがPE的なことをやることもあるだろうし、限られた人 数なので一人で両方を担うみたいなケースも全然あると思います 定義は定義で理解しつつも、実態はうまく調整すれば良いです 僕はそのために商標取ったりしないので安心してください 自分の定義を主張するために商標取るなんて人もいるらしい ですけど、それって不毛なので、定義は定義、実態は実態で うまいこと考えていけばいいんじゃないでしょうか

Slide 43

Slide 43 text

ただ 自分のモチベーションが右から左なのか、左から右なのかは、考えておいたほう がいいです。 そうすることで、適した情報源に当たりやすくなります。 SREの探求 より引用 右から左 SRE 左から右 Platform Engineering

Slide 44

Slide 44 text

deeeetさんとの対談 プラットフォーム開発に関わる人は 「ドラクエでしっかりとスクルトと バイキルトで強化してからボスに望 むのが好きな人」 なんじゃないかという仮説 「プロダクティビティを改善するこ とは、つまり皆を強くすることであ り、みんなで強くなることによっ て、より早くプロダクトを出せるよ うになっていく」 チーム全員の生産性を上げる！ メルカリ deeeetさんに聞く、Platform Engineeringの醍醐味 https://codezine.jp/article/detail/20283

Slide 45

Slide 45 text

こういう人 MMORPGだとバッファータイプ Minecraftでひたすら装置作り

Slide 46

Slide 46 text

共通するところ ● ソフトウェア開発に対する知識、スキル ● 自動化・効率化に対するモチベーション ● 他チームと連携しながら組織を前進させる ● 継続的な改善と学習文化 SRE ● 信頼性・可用性への強いコミット ● 分析・監視・運用設計の能力 ● 障害対応から得た実践的知識 ● データドリブンな意思決定 Platform Engineering ● プラットフォームの設計・開発における技術力 ● ユーザー視点のプロダクト開発マインド ● 組織全体、複数サービスを見渡す抽象化・標準 化への意識 繰り返しになりますけど、SREというタイトルでPlatform Engineeringやっていても良いと思います。共通する項目も多 いので。でも、自分がどっちに対してやりがいを感じるかは、 心の中で整理しておくと良いです。

Slide 47

Slide 47 text

最後に、流行りのアレ

Slide 48

Slide 48 text

AI x (SRE | Platform Engineering) 好む好まざるとに関わらず、AIを活用したSRE / Platform Engineeringの実践は 不可避。 一昨年〜昨年にかけてのRAGを使ったアプローチは上手くいかないケースが多 かった ただ昨年末から盛り上がっているAIエージェントのアプローチは、かなり親和性が 高いように思う(特にPlatform Engineering) 具体的な事例が出てくるのはこれからだが、暖かくなってくる時期から一気に情報 が出てくると思われる

Slide 49

Slide 49 text

AI Driven Development ここ数ヶ月のソフトウェア開発におけるAI Agent の発展がすさまじい 全ての開発が直ちに置き換わるとは思わないが、 全ての開発が「影響を受ける」というのは過言で はない なので、これが開発のメインストリームとなった ときに、SREに求められるのは何か、Platform Engineerに求められるのは何かを早いうちから考 えておくべき まずは自分で触ってみて Cursor composer agent Devin Cline bolt.new いまこの時点では、一定の規模を超えるものを作らせるに は力不足なAIドリブン開発ですが、徐々にやれる規模は広 がるでしょうし、一部のタスクをAIにやらせるというのは 今でも可能。 まずはしゅっと触って感覚を掴むのがお勧め

Slide 50

Slide 50 text

The augmented LLM MCP(Model Context Protocol)や Computer Use, browser-useのように、 LLMと外部がやり取り出来る標準のイン ターフェースが生まれ始めた まずは自社で身近な何かを連携させて仕組み を作ってみるのがおすすめ AnthropicのBuilding effective agentsとい う記事がとてもよく出来ているので、これを 参考にちいさなエージェントを考えてみるの がよさそう https://www.anthropic.com/research/building-eff ective-agents https://www.anthropic.com/research/building-effective-agents より引用

Slide 51

Slide 51 text

まとめ ● SREの主目的は「信頼性」 ● 認知負荷の削減、開発生産性の向上のための「Platform Engineering」 ● SREとPlatform Engineerを明確に分ける必要はないが、自分がどっちを志向 しているのかは理解しておいた方が良い ● AIは不可避

Slide 52

Slide 52 text

Platform Engineering Meetup特別回やります！ 2/19に発売 発売に先立って、2/13に発売記念イベントを兼ねた Meetupを開催します! 一週間も早く入手出来る、書籍の先行販売 著者 Mauricio Salatinoさん登壇 & サイン会 翻訳者 nwiizoさん登壇 & サイン会